Building Enterprise Applications the Microservices Way—Webinar Wrap-up

Last week we completed the webinar series of Microservices Architecture with record numbers of participants. Except for some sound quality issues in the last webinar everything went well.

You can watch the recording by registering here: http://bit.ly/msa-webinars

There are three parts in this webinar series:

• Microservices: the good, the bad, and the ugly
• Microservices: greenfield or brownfield
• Continuous delivery using microservices

The first one included a overview of motivations and benefits of using Microservices by Adrian Cockcroft and Arun Gupta. The second one covered a reference architecture and experience from migrating into microservice architecture by Babak Mozaffari, Siamak Sadeghianfar and myself. The last one explained the correlation between Microservices and DevOps using a Live demonstration of Continuous Delivery using Fabric8 and OpenShift by James Rawlings and myself.

Motivation for Microservices

I believe that most software architects or developers see and immediately recognise the benefits of both continuous delivery and microservices architecture, but it's sometimes hard to convince management of migrating or start using microservice. Business as usual is often seen as the less risky way of doing things. If this is the case in your organisation giving management a bunch of technical reasons for motivation of using microservices often fails. Instead you need to articulate the business benefits. One such business benefit can be described using the OODA model illustrated as a loop. The idea is that the faster you can iterate the loop the more competitive you are as an organisation.

Adrian's presentation (in the first webinar) has allot of useful information about motivation for DevOps and microservices.

Planing for Microservices

When Red Hat Global Professional Services is asked to help organisation to transform into microservices the first step is always to make a analysis of the current state. Are there technical, cultural or organisational barriers that first have to addressed? What would be the immediate and long term benefits of adopting microserivces? How mature are competitors?

These are example of question that you should have answers to before planing an implementation of microservices. 

The next step is define a future state based on microservice and articulate the business benefits of adopting microservices.

When the long term goals are established and accepted by stockholders we are ready to move forward with the actual transformation.

Transformation

The transformation into microservices and DevOps may vary depending the outcome of the analysis of current and future state. Sometime the best way is to create new organisation that will re-implement existing and new applications using Microservices. Sometimes step-wise migration of application are better. 

In one of the projects that I was involve in the current stated analysis showed that this organisation had allot of barriers for implementing microservices. For example, even if the development department recently started working according agile principles, the rest of the IT department was still organised in isolated departments walls between them. The time from identifying a possible improvement until this was released and out in production was almost 1 year. New releases was only allowed once per quarter and these releases where often complex and often failed. They had a huge technical dept of unpatched and unsupported software. In this case we recommended a greenfield transformation, meaning that a parallel organisation was created with a new culture organised in vertical groups consisting of developers, testing, operations etc. The new organisation then replaced old applications and at the same time starting adding new features that had been on the backlog for a long time. After 6 month more than half of the application was transformed to the new organisation. 

In another project the analyst of the current state for that organisation showed a quite mature organisation with small teams without many barrier. Their challenges was instead that the application has grown too large and complex and they had problems scaling. They also had to maintain many versions of the same application because of customer demands. Here the transformation project where much easier and didn't require creating a parallel organisation. Instead large application was broken up into smaller services. Achieving more manage parts that are easier to scale and can use multiple versions of the same service.

Containers and Microservices

The examples and demonstrations in this webinar series where all made using Containers. Even though it's not a requirement for microservices the flexibility and speed of using containers makes is a perfect fit. Adrian Cockcroft is a strong supporter of using Containers as a runtime for microservices Architecture. Containers and especially Docker have lately been accused for not being secure enough and even if many security flaws has todo more about people maintaining their images rather then the container runtime it self there are also some validity in these concerns. Red Hat Enterprise Linux (RHEL) Atomic, combines a rock solid, powerful and secure operating system with containers written in Docker format and is therefor a natural choice for anyone that considers microservices. Additionally OpenShift Enterprise builds on top of RHEL Atomic and provides orchestration and self-service to enable this automation. 

Using publicly downloadable images for different middleware is an easy way to get started with Docker containers, but in my honest opinion you have to be very brave to use these images in a production environment. What is missing today in the Docker community is a chain of trust where we can trust that an image are build on a secure and correctly configured stack of software and operating system. Until we have a echo system where we can trust images we need to be in control of creating containers. Red Hat OpenShift Enterprise provides this control using a layering of docker images where Red Hat provides secure docker images that you can extend. You can either start from a simple RHEL images or you can use an image that contains pre-installed middleware like JBoss Enterprise Application Server. Either way Red Hat takes the responsibility and ensures the chain-of-trust for these images. 

OpenShift

DevOps and microservices architecture are closely coupled. OpenShift Enterprise is a great platform for both. Currently it includes containers for popular frameworks and products like NodeJS, Ruby, Perl, JBoss Enterprise Application Platform, PostgresDB, MariaDB, MongoDB etc. The xPaaS team at Red Hat are currently working on adding more middleware products like JBoss Data Grid, JBoss BPM suite (including JBoss BRMS) and JBoss Fuse.

Slides

The slides are also available for download when you register for watching the webinars on-demand. 

Slides for Continuous delivery using microservices:

Recognitions

Special thanks to Adrian Cockcroft, Arun Gupta, Babak Mozaffari, Siamak Sadeghianfar and James Rawlings for participating and creating great content for the Webinar series.