From monolithic systems to microservices

We update this article in 2022 to include new developments regarding the transition from monolithic systems to microservices-based architecture.

In the monolithic architecture all services and functions are grouped within a single code base. However, this architecture has become obsolete as projects have grown in complexity, workloads, number of developers and users.

To meet today's business needs, it is becoming necessary for applications to be built in a distributed manner, where different components can be deployed independently.

This is why a microservices-based architecture is increasingly used, which facilitates developers' teamwork and is more easily scalable.

What are monolithic systems or applications?

Monolithic systems (also defined as monolithic applications) group all functionalities and business services into a single code base. To make a change to this type of architecture, it is necessary to update the entire code base, creating and deploying an updated version of the application. This makes upgrades restrictive and time-consuming for development, testing and deployment. 

Benefits of monolithic systems

Early software applications use this design and, although more sophisticated alternatives have been developed, they still have important advantages: they are easy to develop, easy to deploy and - by their very simplicity - simple and fast to run. 

Due to the simplicity of their structure, monolithic applications are generally less expensive to develop than their alternatives.

Its main benefits include:

• Centralised development. As the standard way to create applications, no additional knowledge is required. In addition to having a wide range of tools available, all source code is in one place and can be quickly understood.

• Complete debugging. The debugging process is very natural because all the code is in one place, and you can easily follow the flow of a requirement to find a problem.

• Testing and bug tracking in one place. With fewer variables to check, there is much less risk of something going wrong. As all transactions are recorded in one place, only one service is checked, with no other dependencies.

• Easy onboarding of new team members. As the source code is in one place, new team members can easily familiarise themselves with the application.

• Simple deployment and execution. Only one unit to run must be deployed, with no dependencies. As the user interface is packaged with the backend code, no major changes have to be made. No sophisticated automation tools are required to develop and deploy the application.

• Simplicity in implementation. From a business logic perspective, if other data is needed for a new feature, it is already in one package.

• Reliability. As the monolithic architecture is a tried and tested standard method, it is also considered more reliable than any newer and therefore less proven architecture on the market.

• Low cost in the early stages of implementation. As all the source code is in one place, it is packaged into a single unit to be deployed. Therefore, there are no infrastructure or development costs.

However, an application that concentrates all its functionality is not necessarily better, especially if your system tends to grow in complexity, users, developers and load.

Disadvantages of monolithic systems

• Upgrading a monolithic application is difficult. Because it is a single code, any new deployment requires a re-launch of the whole application. In addition, the size of the single code makes it difficult to identify and fix specific problems.  This, in turn, can be overwhelming for developers who need to understand the code as a whole in order to work on it, as any misstep can compromise the code as a whole.

• Monolithic applications are a growing challenge. With a single code, it is not possible to work in several environments at the same time. The growth of the code goes hand in hand with an overload of the software application, which ultimately affects its agility.

• Reliability issues. Because of how interdependent and interconnected the components of a monolithic system are, even a minor problem can lead to the failure of the entire application. 

• Lack of flexibility. When dealing with a monolithic system, you have no choice but to stick to a single technology, which may have its own limitations. Adopting any kind of new technology could mean having to rewrite the entire system, which is extremely costly and time-consuming. Therefore, upgrades are almost impossible, so developers cannot take advantage of new frameworks and more advanced languages. This becomes a major problem when the currently used framework becomes obsolete. 

In many cases the choice to use a monolithic application is not made by a development team, but is part of business decisions and relationships with external suppliers. If a business application is sold as a single unit, we are bound to that architecture.

Today, microservices are an effective alternative, especially when there is flexibility in the development model and when different teams must work together. 

What are microservices?

Microservices are a way to build digital applications and services. 

A microservices architecture seeks to decouple or separate the individual components of an application, so that each component is an application in its own right. 

Microservices connect to each other through APIs, allowing different teams to work on different parts of an application at the same time.

Benefits of microservices

• The great differentiator of microservices is that the different software components can be developed and deployed independently. 

• The isolation of the code is reinforced, as separate components can reduce the impact that errors in one component can have on the code as a whole (as is the case with monolithic applications).

• Microservices allow individual components to be written in different programming languages, making it possible to have programmers from different specializations working on the same product.

• Microservices can be seen as an evolution of SOA (Service Oriented Architecture). The function of this architecture is to divide a complex system into a variety of independent units, each oriented to a particular function, with its own business logic and independence at the development level. Although SOA proposed to develop and think of independent services for the business, in most cases these services were united in the same application.

