Microservices – Principles for converting monolith to Microservices

Lot has been written and talked about architecture and building of micro services. Recently I watched a great video by Arun Gupta (Converting J2EE monolith to microservices)  about converting monolith J2EE application into application based off micro service based architecture. Whole lecture is about 2 and half hours. Here are few points I wanted to note down for reference.

What is Monolith Application?

An application having its own set of UI, DB, Caching mechanism, Security, deployed on a container, with set of war/jar/ear files (in case it is J2EE application) is called monolith application. When considering refactoring of monolith application to microservices based architecture the job is easier if monolith application is written using certain principles in mind. These principles are :-

1. Domain driven design – DDD
2. Separation of concerns using MVC
3. High cohesion, low coupling
4. Do not repeat – DRY
5. Convention over Configuration – CoC
6. YAGNI – You Ain’t Going to Need It

Monoliths written using principles above are easy to decompose into Microservices.

What are Micro services?

Before going to into details of what micro service really is, let us define what micro service is not.

Microservices is not a technology. It is not SOA pattern (Service Oriented Architecture pattern). Neither it is another ESB. Any vendor in the market do not have a product which will help an enterprise build a micro service platform.

Micro services is way of designing,deploying application so that application is decomposed into several logical units which are re-used often, easily scalable, can be deployed as single unit (have bounded context), follow SRP (single responsibility principle) and can be chained together.

Microservices tend to use ReST webservices, take advantage of CI (continuous integration), usually deployed in distributed environment, truly polyglot, deployed on Containers/PaaS.

Steps towards building Microservices –

Each microservice should have its own database/private tables/private schema. Tables should not be shared by micro services unless only one micro service is writing the data to the tables while rest of the micro services are read-only. A tool in the market called JBOSS data virtualization tool creates a view using data in multiple data store. Inidvidual micro service could access the view in order to perform its function. This way we problem of having to denormalize the data in order to be used by different microservices can be overcome. Also, if data is residing in multiple different databases (relational/NoSql), it can be combined to logical view and used as well.

Microservice design patterns – 

I am not going to re-invent the wheel here. Arun Gupta explained the patterns in great detail in dzon refcard. Please be sure to check the link Microservices design patterns. He explains about design patterns starting page 3 of the pdf.

Questions to ask yourself –

Once decision is made to refactor monolith towards building micro service based application, few questions for which answers need to be figured out are –

1. What is going to be data strategy? – Use of private tables/schemas/one database per micro service
2. What is fault tolerance strategy? How the application going to handle failover? What is application’s resiliency?
3. How is the application going to perform service monitoring, logging, produce alerts and chain the events? – ELK stack could be one possible option
4. How application should perform dependency resolution ? – Nexus is preferred choice in most of the companies
5. How and where the application should be deployed? – Docker container, Kubernetes, PaaS are some of the choices