Microservices vs. Monolith – A Paradigm Shift in Software Development

Microservices are a pretty new approach to software development, and originate from the DevOps movement. After all, unlike monolithic applications, microservices are the basis for DevOps and continuous delivery methods. In an ever-changing world of business, applications and programs are required to adapt quickly to the user requirements.

And that is the precise strength of microservices. That’s because microservices support loosely-connected architectures and the independent scaling of the individual components. In this respect, they differ from the traditional, monolithic software development.

Monolithic software architecture and microservices: differences

A traditional monolithic architecture is configured as a single large-scale system, and is usually based on a code. It is usually provided in its entirety – which means that if any of the details are changed, the entire architecture has to be edited and made available in closed form. Microservices, on the other hand, are apps that are built as a suite of small services, all of which have their own code base. These services are built around specific functionalities and can be provided independently of each other. Therefore, in the case of detailed changes, it is only necessary for the corresponding micro service to be changed, and not the entire app.

This has decisive advantages, which is noticeable, for example, in the speed of the provision and development in the context of continuous delivery. In reality, however, microservices also increase the complexity, making them more difficult to manage, and topics such as IT governance and compliance are frequently left unresolved.

Therefore, companies and IT departments that take a conventional approach tend to start with a traditional monolithic architecture, especially when the team is very small and the time constraints are very tight. But that isn’t always the right decision. The right choice depends entirely on the type of project. To understand this better, it is firstly necessary to define both options clearly, and to list their advantages and disadvantages.

Monolith: what is meant by this?

A monolithic application is built as a single and coherent unit. It usually consists of three separate parts: a database, a user interface and a server-side application. It handles requests, executes domain-specific logic, retrieves data from the database, completes the corresponding updates and manages the HTML views that are sent to the browser.

In a monolithic logic, the frontend logic on the user side, the background processes and the server logic etc. are all stored in the same massive code base. When developers make changes and updates, they have to build and deploy the entire stack, starting from scratch. That does not mean that a monolith is an outdated architecture that should be consigned to history, however. A monolith is ideal for certain applications: for a small application, for instance, where it would be far too time-consuming to split it into individual microservices.

Advantages of monoliths

• Overlap
• Lower operational overhead costs
• Performance

Disadvantages of monolithic applications

• Fixed coupling
• Increased complexity
• Reduces productivity
• Changing code base is complicated
• If one function fails, the entire application fails
• Inefficient horizontal scaling
• Slower development time

Advantages in detail

• The biggest advantage of a monolithic architecture is that there is a lot of overlap in most apps – such as logging or security functions – and these are easier to handle in monolithic architectures. If everything runs on the same app, then it is easy to connect the components.
• Lower operating overhead costs: as it is a single, large-scale application, the logs, monitoring and tests only have to be set up for one application. This means that the app is generally easier to provide.
• Performance: there may be advantages, as there is no communication between the individual services.

Disadvantages in detail

• Fixed coupling: monolithic architectures tend to interlock and entangle more tightly as the application evolves, making it difficult to isolate the individual services for one purpose, such as independent scaling or code maintenance.
• Higher complexity: monolithic architectures are much more difficult to understand, as there are always dependencies and effects that cannot be identified clearly by focusing on a specific server or controller.
• As a monolithic application grows, so does the associated code base, which overburdens the development environment each time the application loads. This reduces the productivity of the developers.
• As the application runs on EAR/JAR/WAR, for example, it is difficult to change the technology afterwards. Changing the code base of a monolith is complicated because it is always difficult to predict how this will affect the functionality of the entire monolithic application.
• If a single function of the monolith or a single component fails, the entire application fails. If an application contains functions such as payment, login and history, for example, and only one of the functions starts to use more processing power, then this will hinder the performance of the entire application.
• Those who want to scale monolithic applications can only do this by distributing the same EAR/JAR/WAR packages on additional servers. This is known as “horizontal scaling”. Each copy of the application on additional servers uses the same number of underlying resources, making it an inefficient design.
• Monolithic architectures influence the development as well as the deployment of the applications. When applications grow, it is even more important to break the applications down into smaller components. As everything is so tightly interrelated, developers are unable to work independently on monolithic architectures or provide only their own modules. Rather, they are dependent on others and this slows down the development time.
• Be it new functions, user interfaces or technology interfaces, software must provide innovations quickly and easily without negatively affecting the existing applications. This is not a simple task, even for software manufacturers, because existing software in companies is often still developed as a monolith. In other words, a centrally installed program which provides all modules as a whole. And the larger the monolith, the riskier it is to provide new functions quickly.

With these disadvantages in mind, let us now take a look at microservices. In this respect, it is necessary to answer the questions of why microservices, in particular, offer more flexibility than monoliths and the factors that are required for the successful use of microservices – without ignoring the disadvantages of microservices.

Definition of Microservices

Microservices are not necessarily small, or even “micro”. Although they are usually smaller than classic monoliths, their complexity or code base can be quite extensive. The microservice architecture is an approach to providing an application that consists of a set of smaller services, each of which has its own processes and communicates via interfaces (API). These services are built around capabilities that an organization is required to provide, and are provided independently through automated deployment mechanisms. At the same time, the management of these services is centralized and reduced to a minimum.

