Microservices have become mainstream in the enterprise. This proliferation of microservices applications generates new problems, which requires a new approach to managing problems. A microservice is a small, independently deployable, and independently scalable software service that is designed to encapsulate a specific semantic function in the larger applicationl. This article explores several approaches to deploying tools to debug microservices applications on a Kubernetes platform like Red Hat OpenShift, including OpenTracing, Squash, Telepresence, and creating a Squash Operator in Red Hat Ansible Automation.
Continue reading “Solving the challenges of debugging microservices on a container platform”
This is the first article in a series of three articles based on a session I hold at Red Hat Tech Exchange EMEA. In this first article, I present the rationale and approach for leveraging Red Hat OpenShift or Kubernetes for automated performance testing, give an overview of the setup, and discuss points that are worth considering when executing and analyzing performance tests. I will also say a few words about performance tuning.
In the second article, we will look at building an observability stack, which—beyond the support it provides in production—can be leveraged during performance tests. Open sources projects like Prometheus, Jaeger, Elasticsearch and Grafana will be used for the purpose. The third article will present the details for building an environment for performance testing and automating the execution with JMeter and Jenkins.
Continue reading “Leveraging OpenShift or Kubernetes for automated performance tests (part 1)”
Kubernetes installations can be complex with multiple runtime dependencies and runtime engines. CRI-O was created to provide a lightweight runtime for Kubernetes which adds an abstraction layer between the cluster and the runtime that allows for various OCI runtime technologies. However you still have the problem of depending on daemon(s) in your cluster for builds – I.e. if you are using the cluster for builds you still need a Docker daemon.
Enter Buildah. Buildah allows you to have a Kubernetes cluster without any Docker daemon for both runtime and builds. Excellent. But what if things go wrong? What if you want to do troubleshooting or debugging of containers in your cluster? Buildah isn’t really built for that, what you need is a client tool for working with containers and the one that comes to mind is Docker CLI – but then you’re back to using the daemon.
This is where Podman steps in. Podman allows you to do all of the Docker commands without the daemon dependency. To see examples of Podman replacing the
docker command, see Alessandro Arrichiello’s Intro to Podman and Doug Tidwell’s Podman—The next generation of Linux container tools.
Continue reading “Containers without daemons: Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta”
With the release of version 7.1 of Red Hat Process Automation Manager (RHPAM), the platform now supports the deployment of the process automation manager runtime as a “capability” within Spring Boot applications. As Maciej Swiderski, the project lead for jBPM.org (the upstream community project for RHPAM) explained earlier this year, the KIE (Knowledge Is Everything) platform on which RHPAM is built provides Spring Boot Starters to quickly build a business application or microservice with process and case execution capabilities using a minimal amount of code.
Continue reading “Spring Boot-enabled business process automation with Red Hat Process Automation Manager”
We have pretty exciting news this week as Red Hat is announcing the General Availability of their Apache Kafka Kubernetes operator. Red Hat AMQ Streams delivers the mechanisms for managing Apache Kafka on top of OpenShift, our enterprise distribution for Kubernetes.
Everything started last May 2018 when David Ingham (@dingha) unveiled the Developer Preview as new addition to the Red Hat AMQ offering. Red Hat AMQ Streams focuses on running Apache Kafka on OpenShift. In the microservices world, where several components need to rely on a high throughput communication mechanism, Apache Kafka has made a name for itself for being a leading real-time, distributed messaging platform for building data pipelines and streaming applications.
Continue reading “Welcome Apache Kafka to the Kubernetes Era!”
This post is the first in a series of three related posts that describes a lightweight cloud-native distributed microservices framework we have created called EventFlow. EventFlow can be used to develop streaming applications that can process CloudEvents, which are an effort to standardize upon a data format for exchanging information about events generated by cloud platforms.
The EventFlow platform was created to specifically target the Kubernetes/OpenShift platforms, and it models event-processing applications as a connected flow or stream of components. The development of these components can be facilitated through the use of a simple SDK library, or they can be created as Docker images that can be configured using environment variables to attach to Kafka topics and process event data directly.
Continue reading “EventFlow: Event-driven microservices on OpenShift (Part 1)”
Welcome to the second in a series of posts on Kubernetes, application servers, and the future. Part 1, Kubernetes is the new application operating environment, discussed Kubernetes and its place in application development. In this part, we explore application servers and their role in relation to Kubernetes.
You may recall from Part 1 that we were exploring the views put forth in Why Kubernetes is The New Application Server and thinking about what those views mean for Java EE, Jakarta EE, Eclipse MicroProfile, and application servers. Is it a curtain call for application servers? Are we seeing the start of an imminent decline in their favor and usage?
Before answering that, we need to discuss the use case for application servers. Then can we decide whether it’s still a valid use case.
Continue reading “Are App Servers Dead in the Age of Kubernetes? (Part 2)”
This post is a short summary of my recent experiences with customers that are implementing architectures similar to microservices but with different characteristics in the current post-microservices world.
The microservices architectural style has been around for close to five years now, and much has been said and written about it. Today, I see teams deciding not to strictly follow certain principles of the “pure” microservices architecture and to break some of the “rules.” Teams are now more informed about the pros and cons of microservices, and they make context-driven decisions respecting team experience and organizational boundaries and accept the fact that not every company is Netflix. Below are some examples I have seen in my recent microservices gigs.
Continue reading “The rise of non-microservices architectures”
This is the first in a series of articles that consider the role of Kubernetes and application servers. Do application servers need to exist? Where does the current situation leave developers trying to choose the right path forward for their applications?
Why Kubernetes is the new application server
By now you’ve likely read “Why Kubernetes is The New Application Server” and you might be wondering what that means for you. How does it impact Java EE or Jakarta EE and Eclipse MicroProfile? What about application servers or fat JARs? Is it the end as we’ve known it for nearly two decades?
In reality, it doesn’t impact the worldview for most. It’s in line with the efforts of a majority of vendors around Docker and Kubernetes deployments over the last few years. In addition, there’s greater interest in service mesh infrastructures, such as Istio, and how they can further assist with managing Kubernetes deployments.
Continue reading “Kubernetes is the new application operating environment (Part 1)”
[We are reposting on the Red Hat Developers blog this article from the Red Hat OpenShift blog, which was written by Diane Mueller-Klingspor.]
When we released OpenShift Origin as the open source upstream project for Red Hat OpenShift back in April 2012, we had little inkling of the phenomenal trajectory of cloud-native technology that was to come. With all the work that has gone into the Kubernetes-based core platform (OpenShift 3) from the initial OpenShift Origin 1.0 Release (OpenShift 3) in June 2015, to the current release of Red Hat OpenShift 3.10 release last week, we’ve seen the rise of Kubernetes and containers create the basis of the cloud-native landscape. We collaborated in the incubation and maturation of dozens of new cloud-native projects and into a myriad of upstream projects, expanding the universe of tools and platforms in a way we could only have dreamed about just three years ago.
So it’s time for a new logo, a new website, and a new name for our open source project. We are changing the name of our open source project to better represent who we are today, and who we’ll be tomorrow—the Origin community distribution of Kubernetes that powers Red Hat OpenShift.
Continue reading “OKD: Renaming of OpenShift Origin with 3.10 release”