Numerous software architects are pushing this architectural style, but considering the migration costs, some practitioners are still hesitant to adopt microservices because they are not fully aware of the pros and cons.
So software developers often choose to adopt one architecture over another based on their experience in previous projects or based on the perceived benefits of the new architecture. Therefore, it is important to study why microservices are adopted, to check the current motivation for their adoption, and to investigate whether specific issues are believed to require more improvement than others.
In order to elicit these motivations, we conducted an empirical study in the form of a survey, interviewing 21 practitioners who adopted a microservices-based architectural style at least two years ago.
As for the motivations driving the adoption of microservices-based architectures, software maintenance was always reported and rated as very important by all the participants. Scalability, delegation of responsibilities to independent teams, and the easy support for DevOps also frequently drive adoption, while other motivations were only reported by migration consultants. One interesting observation is that several practitioners reported adopting microservices-based architectures because a lot of other companies are adopting them.
Maintainability
The modular architecture of microservices allows reducing the complexity of monolithic systems. Breaking a system into independent and self-deployable services enables developer teams to make changes and test their service independent of other developers, which simplifies distributed development. Moreover, the small size of each microservice contributes to increasing code understandability, and thus to improving the maintainability of the code.
Scalability
Scaling microservices is easier than scaling monoliths. Scaling monolithic systems requires a huge investment in terms of hardware and often fine-tuning of the code. If there is a bottleneck in some component, a more powerful piece of hardware can be used, or multiple instances of the same monolithic application can be executed across several services and managed by a load balancer.
In contrast, microservices are not automatically scalable, even if they are commonly deployed in elastic and stateless architectures. However, in a microservices-based system, each microservice can be deployed on a different server, with different levels of performance, and can be written in the most appropriate development language. If there is a bottleneck in one microservice in such a case, the specific microservice can be containerized and executed across multiple hosts in parallel, without the need to deploy the whole system to a more powerful machine.
Delegation of team responsibilities
Since microservices do not have external dependencies, they can be developed by different teams independently, reducing communication overhead and the need for coordination among teams. Each team owns the code base and can be responsible for the development of each service; it can maintain independent revisions and build environments based on their needs. The distribution of clear and independent responsibilities among teams allows splitting large project teams into several small and more efficient teams. Moreover, since microservices can be developed with different technologies and with a totally different internal structure, only high-level and technical decisions need to be coordinated among teams, while other technical decisions can be made by the teams themselves.
Because everybody does it
Microservices are cool, and a lot of large companies are adopting them. Therefore, some practitioners become interested and start investigating the potential of microservices. Over time, this interest commonly increases in practitioners. Our interviewees report that after using microservices in a testing environment or implementing some non-critical features, they started using it also for other features, always because of the perceived improvement regarding maintainability of the system. The main reason reported for this motivation is that, even if they are not totally aware of the real benefits, practitioners prefer following the mainstream, and want to avoid being out of the market in a few years because of a wrong technology choice.
DevOps support
The adoption of a DevOps toolchain is supported by microservices. Since each service can be developed and deployed independently, each team can easily develop, test, and deploy their services independent of other teams.
Fault tolerance
The failure of a microservice does not commonly impact the whole system. In contrast, in a monolithic application, the failure of a component might break the whole system. Moreover, faulty microservices can be quickly restarted. Some of our interviewees also reported that they automatically replace faulty microservices with previous versions of the same service so as to deliver the correct output without the need to restart the whole application.
Easy technology experimentation
Microservices are small by definition. Small components are faster to develop and therefore it is easier to experiment with new technologies or to develop new features. As an example, some participants reported that thanks to the polyglot nature of microservices, they were able to experiment with the introduction of a new service written in a new development language that is more suitable for the new service needs. A monolithic application would not have allowed development in a different language, or at least would not have allowed integrating it as easily and flawlessly into the existing system as the microservices architecture.
Separation of software responsibilities
Microservices are responsible for one single task within well-defined boundaries and are self-contained; therefore, development is greatly simplified.
More information can be found in the publication [1].
[1] , “Processes, Motivations and Issues for Migrating to Microservices Architectures: An Empirical Investigation”, IEEE Cloud Computing Journal, vol. 4, no. 5, 2017