Migration guide for monolith to microservices architecture

Most organizations today look for microservices approach without understanding their inspiration behind going microservices. Organizations should list down organization goals that they want to acheive by migrating to microservices architecture.

Most organizations want to migrate to microservices architecture pattern only because latest technological trend suggest them so. Undertaking such a decision just to keep up with latest technology trend would be disaster for organization.

To put it simply, microservices architecture should never be default choice of architecture for an application. You should always start with monolith approach and try modularize your application.

Modularizing application is low cost alternative and is good for most cases where application usablility is not known and so functional and non functional aspects are not clear.

Just because you have monolith architecture do not mean application is old in itself. Their are ways we can use monolith architecture to address business requirement, but for this blog purpose, my idea is to focus on microservices approach and to give idea around it.

Organization should opt for microservices if any of following points holds true.

• Organizations want to buy more scaling options: You can scale up or down application with better fine control by going microservice driven in architecture. However, note title says “buy more scaling options” which imply their is cost associated with going microservices driven.

• Limit blast radius of failure: Microservices set strong border between different business functions. As an organization, you may have more than one business functions and may have expected some high priority functions to remain working (eg. customer facing portal). However, you may not mind loosing some business function for some time if thats non-essential. Or you may want to save cost of operating infrastructure by shutting down some of non-essential business functions. In such cases, limiting business function and enabling other important business functions can be better implemented with microservices approach.

In some cases, like GDPR complaince, microservices are expected to process and operate data in only given geographic boundary. Such cases may also imply going microservices route to process specific data.

• People problem: Most monolithic applications overtime turn more complicated as it contains collective code of all business functions. Under such circumstances, new developers will be hesitant to make changes as they don’t completely understand entire piece of code. Also Quality Assurance engineers will find it difficult to only deploy and validate latest change specific to certain business functionality.

Also their is mental limit to extent person can understand code complexity. Once you are beyond certain complexity, your monolith will be beyond understanding of most people. Then, a limited set of people and their efficiency becomes critical to organization’s success and failure.

People with familiarity with monolith also try to ignore drastic technological improvements even if they are beneficial to organization because old is more familiar approach.

So going microservices in such cases also can help.

Approaching microservices:

Once organization determines their reason to go microservices driven, organization should follow following approach.

Note: approach is too generic and should serve as guiding light rather than determined step by step approach.

• Organization should start tracking commits in Jira and tie it with business functions. Such an exercise will help organization identify pieces of code that change together in code repository. Such code that changes together serves as good starting point for abstracting microservice interface.
• Try to bifurcate data into different schemas for your monolith application (if not designed so already). This data separation will help you demarcate clear boundaries in data. Also, in any application, database schema changes relatively less than code; so schema may do better job of explaining application than code alone. Also, database is hardest part in migration so it is better suited to take it early in migration so that microservices can be moulded around data if required. This saves lot of time and cost to organization.
• Organization should plan for migration plan to switch from monolith to microservices and it is better if done over certain period of time than changing application with microservices abruptly.
• Microservice deployments in general is set of lot more work (even for small changes) than monoliths as they are distributed systems. And distributed systems are considered hardest problem in computer science to solve. So focus on automating tasks and free bandwidth for development team to do more productive tasks.