Strangler Fig mit Symfony: Altsystem schrittweise ablösen, ohne Big-Bang-Umstellung

Inhalt

1. Ausgangslage: Warum der Big Bang so oft scheitert
2. Drei Wege, ein Altsystem abzulösen
3. Woran Sie erkennen, ob Strangler Fig für Sie trägt
4. Betrieb während der Ablösung
5. Der erste Schritt

Die Entscheidung ist gefallen: Das Altsystem muss weg. Es läuft auf einer veralteten PHP-Version, kaum jemand traut sich noch an den Code, neue Anforderungen dauern Wochen. Der naheliegende Plan ist ein Neubau, der an einem Stichtag das alte System ersetzt. Auf dem Papier wirkt das sauber. In der Praxis bedeutet es Monate oder Jahre, in denen das neue System keinen Nutzen bringt, während das alte weiter Pflege braucht. Und am Stichtag hängt alles an einer einzigen Umstellung, die selten ohne Überraschungen gelingt.

Es gibt einen anderen Weg, der seit über zwanzig Jahren beschrieben ist und in der Praxis oft unterschätzt wird. Martin Fowler hat ihn 2004 als Strangler Fig Application beschrieben: Ein neues System entsteht um die Ränder des alten herum und übernimmt so lange Aufgaben, bis das alte nicht mehr gebraucht wird. Ob Sie neu bauen oder umbauen sollten, beantwortet der Artikel Rewrite oder Refactoring. Was an einem Altsystem modernisiert werden sollte, steht in Legacy-PHP modernisieren. Dieser Artikel behandelt die Frage danach: Wie gelingt die Ablösung im laufenden Betrieb?

Ausgangslage: Warum der Big Bang so oft scheitert

Eine Komplettumstellung setzt voraus, dass das neue System am Stichtag alles kann, was das alte konnte. Das klingt selbstverständlich, ist aber der schwierigste Teil. Altsysteme enthalten über Jahre gewachsene Sonderfälle, die nirgends dokumentiert sind. Viele davon werden erst entdeckt, wenn sie nach der Umstellung fehlen.

Dazu kommt ein wirtschaftliches Problem. Während des Neubaus läuft das alte System weiter und muss gepflegt werden, weil das Geschäft nicht stillsteht. Neue Anforderungen landen entweder im alten System, das eigentlich abgelöst werden soll, oder sie warten auf das neue, das noch nicht fertig ist. Beides kostet. Und je länger der Neubau dauert, desto weiter entfernt er sich vom aktuellen Stand des Altsystems.

Fowler nennt das geringere Risiko als den wichtigsten Grund, eine Strangler Fig Application einer Komplettumstellung vorzuziehen. Das Risiko verschwindet dabei nicht. Es wird auf viele kleine Schritte verteilt, von denen jeder einzeln rückgängig gemacht werden kann.

Drei Wege, ein Altsystem abzulösen

Option 1: Komplettumstellung zum Stichtag

Das neue System wird parallel entwickelt und ersetzt das alte an einem Tag. Der Vorteil: eine klare Trennung, keine Übergangsarchitektur, kein Betrieb zweier Systeme im Verbund. Der Nachteil: Der Nutzen entsteht erst am Ende. Bis dahin ist das gesamte Budget gebunden, ohne dass ein Teil davon produktiv wirkt. Geht am Stichtag etwas schief, betrifft es das ganze System. Für kleine Anwendungen mit überschaubarem Funktionsumfang kann dieser Weg trotzdem der günstigste sein.

Option 2: Refactoring im Altsystem

Das bestehende System wird von innen heraus verbessert: Abhängigkeiten aktualisieren, Code aufteilen, Tests ergänzen. Das funktioniert, solange die Grundarchitektur tragfähig ist. Bei sehr alten Systemen ohne Framework oder mit einer Struktur, die jede Änderung über das ganze System verteilt, stößt Refactoring an Grenzen. Dann wird jeder Schritt teurer als der vorherige.

Option 3: Strangler Fig mit Symfony als Fassade

Vor das Altsystem wird eine Symfony-Anwendung geschaltet. Sie nimmt alle Anfragen entgegen und entscheidet, was sie selbst beantwortet und was sie an das Altsystem weiterreicht. Am Anfang reicht sie fast alles weiter. Mit jeder abgelösten Funktion übernimmt sie mehr. Fowler nennt dieses Abfangen Event Interception. Für den Nutzer ändert sich an der Adresse nichts.

Technisch ist der Kern überschaubar. Eine Route am Ende der Routing-Tabelle leitet alles, was die neue Anwendung noch nicht kennt, an das Altsystem weiter:

// Fallback-Controller: Alles, was Symfony noch nicht selbst beantwortet,
// geht unverändert an das Altsystem. Mit jeder abgelösten Funktion
// greift dieser Controller seltener.
#[Route('/{path}', requirements: ['path' => '.*'], priority: -100)]
final class LegacyProxyController
{
    public function __construct(private HttpClientInterface $legacyClient) {}

