We hear about Microservices a lot nowadays. Its implementation requires us to deal with new challenges. A key question that comes with using microservices is how to handle interactions in an asynchronous way. The answer to that is messaging.
Among other things, messaging features the following:
- Loose coupling since it decouples client from services.
- Improved availability since the message broker buffers messages until the consumer is able to process them.
- Supports a variety of communication patterns including request/reply, notifications, request/async response, publish/subscribe, publish/async response and more.
One of the most famous products in messaging is JBoss A-MQ. Among the questions I receive from customers is whether it’s possible to run Red Hat JBoss A-MQ on Red Hat OpenShift. The answer is yes, Red Hat JBoss A-MQ (A-MQ) is available as a containerized image that is designed for use with OpenShift. It allows developers to quickly deploy an A-MQ message broker in a hybrid cloud environment.
The configuration of the broker can be performed two ways:
Before we proceed with how to deploy A-MQ on OpenShift, let’s take a look at different A-MQ architectures in high availability environment.
Continue reading “JBoss A-MQ on OpenShift Cheat Sheet”
Reactive, what an overloaded word. Many things turn out to become magically Reactive these days. In this post, we are going to talk about Reactive Programming, i.e. a development model structured around asynchronous data streams.
I know you are impatient to write your first reactive application, but before doing it, there are a couple of things to know. Using reactive programming changes how you design and write your code. Before jumping on the train, it’s good to know where you are heading.
In this post, we are going to explain 5 things about reactive programming to see what it changes for you.
Continue reading “5 Things to Know About Reactive Programming”
A few days ago I had a rant about the misuse and misunderstanding of REST (typically HTTP) for microservices.
To summarize, a few people/groups have been suggesting that you cannot do asynchronous interactions with HTTP, and that as a result of using HTTP you cannot break down a monolithic application into more agile microservices. The fact that most people refer to REST when they really mean HTTP is also a source of personal frustration, because by this stage experienced people in our industry really should know the difference. If you’re unsure of the difference then check out the restcookbook or even Roy’s PhD thesis (it’s quite a good read!)
However, I digress, so back to the rant: My goal is to point people in the right direction and make some recommendations, hence this followup post.
Continue reading “REST and microservices – breaking down the monolith step by asynchronous step”