5 Things to Know about Taking your Monolith Applications to a Microservices Architecture
5GS6_Margaret_Ticknor 1000005GS6 Visits (11157)
The Microservices architecture is based on building a large software application using many small software pieces (microservices) that work together to fulfill a business requirement. This architecture is increasingly being used by many companies for the new cloud based solutions, but what happens with the old single large applications (monoliths) that are running on your data center?
Here are 5 Things to Know when you are considering taking a Monolith application to a Microservices architecture:
Large Monolith applications are facing problems like:
If you are facing these problems with your Monolith application, you should take it to a Microservices architecture, where each Microservice is developed and deployed independently of one another, language agnostic and covers a specific part or functionality inside the complete solution. With this architecture, the software solution is able to adapt to the business and user needs in a fast way, by having small pieces that the technical team can modify, or even delete and recreate, to provide new and better functionalities with a low risk of affecting the other pieces of the software solution. Also by using the right technology stack (programming language, database, brokers, devices, etc.) for the features needed.
There is no a specific path or guide you should follow to take your Monolith to Microservices, so the best way to start is by having a clear understanding of what the end user needs and his expected experience, you can accomplish this process by using Design Thinking, where you define the Who, What and How. After this process you can use the concepts of the Strangler Pattern to define how you are going to split or break the Monolith in an incremental way, avoiding the risk of changing or adding too many functionalities at the same time. In the end you end up with an estimated number of new Microservices for new functionalities and other pieces composed or taken from old parts of the monolith application that you can’t split or break because they are the core of the application and the risk of modifying them is too high, now you can choose the right technology stack for the new pieces.
Now that you have a general process of how the application is going to be taken to Microservices, you can select the right technology for each one of the new Microservices. This is not an easy task, given that today we have a big list of programming languages, protocols, databases and providers. To accomplish this process, it is really important to keep in mind the objective of each functionality and the technologies you and your development know and prefer. There are cases in which it is better to learn a new technology rather than trying to adapt the one you know to provide a specific functionality, and even more with the advantages provided by Cloud Computing, especially with the Cloud Computing Platform as a Service model, where you do not have to install, configure and maintain all the tiers (Network, Infrastructure, OS, middleware, etc) to run a technology and you can start using it to create the features you need. For this task, you can have a look at the IBM Bluemix Catalog, where you can find different services for Data and Analytics, Internet of Things, runtimes, Integration and Cognitive services based on IBM Watson.
In the first point of this article “Why should I take my Monolith to Microservices?” we had a high level view of the Microservices architecture advantages, but it also comes with new challenges that you have to face. Given that now we have several microservices working together, this approach gives us the general problems of distributed data management like data consistency and communication between them, and besides this, since we are evolving a Monolith application, we are also going to face the challenge of integration between the new microservices and the Monolith parts we did not changed.
There are different patterns to solve the consistency and communication challenges, like the Gateway pattern, the pipeline pattern and the Event Driven pattern, and for the integration with the old parts that you are going to keep, you have to think in a Hybrid Cloud architecture, that allows you a secure and consistent communication of the new microservices with your backend services. The specific solution of this problem depends on the cloud provider you select, in the case of IBM Bluemix, there are security and integration services like API Connect, VNPs and the Secure Gateway that will help you with this integration.
This is one of the more important point you have to consider when evolving your monolith to microservices. Usually, in a monolith application, the deployment process is composed of very complex and orchestrated human tasks, probably with a separate development and infrastructure team, and this deployment process may take several hours to finish. In a Microservices architecture you have several microservices to test, deploy and monitor, and probably they are written in different programing languages and using different databases, so it is pretty difficult to give all these deployments to a single team, that is why you should not start a microservices evolution without considering DevOps practices.
This is five points you have to consider when taking a monolith to microservices, if you would like further detailed information about this, please read the IBM Redbooks publication “Evo