    public function __invoke(Request $request): Response
    {
        $response = $this->legacyClient->request(
            $request->getMethod(),
            $request->getRequestUri(),
            ['headers' => $request->headers->all(), 'body' => $request->getContent()],
        );

        return new Response(
            $response->getContent(false),
            $response->getStatusCode(),
            $response->getHeaders(false),
        );
    }
}

In der Praxis kommen Sitzungen, Cookies und Authentifizierung dazu, die beide Systeme teilen müssen. Oft wird das Routing auch eine Ebene tiefer im Webserver gelöst. Das Beispiel zeigt trotzdem den entscheidenden Punkt für die Entscheidung: Die Fassade ist schnell produktiv und bringt das Altsystem nicht aus dem Gleichgewicht.

Danach übernimmt die neue Anwendung fachliche Einheiten nacheinander, etwa zuerst das Kundenkonto, dann die Bestellübersicht. Fowler beschreibt dieses Vorgehen als Asset Capture. Zwei Techniken nutze ich dabei regelmäßig, auch wenn sie nicht aus Fowlers Originaltext stammen. Mit Branch by Abstraction wird im Altsystem eine Schnittstelle eingezogen, hinter der sich alte und neue Umsetzung austauschen lassen. Bei einem Parallel Run laufen alte und neue Umsetzung eine Zeit lang gleichzeitig und ihre Ergebnisse werden verglichen, bevor die neue allein entscheidet.

Wirtschaftlich verschiebt Strangler Fig den Nutzen nach vorn. Jede abgelöste Einheit ist sofort produktiv. Der Preis dafür ist eine Übergangszeit, in der zwei Systeme gemeinsam betrieben werden und die Fassade selbst Pflege braucht.

Woran Sie erkennen, ob Strangler Fig für Sie trägt

Gibt es eine Stelle, an der sich Anfragen abfangen lassen?

Webanwendungen bringen diese Stelle fast immer mit: die HTTP-Anfrage. Bei Systemen, die über Cronjobs, Dateiimporte oder direkte Datenbankzugriffe anderer Programme arbeiten, ist es schwieriger. Dort muss die Abfangstelle erst geschaffen werden, was den Einstieg teurer macht.

Lässt sich das Altsystem in fachliche Einheiten schneiden?

Strangler Fig lebt davon, dass sich ein Teil ablösen lässt, ohne alle anderen gleichzeitig anzufassen. Wenn jede Funktion direkt in dieselben Tabellen schreibt und von denselben globalen Variablen abhängt, ist der erste Schnitt die eigentliche Arbeit. Ein Code-Audit zeigt, wie hoch diese Hürde ist. Worauf dabei zu achten ist, beschreibt der Risiko-Check vor der Projektübernahme.

Muss das Altsystem während der Ablösung weiterentwickelt werden?

Wenn ja, spricht das für Strangler Fig. Neue Anforderungen können direkt in der neuen Anwendung umgesetzt werden, statt im Altsystem zu landen. Bei einer Komplettumstellung müssten sie entweder doppelt gebaut werden oder warten.

Ist das Altsystem groß genug, dass sich die Fassade lohnt?

Die Fassade ist eine zusätzliche Schicht, die gebaut und betrieben werden muss. Bei einer kleinen Anwendung mit wenigen Funktionen übersteigt dieser Aufwand schnell den Nutzen. Dann ist ein geplanter Umstieg ehrlicher.

Wer die ersten drei Fragen mit Ja beantwortet und die vierte ebenfalls, hat einen guten Kandidaten für Strangler Fig. Wer schon an der ersten Frage scheitert, sollte zuerst klären, ob sich eine Abfangstelle schaffen lässt, bevor er sich für das Muster entscheidet.

Betrieb während der Ablösung

Ein Punkt wird bei der Planung oft unterschätzt: Während der Ablösung laufen zwei Systeme. Das alte braucht weiter Sicherheitsupdates, das neue wächst. Die Fassade dazwischen ist ein eigenes Stück Software mit eigenem Wartungsbedarf. Fällt sie aus, sind beide Systeme nicht erreichbar.

Genau deshalb sollte die Ablösung nicht getrennt vom Betrieb geplant werden. Wer das Altsystem pflegt, muss wissen, welche Teile bald abgelöst werden, damit dort kein unnötiger Aufwand entsteht. Wer die neue Anwendung baut, muss wissen, wann im Altsystem Sicherheitsupdates anstehen. Am einfachsten ist das, wenn beides in einer Hand liegt oder in einem gemeinsamen Wartungsvertrag mit festem Patch-Takt geregelt ist.

Der erste Schritt

Eine Strangler-Fig-Ablösung beginnt nicht mit einem Architekturkonzept für das gesamte neue System. Sie beginnt mit zwei Fragen: Wo lassen sich Anfragen abfangen? Und welche fachliche Einheit ist am wenigsten verflochten und bringt trotzdem spürbaren Nutzen, wenn sie neu gebaut wird? Diese Einheit wird die erste. Sie zeigt im Kleinen, ob Fassade, Sitzungsübergabe und Datenzugriff funktionieren. Danach wird jeder weitere Schritt leichter, weil die Grundlage steht. Wer diesen Weg mit Unterstützung gehen will, findet unter Legacy-Migration und Symfony-Individualentwicklung den Einstieg.