Microservices enable architects to build modular architectures that provide superior characteristics in terms of flexibility, adaptability, and scalability compared to monolithic architectures. Yet, there are also disadvantages of microservices, such as a higher complexity, higher integration needs, fewer efficiencies, duplications, and more required resources. This article illustrates in which situations the advantages outweigh the disadvantages and when not.
The concept behind the decision tree is simple. There are a couple of situations that suggest that you seriously consider a modular architecture based on microservices, which are:
- Demand for parts of the service or the whole service is varying or increasing in the future, so scaling is required. Microservice deployments can be easily multiplied or terminated so that the architecture can be automatically adapted to the actual demand. Also, single microservices can be scaled individually while the resources for other microservices stay the same
- A fast delivery of new features is required, such as reacting to market changes or even disruptions. Microservices support agile ways of working and frequent releases of marginal software improvements. This is because individual microservices can be stopped, adapted, and integrated with little or no impact on the overall system. In a monolithic architecture, in contrast, a whole system would need to be restarted and patched to release changes on single business functions
- A continuous improvement is required. This is often the case when the used technology is not mature and is developing rapidly or if even completely new technologies do emerge that need to be integrated with the existing architecture. As described above, microservices can be updated individually without impacting overall operations. In addition, single microservices can be written in different program languages: As the communication and interaction between microservices are based on standardized APIs, the programming language or technology for the business functionality can be chosen based on the best fit or most recent technologies
If at least one of the above circumstances holds for your situation, you should consider microservices. Next, there are a couple of circumstances that are, with today´s technology, road blockers to using microservices. These are:
- The data that is processed requires the highest level of security. As a microservices landscape has much more APIs than a monolithic architecture, it has also more potential entries for hackers to penetrate the system. This is especially true if microservices are deployed across different locations
- The business function requires the fastest possible operating speed. Many different microservices have to communicate to process a user request. As every interface between microservices takes some time, the sum of the interfaces leads to a noticeably longer processing time compared to a monolithic system
- The deployment of the business function is limited by computing power or storage space. To work independently, microservices have some functionalities doubled that would not be doubled in a perfectly architected monolithic system. In the end, this leads to an increased need for resources in terms of processing power and GPU. In cases in which resources are limited or where they implicate a significant amount of costs, this is a strong argument against microservices.
If you meet at least one of the situations in the first block and if you do not meet any situation in the second block, then you should go for microservices. If you want to learn more about microservices, take a look at this blog post.