The microservices architecture, as a successor to the service-oriented architecture style, represents a widely accepted approach to developing complex applications.
It is based on a collection of loosely-coupled independent services that communicate with each other using lightweight protocols.
The main problem solved by this architectural pattern is the ability to develop and deploy new services independently of other services.
In case of bugs in a new release, the risks associated with deployment are limited to the level of the microservice, which is a smaller part of the application, while the deployment itself can be automated (DevOps) and easily rolled back.
However, like with all technologies, there are also downsides of this approach.
First of all, many developers are surprised when they see a picture showing microservices alongside other architectural patterns currently in use, as many believe that microservices architecture is the only one being utilized.
Another surprise arises when they discover that, alongside the aforementioned advantages, microservices architecture also comes with several drawbacks.”
The image below is taken from the book ‘Fundamentals of Software Architecture’ and illustrates the advantages and drawbacks of microservices architecture.
Some of the main drawbacks include complexity (many moving parts that can fail), high maintenance costs, poor performance, limited number of supported integration methods (mostly REST APIs), data management (app data is splitted across multiple databases), complex monitoring and troubleshooting, maintaining complex distributed transactions (especially if ACID is required) – particularly for rolling back transactions, lack of developers with the necessary skill set, etc.
If we were to visualize a single microservice, it would most commonly look like the image below.
In real-life scenarios, the most common are REST API-based microservices that either call other microservices or retrieve data from the database of that microservice (each microservice having its own database, which icould also be a schema within a single database).
An application will always consist of multiple microservices (otherwise, it would be a monolithic application).
The image below illustrates the complexity of interactions among microservices in practice which results in poor performance (distributed transactions).
The following image demonstrates the efficiency of REST vs JDBC protocols, which is another downside of microservices architecture (poor performance due to limitations in integration protocols).
For the same load, the REST service exhausted all server resources, whereas the JDBC protocol barely consumed 5%.
The following image depicts the complexity of monitoring in the case of microservices architecture, which is another drawback of this architecture.
Conclusion:
While an entire book could be written solely on the drawbacks of microservices architecture, the aim of this article is simply to raise awareness that this architectural pattern addresses some issues, but at the same time introduces a whole new set of problems that are not present in other types of architectures.
In the end of a day, when choosing an architectural style, the most important is to assess the major issues and be aware of the drawbacks that come with it.
My rule of thumb is that for a large and complex project, it’s probably worth relying on microservices architecture.
In other cases, it’s worth considering other architectural styles that are still in use for a good reason.
What’s not depicted in this article are the architectural patterns I most frequently use – so called hybrid architecture style.
I’m taking the best features from other architectural styles and combining them together.
But that might be a topic for a future article.
Comments