Step-by-Step Transformation: Strangler Fig and Anti-Corruption Layer
Objectives
By the end of the lesson, you can explain how an existing system can be transformed gradually, and what role the strangler fig and the anti-corruption layer play in it.
Why gradually?
Replacing a complex system all at once is risky, and development coming to a halt in the meantime is a cost as well. Gradual transformation does not stop the working system but moves it onto the new structure function by function. The same holds when the goal is not microservices but, for example, a modular monolith.
Strangler fig
In 2001 Martin Fowler saw strangler fig trees in the Queensland rainforest — trees that germinate in a crack of a host tree and then grow their own roots and canopy — and the transformation pattern got its name from this. The essence of the pattern: the new behaviour is built next to the old, and the behaviour is moved over piece by piece until the old system can be retired.
According to the Azure Architecture Center, a façade (proxy) intercepts the requests and at first routes most of them to the old system, later more and more to the new one. When nothing depends on the old one any more, it is retired, and then the façade is removed too, or kept for the old clients.
flowchart LR
C["Client"] --> F["Façade (routing)"]
F -->|"old functions"| M["Existing system"]
F -->|"migrated functions"| N["New part"]
M --> O[("Old data")]
N --> D[("New data owner")]
Fowler's advice: start small, clarify the expected outcome in advance, find the "seams" where the system can be cut, and replace the small components first. Transitional code is extra work, but it reduces risk. The organisation must change as well, otherwise the new system will be just as rigid (Conway).
Switching the routing is only the visible step. According to the Azure description, the data used jointly by the old and new systems must be handled, the façade must not be left as a single point of failure or bottleneck, and dependencies between the systems must be handled too. It is especially dangerous to create two independent writers for the same business state during the transition.
Anti-corruption layer
When the new part communicates with the old, the old data model and system of meanings "corrupt" the new. The anti-corruption layer (ACL for short) is a façade or adapter between the two subsystems that translates the requests of one into the language of the other. Eric Evans described it in the book Domain-Driven Design. The new system talks to the ACL in terms of its own model, and the ACL talks to the old system in terms of its model.
According to the Azure description, the ACL means latency and one more component to manage, and one has to decide whether it is permanent or is retired at the end of the migration. It should only translate: business rules or orchestration should not go into it.
How does it relate to the others?
Gradual transformation can be used in the direction of splitting and of merging too. The strangler fig is about routing (entry point, 7.6), the ACL about translating meaning (boundary, 1.3). Before splitting into services it is worth taking the modulith step (2.4), because it uncovers the real calls and data needs.
Common misconceptions
Statement
Clarification
"The strangler fig belongs only to microservices."
It can be used for any gradual transformation.
"The ACL is just field renaming."
It also handles differences in meaning and errors.
"At the end of the migration the façade and the ACL always disappear."
They may also remain to serve old clients.
"Before splitting there is nothing else to do."
The internal boundaries have to be clarified first (2.4).
In short
The strangler fig moves functions gradually onto the new structure behind a façade.
The ACL translates between the models of the two subsystems so that the old one does not corrupt the new.
Switching the route is not the same as handing over the data.
Both patterns mean transitional infrastructure.
Review questions
Why is it not enough to switch the route when migrating a function?
What is the difference between the roles of the façade and the ACL?
Why is it worth building the modulith before splitting?
Step-by-Step Transformation: Strangler Fig and Anti-Corruption Layer
Objectives
By the end of the lesson, you can explain how an existing system can be transformed gradually, and what role the strangler fig and the anti-corruption layer play in it.
Why gradually?
Replacing a complex system all at once is risky, and development coming to a halt in the meantime is a cost as well. Gradual transformation does not stop the working system but moves it onto the new structure function by function. The same holds when the goal is not microservices but, for example, a modular monolith.
Strangler fig
In 2001 Martin Fowler saw strangler fig trees in the Queensland rainforest — trees that germinate in a crack of a host tree and then grow their own roots and canopy — and the transformation pattern got its name from this. The essence of the pattern: the new behaviour is built next to the old, and the behaviour is moved over piece by piece until the old system can be retired.
According to the Azure Architecture Center, a façade (proxy) intercepts the requests and at first routes most of them to the old system, later more and more to the new one. When nothing depends on the old one any more, it is retired, and then the façade is removed too, or kept for the old clients.
flowchart LR C["Client"] --> F["Façade (routing)"] F -->|"old functions"| M["Existing system"] F -->|"migrated functions"| N["New part"] M --> O[("Old data")] N --> D[("New data owner")]Fowler's advice: start small, clarify the expected outcome in advance, find the "seams" where the system can be cut, and replace the small components first. Transitional code is extra work, but it reduces risk. The organisation must change as well, otherwise the new system will be just as rigid (Conway).
Switching the routing is only the visible step. According to the Azure description, the data used jointly by the old and new systems must be handled, the façade must not be left as a single point of failure or bottleneck, and dependencies between the systems must be handled too. It is especially dangerous to create two independent writers for the same business state during the transition.
Anti-corruption layer
When the new part communicates with the old, the old data model and system of meanings "corrupt" the new. The anti-corruption layer (ACL for short) is a façade or adapter between the two subsystems that translates the requests of one into the language of the other. Eric Evans described it in the book Domain-Driven Design. The new system talks to the ACL in terms of its own model, and the ACL talks to the old system in terms of its model.
According to the Azure description, the ACL means latency and one more component to manage, and one has to decide whether it is permanent or is retired at the end of the migration. It should only translate: business rules or orchestration should not go into it.
How does it relate to the others?
Gradual transformation can be used in the direction of splitting and of merging too. The strangler fig is about routing (entry point, 7.6), the ACL about translating meaning (boundary, 1.3). Before splitting into services it is worth taking the modulith step (2.4), because it uncovers the real calls and data needs.
Common misconceptions
In short
Review questions
Learning resources