"Who gets the job of pushing the knob? That sort of responsibility you draw straws for, if you're mad enough“ - The Stranglers - "It's always the sun"
Im Zeitalter digitaler Kannibalisierung im E-Commerce ist es für Entscheider in deutschen Mittelstandsunternehmen von immer größerer Bedeutung, mit modernen Architekturen Schritt zu halten und die eigene digitale Transformation voranzutreiben. Doch wie gelingt es, die bestehende Softwarelandschaft aufzubrechen und den Weg in eine agilere und zukunftssichere Unternehmensstruktur zu ebnen? Was haben die Würgefeige und Software-Systeme gemeinsam?
Die Arbeitsweise eines "Würgers" (engl. "strangler") ist nur bedingt geeignet, um den Weg in eine sonnige Zukunft zu beschreiben. Aber manchmal muss man neue Wege gehen, sich über Altbewährtes hinwegsetzen und auch mal "über (Software-)Leichen gehen". Die Natur macht das ganz einfach: Immer der Sonne entgegen! So macht es z.B. auch die Würgefeige (engl. "strangler fig"), die im tropischen Regenwald angestammte, alte Bäume durch Umklammerung "erwürgt" und sich so ihren Weg ans Licht erkämpft. Die alten Bäume sterben mit der Zeit ab und es bleibt eine Würgefeige übrig, der man die ehemals umschlungene Stütze nur noch indirekt ansieht.
Wie kann man das auf etablierte Software-Systeme und deren Ablösung übertragen?
Diese Analogie zur Würgefeige gebrauchte der britisch-amerikanische Autor und anerkannte Software-Architektur-Papst Martin Fowler für sein Architektur-Muster der "Strangler (Fig) Application", einer Software-Applikation die nach und nach die Funktion alter, monolithisch gewachsener Software-Systeme übernimmt. Dieses Architektur-Muster bzw. die Analogie zur Würgefeige ist fast 20 Jahre alt. 15 Jahre nach dem initialen Post änderte Martin Fowler den Begriff von "Strangler Application" zu "Strangler Fig Application", um die teilweise brutal gedeutete Analogie zu einem Würger mehr in Richtung des Verhaltens der Würgefeige interpretiert zu wissen.
Zwei wichtige Aspekte, die in diesem Muster (der Natur) steckt, sind Ressourcenoptimierung und Risikominimierung. Wieviel schneller könnte eine neue Pflanze in den Himmel wachsen, wenn man vorher die Wurzeln der angestammten Platzhalter kappt und das "Stützkorsett" aus dem Weg räumt? Könnte die Würgefeige "eigenständig" der Sonne entgegen in den Himmel wachsen oder würde sie eher seitlich wegknicken? Wieviel Biomasse müsste die Pflanze selbst aufbringen, um in die gleiche Höhe oder darüber hinaus zu wachsen? Wieviel Sauerstoff würde nicht erzeugt werden, würde man die bisherigen Produzenten mit einem Axthieb direkt zum Start beseitigen?
Modernisierung einer Software-Architektur: Ein pragmatischer Ansatz zur Migration von Monolithen zu Microservices
Am Anfang steht immer zuerst die Entscheidung, neue Wege zu gehen und sich über etablierte, monolithisch gewachsene Software-Architekturen hinweg setzen zu wollen.
Eine grobe Vorgehensweise, um eine Migration von Services vom Monolithen in eine neue Service-Architektur zu überführen, umfasst folgende Phasen:
- Analyse und Aufteilung: Identifizieren Sie Geschäftsbereiche, trennen Sie Komponenten und definieren Sie unabhängige Microservices. Vereinfachen Sie Ihre Anwendung und berücksichtigen Sie auch die Datenbasis und Zugriffssteuerungen.
- Schnittstellen und Kommunikation: Definieren Sie klare Kommunikationsprotokolle und Schnittstellen zwischen Microservices. Wählen Sie RESTful APIs, Message Queues oder Event-Streaming basierend auf den Anforderungen und dem Know-how Ihres Teams oder des Teams der ausgewählten Dienstleisters.
- Schrittweise Migration und Überwachung: Führen Sie die Migration schrittweise durch und überwachen Sie den Fortschritt. Sichern Sie Datenkonsistenz, beheben Sie Probleme und gewährleisten Sie eine nahtlose Umstellung.
Im Sinne von Conway's Law, welches besagt, dass Kommunikationswege und Organisationsstrukturen in einem Unternehmen sehr häufig auch das Design und die Entstehung der verwendeten Software-Systeme beeinflussen oder sogar limitieren, sollte man auch einen Blick auf diesen Aspekt in einem Unternehmen werfen oder noch besser: von außen auf das Unternehmen werfen lassen.
Wie sieht das software-technische Fundament dieser Services aus?
Der Aufbau einer sogenannten MACH-Service-Architektur (Akronym für „Microservices-based, API-first, Cloud-native und Headless“) z.B. in einem Managed Kubernetes Service (AKS) in Azure oder einem Amazon Elastic Kubernetes Service (Amazon EKS) ist ein idealer Nährboden für neue Triebe und die Ausdünnung der "Schwergewichte" im Dickicht des bestehenden Software-Dschungels. Die Flexibilität eines AKS- oder EKS-Clusters ermöglicht auch eine parallele Bearbeitung und Inbetriebnahme verschiedener Services von mehreren Entwicklungs-Teams.
Ein Beispiel für die Anwendung des "Strangler Fig Patterns" und die Verwendung eines Managed Kubernetes Service (AKS) in Azure ist das Produkt-Portal für Architekten und Planer der Firma Hörmann, das zusammen mit communicode umgesetzt wurde.
Mehr Infos zu Composable-Business und -Commerce durch MACH-Architektur finden Sie hier in unserem Blog.
Bei Fragen zu modernen Architekturen, Technologien, aber auch für ein Gespräch über "Musik in der IT" stehe ich gerne zur Verfügung.
Author
