Bei Anwendung des Musters werden innerhalb des Monolithen klar abgrenzbare Funktionsblöcke identifiziert, herausgelöst und in eigenständige Services verschoben. Extrahierte Services erhalten z.B. über HTTP-APIs, Event-Broadcasting oder Datenbank-Trigger Zugriff auf die Daten des Monolithen. Eine wichtige Prämisse des Strangler-Vorgehens ist, dass der Monolith nur noch geändert wird, wenn dies absolut notwendig ist. Der Name des Pattern soll zum Ausdruck bringen, dass der Monolith nach und nach von seinen extrahierten und ihn umgebenden Services erwürgt (strangle) wird.
Wann passt das Muster?
Die Anwendung von Strangler Fig besitzt eine organisatorische und eine Software-technische Rechtfertigung. Auf organisatorischer Ebene eignet sich das Muster für das Aufteilen grosser Entwicklungsteams. So ist es einfacher, zwei Fünf-Personenteams an zwei möglichst unabhängigen Systemteilen arbeiten zu lassen, als die Arbeit von zehn Entwickler:innen an einem schlecht wartbaren Monolithen zu koordinieren.
Auf technischer Ebene ist der Einsatz des Musters gerechtfertigt, wenn einzelne Module unterschiedliche Architekturcharakteristiken besitzen. So unterliegt z.B. die Registrierung eines Webshops geringeren Skalierungsanforderungen, als die Produktsuche des Shops. Werden beide Module als dedizierte Services betrieben, können die Skalierungsanforderungen des jeweiligen Services gezielt umgesetzt werden.
Wann passt das Muster nicht?
Monolithische Architekturen gelten gemeinhin als unmodern oder uncool. Das ist falsch und sollte nicht als Begründung dafür dienen, den Monolithen in Services zu zerlegen. Das gleiche gilt für schlecht wartbare Monolithen. Es liegt ein grosser Reiz darin, nicht wartbare Module in Services zu extrahieren und auf der grünen Wiese neu zu entwickeln. Die Entwicklung geht anfangs schnell von der Hand, Seiteneffekte werden minimiert. Der anfängliche Produktionsgewinn kann mittelfristig ins Negative drehen. Neue Probleme, wie Latenzen, Fehlerbehandlung über Prozessgrenzen hinweg oder verteilte Transaktionen heben die Komplexität auf eine neue Ebene. Ein nicht wartbarer Monolith kann so sehr schnell zu einem noch weniger wartbaren Microservice-System werden. Für die Remodularisierung unter Beibehaltung des Architekturstils ist Branch by Abstraction ein geeigneteres Muster.