Regardless of the field of activity, every company with its own software in growth is sooner or later faced with the same problem: How to continue the development of the software in a sustainable way? This problem known as software scalability has several proposed solutions. In this article we will talk about Microservices , one of the solutions that is on the rise in the industry, but not always well executed. For starters, it's important to understand what we mean when we talk about scalability issues. When we make our first software by ourselves, whether in a classroom or in your first personal projects, it is common that the biggest challenge is the code itself and how it works. However, when we are in a professional environment, several other challenges appear on a daily basis. The first thing to notice is the teamwork itself. On large projects, it is practically impossible to maintain development with a single person and looking at the scale of companies, it is not uncommon for teams to have dozens of developers. Therefore, one of the scalability barriers is to enable the entire team to be able to create or maintain the code simultaneously and without interfering with each other. Another hurdle is code deliverability. This means how quickly fixes and new features can reach the end customer without interrupting existing ones. This problem is more apparent when the code becomes very large, which makes it difficult to develop new features safely, without impacting existing ones.

How to solve the problem?

Microservices is an architectural model initially proposed by Peter Rodgers (2005), which proposes to divide “traditional” software into multiple specialized software (also called microservices) that communicate to perform system tasks. However, this model has only gained more notoriety in the industry in recent years. They were designed to alleviate many of the symptoms of scalability and therefore have been preferred by medium and large companies when compared to the traditional architecture, which became known as Monolithic . When working with a system built on microservices, we are able to split the team of dozens of developers into multiple teams that specialize in taking care of a single microservice each. This mitigates the difficulties that arise in managing larger teams. And when it comes to deliverability, microservices open up a new possibility that didn't exist in monolithic systems. Through them, you can test and deliver code separately, which drastically reduces coupling problems, such as changes that break unrelated parts of the code. Given these and other architectural advantages, many companies have turned to microservices. However, it is an option that brings its own challenges that are often underestimated and the architecture should not be implemented without first understanding them well.

The Challenges of Microservices

However, one of the biggest challenges is the complexity that the entire system accumulates when it is designed as a microservice. This complexity happens because they have multiple code bases to manage and deliver, multiple databases to take care of and also the increased amount of communication between software. All these points need to be studied in depth before making the choice between microservices and a monolithic system. Anyway, whether or not we choose microservices, we will always have to deal with the scalability of our software, which makes it imperative to have possible solutions in our repertoire. Microservices are expensive to implement, but they give us a powerful tool to tackle the most common scalability challenges.