Microservices and Legacy Applications
The transformation of a legacy application into a microservice-based architecture is a scenario that is frequently met with in practice. Completely new developments are rather rare, and microservices, first of all, promise advantages for long-term maintenance. This is especially interesting for applications that are already on the brink of not being maintainable anymore. Besides, the distribution into microservices makes possible easier handling of continuous delivery: Instead of deploying and testing a monolith in an automated fashion, small microservices can be deployed and tested. The expenditure for this is by far lower. A continuous delivery pipeline for a microservice is not very complex; however, for a deployment monolith the expenditure can be very large. This advantage is sufficient for many companies to justify the effort of migrating to microservices.
In comparison to building up completely new systems, there are some important differences when migrating from a deployment monolith to microservices:
- • For a legacy system the functionality is clear from the domain perspective. This can be a good basis for generating a clean domain architecture for the microservices. Such a clean domain-based division is especially important for microservices.
- • However, there is already a large amount of code in existence. The code is often of bad quality. There are few tests for the code, and deployment times are often much too long. Microservices should remove these problems. Accordingly, the challenges in this area are often significant.
- • Likewise, it is well possible that the module boundaries in the legacy application do not answer to the Bounded Context idea (see section 3.3). In that case migrating to a microservice-based architecture is a challenge because the domain-based design of the application has to be changed.