Die Evolution zur MACH-Architektur

Good to know: Dies ist eine Verschriftlichung der Keynote von Christoph Hautzinger, unserem Managing Director Engineering, im Rahmen der MACH Masterclass 2024.

Die Frage, mit welcher Architektur eine Software gebaut werden soll, ist ebenso eine philosophische Frage, wie die Frage nach dem Umgang mit technischen Abhängigkeiten. Ansätze und Lösungen gibt es wie Sand am Meer – und doch kristallisiert sich ein Framework heraus, das sich als besonders skalierbar und zukunftssicher erweist. Die Rede ist von MACH. Denn MACH macht einiges möglich. Wie sich bereits existierende Systeme Schritt für Schritt in eine MACH-Architektur überführen lassen, haben wir hier in 4 Evolutionsstufen aufgeführt. 

Abhängigkeiten innerhalb von technischen Systemen

Starten wir mit der Frage, wie mit technischen Abhängigkeiten umgegangen werden soll. Oft sieht man hier folgendes Bild: Wir haben eine Komponente A und eine Komponente B, wobei B von A abhängig ist. Das bedeutet, dass Änderungen an A auch Anpassungen an B erfordern. Idealerweise würde A stabil bleiben, sodass B häufiger modifiziert werden kann. Die Realität sieht jedoch oft anders aus: Ein externes System D (wie Typo3, eine Symfony-Anwendung, Magento oder ein anderes Vendor-System) ist im Spiel. Der innerhalb dieses Systems geschriebene Code ist stets von diesem externen System abhängig. Das Problem dabei ist, dass sich das Vendor-System durch regelmäßige Updates ständig verändert. Diese Updates erfordern wiederum oft Anpassungen am eigenen Code.

Traditionelle monolithische Systeme

In der traditionellen Softwarearchitektur finden wir oft monolithische Systeme.  Ein klassisches Beispiel wäre ein CMS wie Typo3, bei dem die gesamte Geschäftslogik, Präsentationsschicht und Datenpersistenz eng miteinander verbunden sind. Diese enge Kopplung bringt einige Vorteile mit sich, wie die einfache Nutzung vorhandener Frameworks und Tools sowie schnelle Ergebnisse für Entwickler:innen, insbesondere für Einsteigende.

Allerdings gibt es auch erhebliche Nachteile: 

• Hohe Abhängigkeit: Änderungen in einem Teil des Systems erfordern oft Anpassungen in mehreren anderen Teilen, was die Wartung und Weiterentwicklung erschwert.

• Schlechte Skalierbarkeit: Die Skalierung eines monolithischen Systems ist komplizierter, da alle Komponenten miteinander verknüpft sind.

• Langsame Anpassung an neue Trends: Moderne Anforderungen wie die Core Web Vitals von Google sind schwer zu implementieren, da das gesamte System angepasst werden muss.

In der dynamischen Welt der Softwareentwicklung ist Flexibilität entscheidend. Die MACH-Architektur (Microservices, API-first, Cloud-native, Headless) bietet hierfür eine moderne Lösung. In diesem Beitrag betrachten wir die verschiedenen Stufen auf dem Weg zur MACH-Architektur und die jeweiligen Vorteile.

In unserem MACH-Check sind demnach beim traditionellen monolithischen System noch alle Ampeln auf rot.

Stufe 1: Entkopplung der Präsentationsschicht

Der erste Schritt zur MACH-Architektur ist die Entkopplung der Präsentationsschicht. Dabei wird zunächst das Frontend herausgelöst und UI-Komponenten werden so in ein separates Projekt ausgelagert. Mit Hilfe moderner Tools und Techniken können Entwickler:innen moderne Frameworks und Tools nutzen, was die Developer Experience verbessert.

Das Frontend kann als statische Datei über ein CDN bereitgestellt werden, was die Performance erhöht. Insgesamt hat das Herauslösen des Frontends den großen Vorteil einer verbesserten Performance. Schnellere Ladezeiten durch verteilte Bereitstellung über ein CDN verbessern zudem die User Experience. Außerdem kann die Frontend-Entwicklung unabhängig vom Backend erfolgen, wodurch die Flexibilität erhöht wird.

Ganz ohne Herausforderungen kommt diese erste Stufe allerdings nicht: Die Verwaltung einer separaten Frontend-Infrastruktur erfordert zusätzliche Tools und Kenntnisse. Außerdem werden für die erhöhten technischen Anforderungen bei der Frontend-Entwicklung spezialisierte Frontend-Expert:innen benötigt. 

In unserem MACH-Check springt die Headless-Ampel demnach schon auf grün und API-First sowie Cloud-Native noch auf gelb. Die Microservices-Ampel leuchtet jedoch noch rot.

Stufe 2.1: Entkopplung der Geschäftslogik

