Microservices vs. Monolith

Traditionally, many software systems were developed as a single closed unit, a so-called monolith. This contrasts with modern, distributed architectures in which the software is developed and published in separate software components. The question therefore often arises as to whether and when it makes sense to split up a monolithic application. This article sheds light on this question, compares the advantages and disadvantages of the individual approaches and provides decision-making aids for a possible migration.

In software development, monolithic architecture refers to a type of software structure that consists of a single, self-sufficient program that handles all business processes. The application is developed in a large code base and compiled, tested, delivered and executed together. The components of a monolithic application are usually firmly linked to each other and share system resources. Monolithic architectures are, so to speak, the all-in-one solution in software development.

The implementation of a monolithic architecture is generally simple, as the components are homogeneous and communication between components is uncomplicated via simple function calls.

The benefits one monolithic architecture

• In comparison, monolith vs. microservice, development setup and publication are simpler with a monolithic architecture, as only one application needs to be executed.

• Higher performance because all calls are made within the same system process.

• Researching errors is simpler than in distributed systems, since a call does not have to be traced across process boundaries.

The disadvantages one monolithic architecture

• The entire application must always be published. This reduces the radius of action of Deployments larger. This has an impact on quality assurance processes, may require the coordination of maintenance windows and often leads to fewer but larger updates.

• Scaling is only possible for the entire application, even if only a specific business process is affected by a higher load.

• Limitation in flexibility, as the application uses a single Technology stack, which must also be used for all new functionalities.

• Distributed system architectures are often already modularized in themselves, as this is enforced by the technical limits of the system components. In monolithic applications, it is far more important to divide the code into manageable units that are as independent as possible. If this is not done, the complexity can increase to such an extent that changes are difficult to make.

In contrast to the monolithic architecture a microservice architecture consists of a large number of small, autonomous services. Each microservice fulfills a specific business function and can be developed independently. The services communicate via a lightweight protocol such as REST, gRPC and/or event-based with the interfaces of the other services.

A single microservice can be written in any programming language, use the best tools for its task and have its own databases and infrastructure components. In addition, microservices are designed to run as standalone applications, which means they can be easily restarted, updated or scaled without affecting other services.

An extension of the microservice architecture, the so-called Microfrontend Architecture, in which the modularization idea is applied to the Frontends of the application, whereby the microservice architecture itself refers to the backend of the application by default.

The Advantages one Microservice architecture

• The development of individual services can be easily divided between independently working teams. New functionalities can be added in separate services without affecting the overall system. This promotes agile development processes and shortens development cycles.

• Microservices can be scaled independently based on the respective load profile.

• In comparison to monolith vs. microservice, microservices can be published individually - even in parallel with older versions. This leads to a reduced scope of Deployments and thus to smaller, more frequent releases - up to Continuous Deployment scenarios.

• By splitting into individual services, microservice-based applications are often better modularized and the individual units are easier to maintain.

• Because individual business functionalities are available as interfaces, these can also be used to build completely new solutions based on the existing functionalities or to connect external systems.

• The flexibility in technology selection is greater, as the Technology stack can be determined individually for each microservice. This allows the most suitable, modern frameworks and infrastructure components to be selected for the respective service.

The disadvantages a Microservice architecture

• Researching and tracing errors is more complex in distributed systems because a request for a business process potentially runs through many services. Standardization for topics such as Logging and telemetry, as well as the continuous use of correlation IDs provide a remedy.

• The performance of microservice-based applications can become problematic due to the additional overhead for communication between the services. Techniques such as the use of asynchronous service calls or events and the use of caching help to overcome performance problems.

• The development setup of a microservice architecture is more complex when comparing monolith vs. microservice, as it may be necessary to start several services for the development workflow or the calls must be replaced accordingly (e.g. by . e.g. by Mocking). 

• there is an increased need for communication, for example during updates, as the requirements of a business process may have to be processed by several teams and the Deployment of the interdependent services must be coordinated.

• Less standardization, as the services may have different Technology stacks. This can lead to a more heterogeneous technology landscape that needs to be mastered, maintained and updated.

• It is more challenging to maintain data consistency in the overall system, as calls across service boundaries cannot simply be rolled back by transactions in the event of an error. The use of mechanisms such as the outbox or the saga pattern is recommended. However, these require additional development effort.

There is no clear answer to the question of whether and when you should migrate a monolith to a microservice architecture. You certainly shouldn't migrate just to have a microservice architecture afterwards. 

Instead, there should be points in the presented disadvantages of monolithic architecture and/or in the advantages of microservice architectures that represent a decisive improvement of the status quo for the system under consideration. 

Examples:

• The development of the current monolith has become very complex and error-prone. As a result, the speed at which adjustments can be made is severely restricted. The complexity is to be reduced and the work distributed across several teams in future.

• The monolith forms some business processes where performance is particularly important. The performance requirements are currently not met and the horizontal or vertical scaling options are exhausted or too costly. The individual business functions affected should therefore be extracted and scaled individually.

• The monolithic system is based on a legacy framework. A complete migration is not feasible on an ad-hoc basis. Instead, frequently changing and new components should be implemented directly with modern frameworks in order to benefit from their technological advantages. The monolith will then be migrated step by step.

1. Identify microservices:

Determine your monolithic system's various business areas or functions and define how these can be subdivided into individual microservices. Methodologies from domain-driven design (DDD) are suitable for this to Bounded Contexts. 

2. Creation of a roadmap:

The transition from a monolith to microservices can be a complex process. Therefore, it is important to create a detailed roadmap outlining when each service is to be extracted. The priorities should be based on the expected additional business value after the migration.

3. Test cross-sectional aspects:

Creation of a technical puncture, at Scrum often referred to as spike, for the conception of: 

• Microservice communication 
  Definition of how the microservices communicate with each other in which scenarios and which protocols and components are to be used for this. This can be done via interface calls - directly or via an API gateway - and/or via messaging using a MessageBus 

• Runtime and development environment 
  Determine how the microservices will be executed at development time and operated in production. This can include, for example, the use of cloud services and other technologies such as Docker, Kubernetes and Dapr include. 

• Observability ensure 
  Standardization for Logging and telemetry, for example, by using OpenTelemetry and a corresponding aggregation and visualization solution.

4. Enable gradual migration:

The migration of microservices should always be planned so that the first microservices can exist alongside the monolith from the outset and take over their tasks, instead of only rolling out the project with a big bang after the complete monolith has been migrated. The use of the Strangler Fig Patterns. Just as the eponymous strangler fig wraps itself around its host tree and gradually smothers it, the microservices are gradually built up around the monolith until it is completely replaced and, therefore, obsolete. To achieve this, it is necessary to create a technical possibility for the coexistence of monolith and microservice. Depending on the structure of the existing system, this can be implemented via routing rules, e.g. in an API gateway. Alternatively, using Wrappers like adapter/Proxies or facades may be helpful.

This article provides a comprehensive overview of the differences between monolith vs. microservice, including their advantages and disadvantages. The decision to migrate a monolith to microservices should be based on specific problems or improvement opportunities that can be addressed by switching.

The competent experts at Arvato Systems have many years of experience in the migration of applications and application landscapes. They offer support to companies in various industries - through architecture reviews of existing applications, planning of modernization initiatives and the implementation of these through scalable capacities.