Often there is a concept for the final target architecture that the migration should achieve, but no concrete plan for the first steps to be taken or for the first microservices to be implemented.

In particular, the small steps into which development can be broken down are a major advantage of microservices. A simple microservice is written quickly. Because of its small size, it is also easy to deploy. And if the microservice should not prove itself, not much effort has gone into the microservice and it can easily be removed again.

In the further course of the project, the new architecture can be implemented step by step, microservice by microservice. In this way, the team will avoid large risks.

Because the migration process depends on the goals and on the structure of the legacy system, there is no universal approach. Therefore, the strategy presented here must not simply be used as is but must be adapted to the respective situation.

A typical scenario #

A typical scenario for a migration to microservices is:

  • The aim of the migration is to increase the development speed.

    • Microservices need fewer tests for a release and provide easier continuous delivery because they are smaller.
    • Also, the development of individual microservices is quite independent, so less time is spent on coordination. All of this can make development faster.

  • The migration to microservices must provide an advantage in development as quickly as possible. It makes no sense to invest in an architectural change that only leads to improvement much later down the line.

The migration strategy proposed here is based on extracting individual microservices in order to achieve an improvement of the situation as quickly as possible. Have a look at the drawing below for a visual.

Get hands-on with 1200+ tech skills courses.