Der nächste Schritt ist die Entkopplung der Geschäftslogik vom monolithischen System. Das technische Detail, das hierbei im Fokus steht, ist die “Inversion of Control”. Das heißt: die Abhängigkeiten werden umgekehrt, sodass die Geschäftslogik nicht länger Teil des Vendor-Systems ist. In der Anwendung führt dies dazu, dass die Anfragen aus dem Frontend über kleine Entrance-Punkte an die Geschäftslogik delegiert werden.

Vorteil dieser Entkopplung ist, dass Änderungen in der Geschäftslogik unabhängig vom Rest des Systems durchgeführt werden können. Bei Updates müssen innerhalb des Vendor-Systems auch nur die kleinen Integrationspunkte angepasst werden, die die Anfragen an die Geschäftslogik delegieren.. 

Anzumerken ist, dass diese Inversion of Control sorgfältige Planung und Expertise erfordert. Um sicherzustellen, dass die Geschäftslogik richtig entkoppelt und integriert wird, ist ein außerdem fortgeschrittene Software-Achitektur-Expertise notwendig.

Die Ampeln in unserem MACH-Check bleiben allerdings noch gleich wie in der Stufe zuvor, da lediglich die Abhängigkeit zwischen Vendor-System und Geschäftslogik umgekehrt wird. 

Stufe 2.2: Einführung von API-first und Microservices

In der dritten Ausbauphase wird die Geschäftslogik weiter in einen Microservice ausgegliedert und über APIs bereitgestellt. Demnach ist das Vendor-System nur noch auf die eigentliche Funktionalität beschränkt und hat nur noch eine Zuständigkeit. Somit greift das erstrebenswerte “Single Responsibility Principle” – denn je weniger Zuständigkeiten eine Komponente hat, desto besser. Der API-first Ansatz beschreibt, dass die einzelnen Komponenten über klar definierte APIs kommunizieren. Dabei wird jede Funktionalität als eigenständiger Microservice implementiert, was die Modularität erhöht.

Vorteilhaft an diesem Ansatz ist, dass APIs eine saubere Trennung der Komponenten ermöglichen und die Entwicklung durch klare Schnittstellen erleichtern. Auch die Flexibilität wird erheblich verbessert: Komponenten können unabhängig voneinander entwickelt, ausgetauscht und skaliert werden.

Teilweise kann es auch hier zu Herausforderungen kommen, da die Verwaltung und Dokumentation der APIs zusätzliche Ressourcen und Tools erfordert. Unterschiedliche Teams müssen außerdem gut koordiniert arbeiten, um konsistente APIs zu gewährleisten.

Im MACH-Check springt nun auch die Microservices-Ampel auf gelb, somit begeben wir uns immer mehr in Richtung MACH-Architektur.

Stufe 3: Vollständige MACH-Architektur

Die letzte Stufe ist die vollständige Implementierung der MACH-Prinzipien:

On Top zur Nutzung von Microservices und dem API-first Ansatz kommt auf dieser Stufe die Cloud-native Infrastruktur. Die gesamte Architektur wird in der Cloud betrieben, um die Vorteile der Cloud-Infrastruktur voll auszuschöpfen. Außerdem ist das Frontend vollständig vom Backend entkoppelt und kommuniziert ausschließlich über APIs (-> es ist headless).

Das bedeutet, dass in dieser Evolutionsstufe sogar der Vendor mit einem modernen System ausgetauscht werden kann. So wird der “Best of Breed”-Ansatz komplett gelebt: Je nach Use Case (z.B. für das Content Management System selbst) können verschiedene Optionen geprüft und das Bestehende mit der besten Lösung ausgetauscht werden. Die gesamte Architektur ist dadurch hochgradig flexibel und kann einfach skaliert werden.

An dieser Stelle sollte angemerkt werden, dass die Infrastruktur so natürlich recht komplex ist. Die Verwaltung einer cloud-nativen, microservice-basierten Architektur erfordert fortgeschrittene Kenntnisse und spezialisierte Tools. Es macht also Sinn, Entwicklungs-Expertise an Bord zu haben, die mit den neuesten Technologien und Konzepten vertraut sind. 

Und im MACH-Check sind nun alle Ampeln auf grün – wir sind also endlich in der MACH-Welt angekommen.

Fazit

Die Transformation zur MACH-Architektur kann in mehreren Stufen erfolgen: von der Entkopplung der Präsentationsschicht bis hin zur vollständigen Implementierung aller MACH-Prinzipien. Jede Stufe bringt ihre eigenen Vorteile und Herausforderungen mit sich, bietet jedoch insgesamt eine modernere, flexiblere und skalierbarere Architektur. Durch die schrittweise Einführung dieser Konzepte können Unternehmen ihre Systeme zukunftssicher gestalten und schneller auf technologische Veränderungen reagieren.