Up until now, we have heard a lot about microservices. In plain English, we can say that it's a way to break a large system into smaller subsystems in order to try and make the system as a whole work more efficiently. It should be easier to build and maintain. As much as it sounds good, at the same time, it is a challenge to break up any platform into a microservice pattern. It doesn't matter whether you are building it from scratch or migrating from a monolithic to a microservice architecture, it takes a lot of time, effort, expertise, and research to do so.
Say you have had a successful monolithic application, running for the last few years: Why would you want to change it? You are using it for a business, and a business needs consumers. If you see an increase in the number of internet users, then it makes sense for you to try to increase sales by increasing your digital presence and attracting more and more traffic. With good digital marketing, the number of visitors to your site will increase, and sooner or later your website will reach the point where the response time will start dipping. If you have an e-commerce platform and it is popular, then one big sales day can be a hard time for your platform. So, whichever pattern or technology was good yesterday for your platform, will not necessarily be best for the future, because of the increase in traffic. Something has to change to accommodate the increase in the number of requests. The microservice architecture may be the best option for you--it depends on the specific details of your platform.
Another key factor is dependencies between the features of your platform. A change in one feature that is seemingly irrelevant to another might cause a problem that means you have to deploy the whole application again, which means downtime for the whole application. If there is a failure in an unrelated feature, it can cause the whole system to experience downtime, even if the feature is not used by the user, or is obsolete.
In this chapter, we will try to address these challenges, and look at the best practice one can follow. The following topics will be covered in this chapter:
- Primary mechanisms to evolve a microservices architecture
- Example walkthrough on how to evolve the sample application
- Challenges that you may face
A typical monolithic application consists of a UI layer, controller layer, service layer, persistence layer, and a database. In the very first stage, the client request is directly handled by the monolithic application. After performing some business logic or database interaction, it will be delivered to the client:
Should the traffic increase on your platform, whether for one day or permanently, then one option would be to add multiple servers to your application and add a load balancer in front of those applications:
The problem is that the traffic load for which we have to scale this whole monolithic application won't use all the modules/components. The traffic mostly uses some of the services, but not all. But you still have to scale the whole application, including the unused modules. High traffic only hits the subsystem. If you want to scale only the subsystem (which is facing high traffic) in isolation, then it is not possible in monolithic applications. To scale any subsystem, you have to scale the complete application. In microservice design, you have the option to scale only those services that are facing high traffic, not all the services:
To achieve this pattern, there are a few hurdles to overcome. First of all, you need a technician and a domain expert who understands the domain. These people will understand the domain and try to define the different subsystems with a clear-cut separation of duties or a well-defined bounded context.
The second hurdle would be the mindset of the team. The team should feel ownership about the module or service that they have to develop.
Thirdly, the DevOps team would have lots of overhead, as well as new challenges. Before migrating from a monolithic to a microservice architecture, the DevOps team should be prepared to take on these challenges.
The fourth hurdle concerns monitoring, scaling, and logging. Monitoring and taking action when action is required is not an easy task, for any number of services. We will discuss how to solve monitoring, scaling, and logging problems in the next chapter.
These are the four most important challenges you will face while evolving your system. There are more challenges, such as testing, that we have already discussed, and some of these are going to be discussed in upcoming sections, along with the solutions and recommended best practices to overcome these challenges.