Monoliths, Services and Microservices: Business Impacts

In IT, the frontier of knowledge is always evolving. In a virtuous cycle, technology manages to allow us to create new solutions, and these new solutions generate demand for new technological capabilities. One of the subjects at the moment, which appears to be full of potential, is microservices architecture. In this article, we’ll explore what these architectures are and their application for business. 

Monolithic applications

With older technologies, the architectural pattern was to build a single, large, and ‘complete’ application. A single application handled all the necessary functionality for a given domain, for example: a management system, CRM, or sales force.

In addition, this single application was responsible for all layers of the solution – it ranged from displaying information to the user on-screen (front-end), processing information (back-end), to storage (database).

Why can monolithic applications be bad?

We are now going to discuss the two main pains of living with a monolith application that directly affect business: scalability and maintainability. 

Scalability

Scalability is the ability to keep up with demand growth. Therefore, that will only be a problem if your business is growing, and we hope it is. As the company grows or reaches a larger number of customers, it is normal to feel impacts on application performance, or even start experiencing unavailability situations – applications that ‘go down’ or stop responding to users.  

Monolithic applications can easily scale vertically, which consists in increasing the capacity of the server where the application is located. So we increase the memory, CPU number, and hope that will be enough.

Fortunately, today we have much more elastic cloud solutions – that is, it is easier to increase server capacity without the need for a lengthy acquisition and configuration process. But even so, every server has a limit, and it is not uncommon to find companies that have already taken their monoliths to the machine limit. 

The other alternative is horizontal scalability – being able to split the load between multiple servers. However, monolithic architecture is not friendly to horizontal scalability. Generally, because it is so intricate, the monolith does not allow running activities in parallel and independently. It requires processes to be executed sequentially, one process at a time, and with the entire application keeping the ‘status’ of that specific process that is running. 

Thus, monoliths have direct impact on the business, bringing performance problems that can generate a loss of revenue, operational efficiency, or negative impacts on the company’s image and customer relationship. In addition, these performance issues are not easy to solve and can become a bottleneck, and a limit to the company’s growth capacity. 

Maintainability

The other painful impact of monoliths is on the ability to maintain the application. The cost of software ownership goes far beyond its initial acquisition or development. The company needs to maintain the application by performing evolutionary, corrective maintenance, and also ensuring its availability through monitoring and maintenance of the associated environment and infrastructure. 

What usually happens is that monolithic applications are exceptionally simple to maintain at first. The code base is small, everything is in the same place, and it is easy to make a correction, or add a function.  

But over time, the code base begins to increase, and so does the number of people involved. As everything is together, not all developers will ‘put things in the right place’, and suddenly business rules that should be in the back-end layer are created on the front-end, or the function belonging to feature X is written alongside feature Y. All developers – each with a different task and goal – are modifying this same code base. Therefore, it’s easy to imagine that they will eventually make inconsistent changes, and end up creating new unforeseen bugs.  

The effect of this on business appears in different ways. One of them is when a new version that modified a specific part of the application presents errors in other parts that, in principle, were not modified. Another effect is the long lead time, each maintenance starts to demand much more time in the integration between the developers and in the tests, in an exponential growth of the maintenance complexity. 

Services and microservices

The solution to these problems is to segment and decouple. Create applications in smaller, independent pieces with clear responsibilities that talk to each other. So it’s worth decoupling the layers, a trend that already existed in architectural patterns like MVC and MVVM, but also decoupling the functions, creating multiple services. 

A service is a distinct enclosed system that provides business functionality in support of building one or larger products (Lee Atchison, Architecting for Scale).

What identifies a service are the following characteristics: 

• Separate codebase;
• Separated data: only the service itself manages its data;
• Provides capabilities for other services;
• Consumes capabilities from other services;

Assuming these characteristics are met, many authors use the terms ‘Services’ and ‘Microservices’ interchangeably. Other authors indicate that the term microservices refers to the tendency to increasingly reduce the size and responsibilities of services, making them more and more granular.  

In the image below, for example, each main function has been divided into a Service that contains its own database and its back-end with multiple endpoints related to that domain. It is also interesting to note that in this type of architecture, the front-end itself can also be broken, using a micro frontend strategy, and if your services are very granular, an intermediate back-end layer (the BFF: Backend For Frontend) can be useful too.   

Advantages and disadvantages

Advantages of building a service-based application include:  

1. Granular decision: as each part is independent, it is possible to make decisions that are also more independent. For example, it is possible to apply different technologies according to the challenge of each part of the application. 

2. Division of work: it is more viable to divide the work into multiple teams, since each team can be working on a specific part. Each service is a closed system, so if a team changes the internal behavior of the service, it will not negatively affect the other services. 

3. Test: for the same reason, as they are closed systems, a service architecture is easier to test than a monolith architecture. 

4. Managed Complexity: complexity is controlled or, in a sense, contained within each service. Imagine a service that is responsible for doing a complex mathematical calculation: if this code is inside the monolith, to work with the monolith safely, everyone must understand how this calculation is done and how it interacts with the rest of the code. However, if it is contained in a service, whoever needs to use it just needs to know the input and output interface. 

But these architectures also have their disadvantages: 

1. Infrastructure complexity: instead of publishing an application (monolith), it will be necessary to publish multiple applications. Each service will have its own specific lifecycle and will need to be published and maintained. It is unfeasible to maintain an environment like this without the support of containerization tools and without an improvement in the DevOps environment to increase automation, in addition to monitoring tools. This requires specialized knowledge and a dedicated team. 

2. Higher initial cost: It is also normal to notice a higher initial infrastructure cost, also in development team. This higher initial cost will pay off through the ability to scale.

Conclusion: should I migrate to microservices?

As in all technological evolutions, there is no one-size-fits-all. That is, there is no solution that is applicable to all cases. 

So don’t rush out to migrate to a microservices architecture. First, assess whether the application you are maintaining or building needs to scale. Is it expected to grow a lot in terms of functionality or number of users? Some applications are made to meet a specific scenario and will have a stable number of users. Others are made for temporary use, with planned obsolescence.  

But, if you are working in a project that has an exponential business model, or if you plan to evolve the application to serve many “modules” or areas that are complex by itself, then we suggest that you do worry about knowing this type of architecture, to not let your application become a bottleneck for the evolution of the business. 

If you want to learn more about microservices and understand how we can help you, fill out the form below.