Monolith Server to Microservices

We successfully migrated our application from one big monolith server to micro-services architecture. In process we learned a lot and I thought it will be good exercise to point of out issues with monolith servers and challenges involved in migrating to micro-services architecture.

Monolith Servers

Monolithic servers are not designed to be monolithic but become one over a period of time. Initially these applications provide basic functionality of intended use case. These applications provide quick proof of concept and enables product owners to roll out new features in relatively short time. These applications have smaller resource footprint and performs better.

But as time goes on, applications becomes heavy. More services, features, workflows are added. Since these are exiting times for the organizations, engineers and product owners are more concerned with customers and capturing market share. In order to keep performance and stability metrics intact, more powerful hardware and extra resources are thrown at the application.

But it is not only performance or stability but other aspect of development are impacted. Such servers becomes increasingly complex and take more time to develop, test, deploy.

Top issues with monolithic servers

• Unpredictable performance: Increasingly it becomes difficult to maintain performance of application. Its difficult to find out which service/workflow is taking more resources impacting performance of other services. 
• Monitoring Challenges: Each application should have clear metrics logged so that right information can be gathered. But when application have too many metrics ( one or two for each service ), it becomes overwhelming and counter productive.
• High Availability and Scalability nightmare: HA of stateful monolith applications becomes extremely difficult. 
• Upgrade Challenges: Huge risks are involved with upgrading entire application. One malfunction workflow can cause entire application go down creating more risk for its customers.
• Server startup time increases: This may or may not be an issue for some organization. But monolith servers takes long time to come up, sometime 20-25 minutes. This downtime may not be acceptable for certain businesses.
• Limitations in usage of technology or third party libraries: This issue hampers developers ability to use new libraries, technology. A developers cannot freely use new and better third party libraries without worrying about interface change one has to do to other's code. 
• Ownership crisis: If more than one cross-functional team's code is getting deployed in such monolith application, one can imagine the ownership issues it will create. Production and customer issues are tossed around because their is no clear owner.
• Development, Test and Continuous Integration: Its virtually impossible to do continuous integration. It exponentially takes more time to develop and test such application. 

Microservices

Everybody is aware of Microservices. These are independent process which are loosely coupled providing a complete solution. Building new solutions based on micro services is normal practice and all new design and product do that job well. But it gets challenging to covert a running monolith application to loosely couple micro services. It get more complicated if both types of application needs to co-exist while migration to micro services is going on in production.

This is not just technical shift but cultural shift as well. Embracing microservices and in general devops culture requires having common understanding of the new architecture and open attitude to adopt it. This journey will obsolete some components while give birth to new. It is extremely important that all architects, technical managers and engineers are talking the same language so the communication is not a bottleneck.

Decomposing Monolith:

In this phase identify how many and which microservices should run independently. One requires complete and details knowledge of current monolith so that appropriate microservices can be identified and can be carved out. Its team exercise and needs to have proper brain storming discussion and reviews from entire engineering.

Identify communication protocol and its infrastructure:

I cannot stress this point more. If organization have solid infrastructure already in place then adoption of microservices becomes must faster and easier. If not then it is important to put in engineering efforts in building such infrastructure.

Messaging infrastructure allows services to talk to each other via common interface. Its common to have multiple communication protocol through which services talk to each other. REST, TCP, UDP, Message Broker like AMQP are some of the common protocols through which services can talk to each other.

Refactor current code into core services/modules:

Refactoring is the key here. Many times a well written, well tested code is much easier to refactor so that it can be put behind interfaces. Otherwise engineering efforts are required to refactor current code. This refactored service can still be run under monolith or in its own container as micro service. This provides a good migration path.

Test driven (TDD) approach is extremely important. If code to be refactor has no or very little tests then its better to first write those test cases. This helps catching regression issues upfront and saves valuable time.

Build new framework:

Often above exercise if done correctly, one will find that each service needs some typical low level services like logging, persistence, messaging, metrics etc. Its wasteful and cumbersome if each micro service has its own these types of low level services. Building or using of the shelf framework for such purpose is highly recommended.

API:

Each service needs to have clear, concise API which is well documented. Up to date API documentation is extremely important in order to have successful adoption of micro service. API development has to take backward compatibility into account so that other services can upgrade to new API in gradual manner. 

Finally there is no one fit for all approach here. Every engineering team needs to decide what is best for them and move towards common goal. It is important to keep working till monolith server is completely deprecated and replaced by new microservices in production.