Advantages of microservices

• Better organization
• Decoupling
• Performance
• Fewer errors

Disadvantages of microservices

• Convergence of different services
• Higher operational overhead costs
• Demanding monitoring
• Costly troubleshooting

Advantages in detail:

• Superior organization: microservice architectures are typically better organized because each microservice has a specific task and is not required to deal with the other components.
• Decoupling: decoupled services are easier to disassemble and reconfigure to serve the purpose of different apps (such as the authorization and streaming service, for example). They also allow for the faster, independent delivery of individual parts within a bigger, integrated system. Each of these microservices is self-contained and has only the one task for which it is intended. That way, it is very simple to add additional microservices without endangering the stability of the entire program. The development of services is also much simpler, because the complexity is significantly reduced.
• Performance: in the right circumstances, depending on how they are organized, microservices can deliver performance benefits, especially because heavily used services can be isolated and scaled independently from the rest of the app. While in a monolith, every function is only available once and only scales with the entire monolith, microservices can be available as often as desired. An example here would be a search service. If you determine that the users of the program search a great deal, then multiple instances of precisely this service can be made available. However, it is not necessary to start other services multiple times, but only those which you need multiple times. This ability not only makes the software extremely powerful, it also leads to it being economically very efficient.
• Fewer errors: microservices enable parallel developments, because boundaries exist between different parts of the system that are difficult to cross. This makes it harder to do the wrong thing, specifically, to connect parts that shouldn’t be connected, or to connect things that should be connected, albeit too closely

Disadvantages in detail:

• The biggest disadvantage of microservices is in the convergence of the different services: those creating a microservice architecture will find that many of the approaches overlap. One solution is for the interfaces to run completely through a separate layer which is responsible for the processes. In monolithic architectures, the traffic often runs through an outer service layer for exactly these overlaps; the cost of this work can be delayed for much longer with monolithic architectures, however, i.e., until the project is much more advanced and mature.
• Higher operating overhead costs: microservices are often be deployed on their own virtual machines or in containers, which frequently increases the costs. These tasks are often automated.
• Time-consuming monitoring of the microservices: those who launch a classic app in microservices or build a completely new microservice system will have many more services to monitor. The services are active on different machines and/or in different containers; use different technologies and/or languages, and can sometimes have their own version control. It’s pretty clear that in this case, there is an urgent need for centralized monitoring and logging.
• Costly troubleshooting: assuming that a microservices network consists of several hundred microservices that interact with each other, it isn’t easy to find the cause of an error, which may potentially be distributed over several services. It is therefore necessary to have a centralized tool that detects these problems from their origin.

In general, considering the advantages and disadvantages of both approaches makes sense. However, these alone are not sufficient as a decision-making basis for companies. On the contrary, to ensure that they choose the right approach for their business, companies should ask themselves some fundamental questions.

Microservices or monolith: choosing the right approach

1. Is the company operating in a familiar territory?

Those who are already well-versed in a field and know the corresponding benefits are able to experiment directly with microservices. Those moving in completely unknown territory and who have no previous experience in the field in which they are working are often better off with monolithic architectures.

2. Is the team well-prepared?

Does the team already have experience with microservices? And are microservices the right approach when the team continues to grow? Evaluating these factors is essential for the success of a project. If a team is already well-prepared, it makes sense to start directly with the microservices, so that the team members get used to the rhythm of the development in a microservices environment – and right from the start.

3. What is the infrastructure?

For microservices to work for a project, a cloud-based infrastructure is necessary. With modern cloud services, such as Google Cloud and Amazon AWS, providing the service has become much easier, as it isn’t necessary to either purchase or to ensure the availability of the entire server base.

4. Evaluating the risk

Microservices are often ambitious, which means they pose a business risk if teams with limited experience embark on the use microservices, or if their use is not appropriate.

5. The context is crucial

The individual context and scenario are of decisive importance in determining whether a monolithic architecture or microservices should be chosen. Companies should be aware of this before they decide on the architecture that is appropriate to their situation.

A monolithic architecture makes sense if…

• The team is still in the start-up phase, has very few members, and is not yet able to manage the complexity of a microservice architecture.
• The company is creating a new, unproven product, or needs a proof of concept: if it is a new idea, it is likely that it will continue to evolve over time. A monolith is therefore ideal to enable a rapid product sequence. The same applies to a proof of concept, where the objective is to learn as much as possible and as quickly as possible, even if the project is discarded in the end.
• There is no previous experience with microservices: if the team has no experience with microservices, they should choose a monolith, unless the company is prepared to accept the risks of a “learning by doing” approach.

There’s nothing wrong with using microservices if…

• The company requires a faster and independent service delivery: microservices enable the rapid and independent provision of individual parts within a larger, integrated system.
• Part of the platform has to be efficient: this part should be built in a very efficient programming language. Different programming languages can be used for other components.
• The team is set to grow: those who start with microservices can ensure that the team is used to working in small, separate services from the very start. As the team grows, there is no need to exponentially introduce a greater degree of complexity, as the teams are already separated from one another by service boundaries.

A brief summary: monolithic architectures aren’t facing extinction. However, microservices should be used according to the context. Companies should always think about their individual needs first, and then decide on the appropriate architecture.