Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation

"The term 'microservice' has been widely used since March 2012 to refer to applications developed as a set of relatively small, consistent, isolated, and autonomous services deployed independently, with a single and clearly defined purpose."

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.

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.

Scalability. Scaling microservices is easier than scaling monoliths. Scaling monolithic systems requires 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.

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.

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.

Because Everybody Does It. Microservices are cool, and a lot of large companies are adopting them.

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.

The main issues reported are the complexity to decouple from the monolithic system, followed by migration and splitting of data in legacy databases and communication among services.

As reported in Table 3, improved maintenance was confirmed as the most important benefit. Practitioners reported that in the beginning they were aware that such a complex architecture might have a negative impact on software maintenance, but in the long run (at least one year, based on participant answers), they discovered that the architecture is less complex to understand and the system requires less maintenance.

Table description: The migration benefits identified in the survey

All the participants confirmed that the development of a microservices-based system has initial costs that are higher than those for developing a traditional system, with 24% reporting increased costs ranging from zero to 10% and the remaining 76% reporting an effort overhead between 20% and 30%.

All the participants also agreed that the higher cost overhead is highly compensated by the reduction of maintenance effort in the long run.

The reasons for migrating to microservices are manifold. Several participants migrated to microservices simply because it was the only feasible solution for reducing the growing complexity of their systems. Therefore, maintainability as a consequence of the properties of some microservices is the key driver for migration, whereas the increased initial cost turned out to be one of the main issues hindering adoption, even if such costs were highly compensated after the adoption because of the long-term return on investment.