Migration from Monolith to Microservices: Redesigning instead of reusing

Autonomous services instead of inflexible service clusters

A monolithic system is composed of closely integrated layers that are highly interdependent and need to be integrated in the same output. A microservice, on the other hand, is not a layer within a monolithic system. In fact, it is an independent business application that provides its services via interfaces to any client. An architecture of microservices enables a modular separation of concerns.

Microservices depict a type of service-oriented architecture (SOA). A system is therefore structured as a collection of loosely coupled, lightweight services. These services can be developed and scaled independently of each other. Microservices communicate with each other via messages, can be operated in a decentralised manner and can be provided i.e. integrated and tested continuously and automatically. Consequently, Microservices have an independent life cycle.

Layer Model Monolith vs. Microservices

Typically, a monolithic application is composed of three layers:

- Business logic

- Data layer

- User interface

Microservices, on the other hand, consist of:

- Business logic

- Possibly a data layer

- Programming interface

Redesigning instead of reusing

It is not recommended to reuse the monolith to code microservices as this code contains the environment dependencies that Microservices do not have. If monolithic services are not based on a clear domain concept, the data structures used will also not correspond to the new domain models.

How can a monolithic application be dismantled?

The migration should gradually decouple core functions from the monolith by eliminating dependencies on the monolith. If this policy is followed, dependencies will instead be built in the opposite direction - from the monolith to the services. This is the desired direction for the dependencies.

For this architectural style, the question of the demarcation between the individual services must be clarified. Each migration step should improve the code organization. A typical problem is that features of the monolith that are not based on a precisely defined domain concept, but on which many functions of the monolith depend. Developers need to identify such functions, break them down into well-defined domain concepts and transform them into autonomous services.

An example of such a problematic feature in web-based monoliths is a "session" - the ability for an application to remember who is logged in during a single use of an application - that can contain a variety of attributes across domain boundaries. Developers should incrementally extract microservices from the session function here, one service at a time.

Front-end applications are finally redirected to the new interfaces of the microservices. Different applications can then use the same microservice.

"Micronaut" is an example of a modern framework for the development of easily testable microservices on the Java Virtual Machine.

Challenges with Microservice Architectures

Distributed architectures come with their own kind of complexity. When dealing with migration, developers need to take into account the effort involved and possible disadvantages:

- Inter-service calls via a network have higher costs (latencies) than inter-process calls in a monolithic system.

- Services with different programming languages and technologies increase complexity.

- Requests across multiple services, each with its own interface, are harder to track than in monoliths.

- Each service must be secured by an authorization system. API Access Controls and Gateways are responsible for the security of microservices.

- The failure of a microservice should be compensated and not harm the overall system.

- Monitoring and logging is becoming more complex.

Sign up for the newsletter below and don't miss any Taledo news!