Transitioning from a monolith to a microservice is a worthy endeavor, but it is not devoid of challenges and obstacles. There are certain pre-conditions that should be considered before you migrate a monolith to a microservice. This article discusses these prerequisites, such as deployment pipelines, easy provisioning, basic monitoring, rapid deployment, and so forth.
In the sections that follow, we will examine what needs to be in place before your development team transitions a monolith to microservices architecture.
Microservices Infrastructure Checklist
You should be aware of the technical infrastructure that should be in place ahead of building microservices in an enterprise. You should have your plans in place to handle disaster recovery, service discovery, load balancing, and scaling. You should be able to figure out if you would need all the services to be scaled or only just a few of them. Logging should also be a part of the platform infrastructure – you should be able to log each microservice call (both inbound and outbound) into a pre-configured repository – for example, either a file or a database.
Read: An Introduction to Microservices.
Rapid Provisioning
Your team of developers should be well-prepared to handle rapid provisioning and application deployment scenarios. In other words, you should be able to provision the infrastructure and deploy the services quickly there. You should also be able to fire up a new server at the drop of a hat (i.e., you should be able to provision the servers in hours rather than days). For rapid provisioning, automation is a must – it may not be possible at the beginning; but over a longer period of time you should be able to get it.
Robust monitoring
With several services working together in a production environment, there might be issues that may not have been identified in a test environment. This calls for the need of good basic monitoring. You should be able to effectively monitor and manage the entire infrastructure so that you can detect failures related to the CPU, network, or the application quickly. The monitoring system should be good enough to track the flow of messages flowing through the system.
Application performance should be monitored and measured periodically. To do this, you need to be aware of the basic system level metrics such as, CPU and RAM, application-level metrics, and the business level metrics, including transactions per second.
Read: Microservices Observability and Monitoring.
Rapid Deployment
With microservices your team might often need to manage several services and be able to deploy them quickly. To make this happen, you need a deployment pipeline. For managing the integration and deployment of microservices it is imperative that you have continuous integration and continuous deployment in place. Though you might need some manual intervention in the early stages, the deployment pipeline should be fully automated in the long run.
Degree of Independence
You need to be able to decide the level of independence your services should be in, – i.e., whether each service should be completely independent of another. In this case, each service will have its own database. Another option would be to have services that share some components (typically the database). These approaches each have their benefits and downsides, and you will need to choose which one is right for your application.
Although the second option has its benefits (it ensures data consistency across the services), there are downsides as well. As an example, in sharing the database between services, the services are not completely decoupled and if you update the schema of the database then the other services might be affected.
Inter-service Collaboration
REST or gRPC can be used to enable services to communicate and collaborate with each other. However, these approaches can pose problems due to coupling of the services in real-time. To enable collaboration between services, you should define well established interfaces or contracts between the services. Such interfaces or contracts should be designed in such a way that they are not fragile and would not need to be changed over time.
A design that supports autonomous services would be a good choice. When the services are autonomous, they do not need to inter-communicate in real-time. Having autonomous services enables your application to keep working even if some part of the application (one or more services) have stopped working or have failed.
Embrace DevOps Culture
Above all, your organization should embrace DevOps practices and culture. There must be close collaboration between the development and operations teams. You need a culture of shared responsibility and cooperation between the team members. This collaborative culture and cohesion amongst the teams will facilitate rapid provisioning, deploying and help identifying the problems quickly.
Organization Support
The most important point to consider is whether your organization is ready for microservices (i.e., ready for a transition from monolith to microservices architecture). Are all departments in your organization aligned as far as the shift to microservices is concerned? You should be able to answer these and other similar questions. Transitioning to microservices in an organization is a change. To bring about this change in an organization you need leadership buy-in. You need the leadership’s willingness to accept this change and embrace it.
Read: How to Align Your Team Around Microservices.
Downsides to Transitioning to Microservices
Even if the prerequisites are satisfied, you should consider the downsides in transitioning to microservices. This will help you to know if the approach really suits your business needs. Increased operational cost, increased complexity, and so on are some of the many challenges that you would need to address if you are to transition your monolith to microservices architecture.
A better strategy would be to refactor the monolith into clear modules with distinct application boundaries defined. Then you should also make sure that the application has automated tests written. Once you have done all this, several issues that you have been facing with your monolith would disappear. That is the time when you can decide if the transition is worth it.