• Microservices allow us to evolve and promote software growth. When a specific microservice component grows beyond its capabilities, it is possible to split it into smaller elements or allocate more resources to it. Microservices offer simplicity in software architecture.

The challenges of doing microservices

Although microservices are distinguished by their efficiency, flexibility, agility and growth potential, they involve significant implementation challenges. 

With a larger number of components, it is more complex to operate, requiring more time and resources to create and develop the infrastructure. 

This is one reason why a DevOps (development and operations) culture offers agility to the development process. As Martin Fowler mentions in his Pre-requisites for microservices blog, there are different challenges in operating microservices-based systems:

• Rapid resource provisioning skills, either in the cloud or on-premise. Knowledge of automation tools to deploy and maintain a distributed application. 

• Monitoring schemes for distributed services, including application metrics, networking, log consolidation, as well as ways to link a client operation or transaction to the different microservices it uses.

• Agile development practices such as DevOps, Continuous Integration, Continuous Deployment and product-focused development teams.

Fowler proposes the creation of a maturity model where the current capabilities, weaknesses and roadmap of a development team are clearly documented.

Adding consultants with a high level of maturity in these practices to the team reduces risk and increases the speed of implementation of these practices.

Which is easier to develop, monolithic systems or microservices?

It is important to make a careful decision on the appropriate architecture considering these factors: the problem being addressed, the scope of the development, the expectation of future developments, the size of the team and the available budget.

In general, monolithic systems are more suitable for the following cases:

• Simple, lightweight applications that require only limited functionality.

• Start-up companies that have only a small team and are looking to get their systems up and running quickly.

• Prototypical versions of systems, in their initial testing stage, which are not yet guaranteed to be used frequently.

On the other hand, microservices architecture might be more suitable for such cases:

• Complex and evolving applications, requiring a certain agility and fluidity with the help of experienced developers.

• Systems that plan to expand to acquire more functionality over time.

• Business systems that are already stable and verified, have high traffic and are intended for a long-term project.

Microservices may not be the most suitable architecture for all developments. That is, a monolithic system may work perfectly well, so it may not be worth dismantling it. 

However, as enterprises grow and user requirements for their applications increase, microservices architecture pays off.

When should we think about microservices?

While monolithic architecture is still common for many applications, it is not best for complex systems. As software evolves and develops, it becomes more costly to preserve a monolithic architecture and there are greater advantages to adopting a more flexible architecture that enables and promotes the growth of your business.

Microservices architecture was born as a reaction by developers to the impossibility of scaling applications any further. 

This happens sooner or later with all successful software, regardless of the quality of the original code or how well it has been maintained. At a certain point, the monolithic architecture is simply insufficient for the growing demands of the application. 

Microservices in the cloud

Cloud services are characterized by agility, flexibility, resilience and adaptability. 

Migrating to the cloud is an important step in any software modernisation process, but these benefits do not happen automatically just because you are in the cloud.

Delivering on the promise of a more efficient service requires a parallel adjustment in the architecture of your application. Monolithic architectures easily become a bottleneck for large-scale, complex systems. 

As described in our Cloud Native article, microservices are an essential element of a cloud adoption strategy for digital transformation. 

How to move from monolithic systems to microservices?

When a company decides to migrate to microservices, it is usual to use an external company specialized and experienced in the sector, so that the process can be carried out effectively and quickly, without affecting the different business processes of the company.

During the migration process, developers will instinctively seek to replace the old code as quickly as possible with the new code implementation, which could be extremely risky.

This is why the first thing to do is to analyze the current system, to identify what can be migrated. Initially, look for parts of the business logic that can be separated. In addition, you should identify parts of the code that consume a lot of resources, but can be isolated.

For example, you can start with functionalities that are within the customer's journey through the system, gradually directing traffic away from the monolithic system, through pointers and phasing out previous code.

Examples may be common areas such as media or external file management, authentication with external systems, notification systems, or specific business functions in a traditional application (e.g. shipping costs, discounts, inventories, etc.).

The idea is to slowly replace the functionalities in the monolithic system with the various microservices, in order to minimize the impact of the migration.

This migration can be a challenging and time-consuming process, especially for companies with large and complex monolithic systems.

Contact us at

If your organization is interested in implementing microservices from experts, we invite you to contact us.