Microservice architecture promises to bring all the exciting and fascinating features into a system, which was not easy with monolithic architecture. Microservice offers all benefits such as scalability, high availability, loose coupling between components, high cohesion, and so on but there are some challenges involved in getting into microservices architecture. The decision of migrating to microservices isn't easy. This is a, relatively new field and there is lack of experience in this field. Hopefully more and more people delving into this can drive some patterns in the architecture. There are many factors that an organization should consider before migrating to microservice architecture. Before taking a big step, any organization should consider following factors.
Make sure people who are going to work in this environment are educated about it. It is not limited only to technical skill set, but they also need knowledge of the concept on which they are working. Mostly, people or teams should adopt the full stack developer philosophy. Their mindset should be aligned in DevOps work knowledge. Developer works in microservice environment, have a complete ownership of their microservice. It is very necessary that there should be no boundary in their mind as developers such as front end developer, back end developer, DevOps member and so on. The team should be ready to do all stuff by itself. Although having DevOps is always a good thing, the team should be self-sufficient to handle these tasks.
Make sure organizations have a mature DevOps team and procedures in place to handle multiple releases happening in a day. When moving from monolithic to microservices architecture, each service needs to be monitored separately. It will be an additional responsibility for the infrastructure and DevOps team. If you have to ship fast and independently, then your DevOps and monitoring system should be attentive enough to go and rollback efficiently if anything goes wrong.
Efficient decomposing of databases is a problem. Sometimes, a database is designed in such a way that it is hard to decompose it or it requires a major design change in DB tables. Is the organization ready to take that hit? Is it feasible to break down one big DB into much smaller databases that are logically and physically different from each other? As data is in the decentralized form and resides in different databases, it means there will be no physical connection at tables. It leads to major changes in code bases.
Automation testing tools and CI/CD tools such as Jenkins and Team City should be in place for frequent delivery or release of microservices. Each microservice has to have its own deployment pipeline and configuration management. This will again be an overhead for the DevOps team. TDD is very important in this aspect. Unit test cases and integration test cases should be in place to support automation testing and continuous delivery.
For having different pieces of an application running at different places (microservices), one needs a lot of integration work, to get the desired output. Integration work like communication among these services and lots of maintenance work will be overheads while moving towards microservices.
With so many components talking to each other over APIs or over messaging, security becomes an important aspect to look out for. Credential-based or token-based microservices offer many solutions to handle the problems, but it will be an overhead for the developing and infrastructure teams to manage.
Any organization that is ready to give blood to microservice architecture should consider giving thoughts to the preceding factors. Successful implementation of this will give any organization the freedom to scale, high availability, and any time deployment and can achieve zero downtime.
Netflix is one of the big shots that has stepped into microservices from the traditional monolithic application in 2009. They were so amazed with their learning that they shared the experience at each step of this journey with the world. Today, Netflix has roughly 800+ microservices running, which serve around 2 billion requests daily, resulting in 20 billion internal API hits in these microservices.
When Netflix started moving from a monolithic to a microservices architecture, the term "microservices" wasn't around. Initially, Netflix used to have a big monolithic application; they started with moving the movie encoding code base, a non-customer-facing application, to small new microservices. This is the best approach while migrating to microservices architecture: always move non-customer-facing components from monolithic to microservice architecture first. The failure of these types of components has less impact on traffic and the customer journey on the production. After this successful exercise, they started moving customer-facing components to microservices. By the end of 2011, they were completely on AWS cloud with a number of microservices running. Netflix has open sourced some of the tools that helped them successfully migrate from monolithic to microservices architecture. These tools are accessible at http://netflix.github.io/.