I am pleased to announce that my upcoming book “Vert.x in Action: Asynchronous and Reactive Applications in Java” is now available from the Manning early-access program (MEAP): (See below for the exclusive Red Hat Developer discount code)
As enterprise applications become larger and more distributed, new architectural approaches like reactive designs, microservices, and event streams are required knowledge. The Eclipse Vert.x framework provides a mature, rock-solid toolkit for building reactive applications using Java, Kotlin, or Scala. Vert.x in Action teaches you to build responsive, resilient, and scalable JVM applications with Vert.x using well-established reactive design patterns.
Vert.x in Action teaches you to build highly-scalable reactive enterprise applications. In this practical developer’s guide, Vert.x expert Julien Ponge gets you up to speed in the basics of asynchronous programming as you learn to design and code reactive applications. Using the Vert.x asynchronous APIs, you’ll build services including web stack, messaging, authentication, and access control. You’ll also dive into deployment of container-native components with Docker, Kubernetes, and OpenShift. Along the way, you’ll check your app’s health and learn to test its resilience to external service failures.
Continue reading “Upcoming Book: Vert.x in Action (MEAP)”
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”
On October 25th Red Hat announced the general availability of their AMQ Streams Kubernetes Operator for Apache Kafka. Red Hat AMQ Streams focuses on running Apache Kafka on Openshift providing a massively-scalable, distributed, and high performance data streaming platform. AMQ Streams, based on the Apache Kafka and Strimzi projects, offers a distributed backbone that allows microservices and other applications to share data with extremely high throughput. This backbone enables:
- Publish and subscribe: Many to many dissemination in a fault tolerant, durable manner.
- Replayable events: Serves as a repository for microservices to build in-memory copies of source data, up to any point in time.
- Long-term data retention: Efficiently stores data for immediate access in a manner limited only by disk space.
- Partition messages for more horizontal scalability: Allows for organizing messages to maximum concurrent access.
One of the most requested items from developers and architects is how to get started with a simple deployment option for testing purposes. In this guide we will use Red Hat Container Development Kit, based on minishift, to start an Apache Kafka cluster on Kubernetes.
Continue reading “How to run Kafka on Openshift, the enterprise Kubernetes, with AMQ Streams”
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!”
An Introduction to Thorntail
Today Red Hat is making Thorntail 2.2 generally available to Red Hat customers through a subscription to Red Hat OpenShift Application Runtimes (RHOAR). RHOAR provides application developers with a variety of application runtimes running on the OpenShift Container Platform.
Thorntail is the new name for WildFly Swarm, and bundles everything you need to develop and run Thorntail and MicroProfile applications by packaging server runtime libraries with your application code and running it with
java -jar. It speeds up the transition from monoliths to microservices and takes advantage of your existing industry standard Java EE technology experience.
Continue reading “Announcing: Thorntail 2.2 General Availability”
At the recently concluded Microsoft Ignite 2018 conference in Orlando, I had the honor of presenting to a crowd of Java developers and Azure professionals eager to learn how to put their Java skills to work building next-gen apps on Azure. Of course, that meant showcasing the technology coming out of the popular MicroProfile community, in which Red Hat plays a big part (and makes a fully supported, productized MicroProfile implementation through Thorntail, part of Red Hat OpenShift Application Runtimes).
We did a demo too, which is the main topic of this blog post, showing how easy it is to link your Java MicroProfile apps to Azure services through the Open Service Broker for Azure (the open source, Open Service Broker-compatible API server that provisions managed services in the Microsoft Azure public cloud) and OpenShift’s Service Catalog.
Here’s how to reproduce the demo.
Continue reading “Deploying MicroProfile apps on Microsoft Azure using the Azure Open Service Broker”
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)”
Microservices architecture (MSA) has become very popular.. However, one common problem is how to manage distributed transactions across multiple microservices. This post is going to share my experience from past projects and explain the problem and possible patterns that could solve it.
What is a distributed transaction?
When a microservice architecture decomposes a monolithic system into self-encapsulated services, it can break transactions. This means a local transaction in the monolithic system is now distributed into multiple services that will be called in a sequence.
Continue reading “Patterns for distributed transactions within a microservices architecture”
The Istio service mesh is a powerful tool for building a service mesh. If you don’t know about Istio yet, have a look at the Introduction to Istio series of articles or download the ebook Introducing Istio Service Mesh for Microservices.
The power of Istio comes with the cost of some complexity at configuration and runtime. To help this, the Kiali project provides observability of the mesh and the services in the mesh. Kiali visualizes the mesh with its services and workloads. It indicates the health of the mesh and shows hints about applied configuration options. You can then drill in on individual services or settings to view details.
This post describes how to use Kiali to observe what the microservices in your Istio service mesh are doing, validate the Istio configuration, and see any issues.
Continue reading “Observe what your Istio microservices mesh is doing with Kiali”