The migration of a software: from monolith to microservices

Living in a constantly changing and demanding world requires our systems to be able to adapt to this pace. Software architecture is a key factor in helping people and organizations deliver their software faster. While there are some techniques such as infrastructure automation, testing, monitoring and continuous delivery that could help, all of these techniques lose their power if the underlying system design where they are applied does not allow for easy adaptation to change. Over the past few decades there has been one software architecture that has dominated over its alternatives; it is the monolithic approach. However, in this new ecosystem where speed and adaptability are essential, this type of system often finds it difficult to work on a large scale and, consequently, to keep pace with business needs. In this context, an idea is spreading through the software community, an idea of small, loosely coupled teams capable of delivering software quickly and reliably through the use of a new architectural approach, that of microservices. But is this new approach the solution to all our problems? Is there a silver bullet or a one-size-fits-all approach when talking about a software architectural style? Is it really a new and revolutionary way of doing things or is it just a twist on something that already exists? What are the main challenges in adopting this approach? This thesis attempts to answer these questions by drawing on both software architecture theory and empirical research to determine the day-to-day reality of implementing this architectural approach, understanding its strengths and weaknesses. The main idea is to build a specific experience based on the reality of the company in its use of this architectural style. In order to gain this experience, this thesis is based on the scientific study and the transformation of a monolithic piece of software to its microservice form. The realization of this thesis allows us to observe how this new approach presents challenges similar to those of distributed systems that, although they are not new, their management is still complicated. At the same time, we have been able to identify the major risks associated with this software architecture and how they can be addressed based on the study of some experiences and consequent proposals made by the community, such as domain orientation, allowing to reduce the negative effects while preserving the positive ones. While we have been migrating the piece of software to microservices, we have realized that adopting this type of architecture is not only a technical challenge but also an organizational one. This type of architecture highlights the importance of Conway’s Law which emphasizes the close relationship between organizational structure and the systems we can create based on it. If we want small, loosely coupled teams capable of creating software highly adaptable and responsive we must configure teams to be the same way. Every company, project or system is different and several factors play a role on defining the architectural approach that bests fits the reality, however, microservices do offer many advantges that can determine the survival or disappearanc