Treat the Legacy System as Microservice
Context
The system (called the legacy system) shall be migrated to a microservice-based architecture. The legacy system has a similar API to the microservices, or it is feasible to use the communication protocol of the legacy system within the microservices next to the one used between the microservices.
Problem
- A re-implementation of the whole system is not feasible due to too high risks and a too long break in return of invest.
Solution
Treat the legacy system as another microservice for the migration.
An implementation of this technique can be combined with an internal integration proxy. Like other microservices, the APIs of the legacy system can be registered at the internal integration proxy, enabling easy switching to a later re-implementation as a microservice.
This technique can facilitate the technique Gradually Replace the Legacy System. The following techniques might pose an alternative to this technique:
- ESB to Decouple From the Legacy System if the legacy system is a service-oriented architecture (SOA).
- Proxy microservices if your legacy system does not reach the required availability needs (under load).
Maturity
More data is required (only 1 source).
Sources of Evidence
L25:
- Citation to a report where SOA system migrated to microservices
- legacy was accessed like any other microservice
- overarching service registry
- ease of migration => switch points to new microservice instead of legacy system
- patterns for migrationg monolithic applications: service registry pattern
- patterns for migrating SOA applications: hybrid pattern