Red Hat Logo

Low-risk Monolith to Microservice Evolution Part II

Let’s dive right in! In the previous post (part I), we set up the context for this blog. Basically, as we introduce a strategy to bring microservices to our architecture, we cannot and should not disrupt the current request flows. Our “monolith” applications typically provide a lot of value for the business and we must drive down the risk of negatively affecting these systems as we iterate and expand. This leads us to an often-overlooked fact: when we start to explore a monolith to the microservice journey we’re going to quickly run into the undesirable, sometimes nasty parts that we cannot just wish away. I encourage you to go back and read the first part if you haven’t yet. Also, go read the part about when NOT do microservices.

Follow along (@christianposta) on Twitter or for the latest updates and discussion.

Continue reading “Low-risk Monolith to Microservice Evolution Part II”

Red Hat Logo

About When Not to Do Microservices

Quick interlude to my last blog. As part of my last blog on low-risk monolith to microservice architecture, I made this statement about microservices and not doing them:

“Microservices architecture is not appropriate all the time”.

I’ve had some interesting reactions. Some of it along the lines of “how dare you”. I also poked at that a bit on Twitter a month or so ago

Don't do microservices

Continue reading “About When Not to Do Microservices”


JBoss A-MQ on OpenShift Cheat Sheet

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”


Low-risk Monolith to Microservice Evolution Part I

As part of a two-day microservices workshop I’m putting together, I’ve been thinking a lot about how to explain monolith-application decomposition and what a transition to microservices might look like. This is a small subset of that material, but I want to share it with you to get feedback (in the workshop we go into more detail about whether you should even break up your monolith). I base this on my own tried and true real-life experience as well as my work with the many Red Hat customers I’ve met over North America for the last few years. Part I explores the architecture while the second part (to be released shortly) will cover some technology that can greatly help in this area. Follow along (@christianposta) on Twitter or for the latest updates and discussion.

Continue reading “Low-risk Monolith to Microservice Evolution Part I”