2020-07-04 17:05:46 +08:00
|
|
|
---
|
|
|
|
|
layout: pattern
|
|
|
|
|
title: Strangler
|
|
|
|
|
folder: strangler
|
|
|
|
|
permalink: /patterns/strangler/
|
|
|
|
|
categories: Structural
|
2021-05-19 10:49:05 -06:00
|
|
|
language: en
|
2020-07-04 17:05:46 +08:00
|
|
|
tags:
|
|
|
|
|
- Extensibility
|
2020-07-26 11:30:42 +03:00
|
|
|
- Cloud distributed
|
2020-07-04 17:05:46 +08:00
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Intent
|
|
|
|
|
Incrementally migrate a legacy system by gradually replacing specific pieces of functionality
|
|
|
|
|
with new applications and services. As features from the legacy system are replaced, the new
|
|
|
|
|
system eventually covers all the old system's features and may has its own new features, then
|
|
|
|
|
strangling the old system and allowing you to decommission it.
|
|
|
|
|
|
|
|
|
|
## Class diagram
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Applicability
|
|
|
|
|
This strangler pattern is a safe way to phase one thing out for something better, cheaper, or
|
|
|
|
|
more expandable. Especially when you want to update legacy system with new techniques and need
|
|
|
|
|
continuously develop new features at the same time. Note that this pattern indeed need extra effort,
|
|
|
|
|
so usually use it when the system is not so simple.
|
|
|
|
|
|
|
|
|
|
## Credits
|
|
|
|
|
|
2020-07-26 11:30:42 +03:00
|
|
|
* [Strangler pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler)
|
2020-07-04 17:05:46 +08:00
|
|
|
* [Legacy Application Strangulation : Case Studies](https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/)
|
