Microservices versus monoliths

Important goals of modern software development are short release cycles, rapid response to new technology trends and high software availability.
When monolithic applications have to be developed and maintained over a long period of time, it becomes increasingly difficult to meet these requirements.
As we also repeatedly encounter precisely these difficulties in our projects and product development, we decided last summer to use the iMath research project to investigate an alternative form of architecture in more detail, namely microservices.
Over the past six months, I have been examining the differences, advantages and disadvantages of both types of architecture as part of my bachelor’s thesis “Microservices versus Monoliths”.

In contrast to monoliths, where all functionalities have to be built, tested and deployed as a single unit, microservices divide an application into small, independent services.
These services are only loosely coupled, which means that they communicate exclusively via the network.

These characteristics of microservices result in a number of advantages.
In the long term, microservices offer better maintainability, as each service can be further developed independently of others.
In addition, the loose coupling between services enables independent deployment.
Another advantage is that the individual services are easier to replace.
As long as the interface of a service does not change, it makes no difference which libraries, frameworks or programming languages are used in the background.

However, the downside of microservice architecture is the large overhead and the new challenges that this form of architecture brings with it.
Microservices are a distributed system, which means that communication takes place over the network.
This type of communication is prone to errors.
Another challenge is the deployment and operation of microservices.
A high degree of automation must be aimed for, especially in larger systems with many individual services.
This applies both to deployment and to monitoring the services during operation.

In order to overcome these challenges, it is important to rely on a framework that already implements many of these requirements.
In the Java area, the Spring Framework is suitable for this.
It provides libraries for the implementation of REST services, messaging systems, service discovery, distributed tracing, fault tolerance and much more, and therefore offers the basic requirements for the implementation of microservices.

Conclusion: It is clear that microservices entail a significant overhead, but this can be managed if the right tools are used.
Nevertheless, the software project must have a certain scope so that the advantages of the microservice architecture outweigh the additional challenges.