Interest in microservices has been growing since 2014. Can microservices do more harm than good? In this post I will try to look critically at the topic of microservices and answer the question posed above.
In most cases, software developers prefer small and light projects, so the idea of microservices as a number of small projects seems like it could be a hit. Here one should answer the question of how big the microservice can be if we think of it as a small project. We can find many absurd metrics describing the size of microservices on the Internet. Some think that a microservice should contain no more than one thousand lines; others think that a team who creates microservices should consume no more than three pizzas; still others think that it should be possible to rewrite a microservice in one typical scrum sprint, so about two weeks. Personally, I think that a microservice should be as large as necessary and as small as possible. Of course, size is just one of the characteristics of microservices. A microservice should be connected with a culture of automation, hide details related to internal implementation, be deployed independently, isolate failure and be modeled around business concepts.
Looking at the above features, one can come to the conclusion that microservices are much better when compared to traditional monolithic architecture. What developers want, i.e. the development of small projects and the ease of implementation and delivery, suits the above features. The business team should also be satisfied because, as part of an architecture based on microservices, it receives an application which is scalable and, most importantly, resistant to failures. Unfortunately, that’s where the theory ends, because practical experience reveals many problems and threats associated with an application based on microservices.
It cannot be denied that the dynamic development of microservices was made possible due to the DevOps (development and operations) method of software development. This is due to the fact that each service requires the separate management of logs, implementation or other administrative operations. In the case of one or even several monolithic applications, it is no problem for one person to take care of it. Unfortunately, the workload usually grows linearly along with subsequent applications, which means that a staff of administrators would be required for several dozen or even several hundred microservices were it not for DevOps, and in particular automation in the broadly understood sense. This way we have defined the first requirement that is necessary, but unfortunately not sufficient in itself, to start a project based on micro-services, meaning the preparation of an appropriate environment for our application, automated to the greatest possible degree.
Read more about Project Delivery model.
In the age of the availability and popularity of cloud computing, too many developers forget about network communication and the problems it can create. Two applications which communicate with each other do not do so in a faultless, let alone magical, way. Such incorrect assumptions have been defined and described by L Peter Deutsch as “fallacies of distributed computing”:
If the abovementioned erroneous assumptions about the network are not taken into account and the distributed application is not prepared on that basis, then it is likely that any problems in communication between microservices will arise faster than we may have expected.
Another challenge is related to data consistency. In a system dispersed in accordance with the CAP created by Eric Brewer, it is impossible to achieve consistency, accessibility and partition tolerance simultaneously. We can assume that total partitioning, meaning the failure of part of the system, is rare; however, we could look at a delay, and the latency, of the update between nodes as a temporary partitioning. In this situation the choice is between consistency and availability. In practice, most people prefer availability to consistency; it is also possible to bet on consistency but with no guarantees that the system will be available 100% of the time.
As I wrote at the beginning of this post, each microservice should be associated with a single responsibility, i.e. be closely related to a specific domain based on the bounded context. Newly created systems have related requirements which change frequently in the initial phase of their creation, which may involve blurring the border between microservices through the migration of mutual responsibilities. The result is that the system consists of many microservices, each responsible for everything. Of course, this does not have much in common with the microservice application. This is nothing more than a distributed monolith.
Microservices are also a different work culture than the one that often prevails when working on a large monolithic application. Instead of one large team, we should have many small ones, with testers, developers, etc. being responsible for each microservice. The advantage of this approach is having clearly defined responsibilities for each domain, i.e. microservices.
Microservice project in practice: “Insurance Company under the Digital Transformation – Case Study”
To sum up, the purpose of this post is not to convince the reader that microservices are good or bad, but to realize which problems are created, and understand that the transition from monolithic to microservice architecture does not solve problems, but only shifts them around. If we approach microservices in a responsible and thoughtful way, they can prove to be a good choice. Microservices are also worth considering in the case of new projects, starting with monolithic architecture and switching to a microservice after the initial stage of development, in cases where the main requirements will not change too often and the boundary between domains will not be moved regularly. It is also easier to separate domains and define bounded context in a monolith, that is, something that already exists, than to share something that is not there yet.
Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!
Comment