Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.
Continue reading “Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online”
This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives. Such alternatives can be referred to as “Just enough Application Server”, like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.
Continue reading Curse you choices! Kubernetes or Application Servers? (Part 3)
This is the third of a series of three articles based on a session I held at Red Hat Tech Exchange EMEA. In the first article, I presented the rationale and approach for leveraging Red Hat OpenShift or Kubernetes for automated performance testing, and I gave an overview of the setup. In the second article, we looked at building an observability stack. In this third part, we will see how the execution of the performance tests can be automated and related metrics gathered.
An example of what is described in this article is available in my GitHub repository.
Continue reading “Automating tests and metrics gathering for Kubernetes and OpenShift (part 3)”
Migrating from one software solution to another is a reality that all good software developers need to plan for. Having a plan helps to drive innovation at a continuous pace, whether you are developing software for in-house use or you are acquiring software from a vendor. In either case, never anticipating or planning for migration endangers the entire innovation value proposition. And in today’s ever-changing world of software, everyone who wants to benefit from the success of the cloud has to ensure that cloud innovation is continuous. Therefore, maintaining a stack that is changing along with technological advancements is a necessity.
In this article, we will take a look at the impact of moving to OpenJDK and the results will aid in drawing further conclusions and in planning. It’s quite common to be using a proprietary version of JDK, and this article addresses how to use Red Hat Application Migration Toolkit to analyze your codebase to understand the impact of migrating to OpenJDK.
Continue reading “Using Red Hat Application Migration Toolkit to see the impact of migrating to OpenJDK”
This is the second of a series of three articles based on a session I held at Red Hat Tech Exchange in EMEA. In the first article, I presented the rationale and approach for leveraging Red Hat OpenShift or Kubernetes for automated performance testing, and I gave an overview of the setup.
In this article, we will look at building an observability stack. In production, the observability stack can help verify that the system is working correctly and performing well. It can also be leveraged during performance tests to provide insight into how the application performs under load.
An example of what is described in this article is available in my GitHub repository.
Continue reading “Building an observability stack for automated performance tests on Kubernetes and OpenShift (part 2)”
These days, microservices-based architectures are being implemented almost everywhere. One business function could be using a few microservices that generate lots of network traffic in the form of messages being passed around. If we can make the way we pass messages more efficient by having a smaller message size, we could the same infrastructure to handle higher loads.
Protobuf (short for “protocol buffers”) provides language- and platform-neutral mechanisms for serializing structured data for use in communications protocols, data storage, and more. gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. Together, they provide an efficient message format that is automatically compressed and provides first-class support for complex data structures among other benefits (unlike JSON).
Microservices environments require lots of communication between services, and for this to happen, services need to agree on a few things. They need to agree on an API for exchanging data, for example, POST (or PUT) and GET to send and receive messages. And they need to agree on the format of the data (JSON). Clients calling the service also need to write lots of boilerplate code to make the remote calls (frameworks!). Protobuf and gRPC provide a way to define the schema of the message (JSON cannot) and generate skeleton code to consume a gRPC service (no frameworks required).
Continue reading “Using a Kotlin-based gRPC API with Envoy proxy for server-side load balancing”
Recently I’ve started updating my free online workshops for business rules and process automation that showcase how to get started using modern business logic tooling. These updates start with moving from Red Hat JBoss BRMS to Red Hat Decision Manager and from Red Hat JBoss BPM Suite to Red Hat Process Automation Manager.
This article highlights the first lab update for Red Hat Decision Manager, where you learn to install Decision Manager on your laptop.
Let’s take a look at the lab, shall we?
Continue reading “Modern business logic tooling workshop, lab 1: Installation”
How do YOU get your Java apps running in a cloud?
First you grab a cloud from the sky by, for example, (1) Getting started with a free account on Red Hat OpenShift Online, or (2) locally on your laptop using Red Hat Container Development Kit (CDK) or upstream Minishift on Windows, macOS, and Linux, or (3) using
oc cluster up (only on Linux), or (4) by obtaining a login from someone running Red Hat OpenShift on a public or on-premises cloud. Then, you download the oc CLI client tool probably for Windows (and put it on your PATH). Then you select the Copy Login Command from the menu in the upper right corner under your name in the OpenShift Console’s UI, and you use, for example, the
oc status command.
Great—now you just need to containerize your Java app. You could, of course, start to write your own Dockerfile, pick an appropriate container base image (and discuss Red Hat Enterprise Linux versus CentOS versus Fedora versus Ubuntu versus Debian versus Alpine with your co-workers; and, especially if you’re in an enterprise environment, figure out how to have that supported in production), figure out appropriate JVM startup parameters for a container, add monitoring, and so.
But perhaps what you really wanted to do today is…well, just get your Java app running in a cloud!
Read on to find an easier way.
Continue reading “Building Java 11 and Gradle containers for OpenShift”
“Truth can only be found in one place: the code,” Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship.
The way we structure our code has a direct impact on how understandable is it. Code that is easy to follow with no or less hidden functionality is much easier to maintain. It also makes it easier for our fellow programmers to track down bugs in the code. This helps us to avoid Venkat’s Jesus Driven Development.
The way I write Spring applications comprises heavy use of Spring annotations. The problem with this approach is that partial flow of the application is controlled by annotations. The complete flow of my code is not in one place, that is, in my code. I need to look back to the documentation to understand the annotations’ behavior. By reading just the code, it is difficult to predict the flow of control.
Luckily, Spring has a new way to code to and it has been called Spring Functional or SpringFu. In this article, I will use Kotlin to showcase some of the benefits you get from SpringFu.
Continue reading “Writing better Spring applications using SpringFu”
Our connected world is full of events that are triggered or received by different software services. One of the big issues is that event publishers tend to describe events differently and in ways that are mostly incompatible with each other.
To address this, the Serverless Working Group from the Cloud Native Computing Foundation (CNCF) recently announced version 0.2 of the CloudEvents specification. The specification aims to describe event data in a common, standardized way. To some degree, a CloudEvent is an abstract envelope with some specified attributes that describe a concrete event and its data.
Working with CloudEvents is simple. This article shows how to use the powerful JVM toolkit provided by Vert.x to either generate or receive and process CloudEvents.
Continue reading “Processing CloudEvents with Eclipse Vert.x”