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 http://blog.christianposta.com for the latest updates and discussion.

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

Share
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”

Share

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”

Share

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 http://developers.redhat.com for the latest updates and discussion.

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

Share