Lesezeit: 2 Minuten

MACH & Headless

Die Themen MACH und Headless sind nicht neu. Neu ist aber die große Aufmerksamkeit, die dem Thema gewidmet wird. Aber was genau ist MACH überhaupt?

Was genau ist MACH?

MACH ist ein Akronym und steht für

M icroservices: alle Funktionen und Services können unabhängig entwickelt und bereitgestellt werden
A PI-first: alle Funktionen werden über eine API gesteuert
C loud-native SaaS (Software as a Service)
H eadless: Frontend und Backend funktionieren entkoppelt voneinander

Microservices sind eigenständige Dienste, die spezifische Funktionen liefern. Der Vorteil dabei ist, dass diese getrennt voneinander entwickelt werden können und bei Bedarf auch wesentlich einfacher erweitert oder ausgetauscht. Die Microservices sprechen über APIs miteinander. Das ermöglicht, dass diese technologisch voneinander getrennt entwickelt werden können.

Über APIs wird auf alle beteiligten Headless-Systeme zugegriffen und die Daten werden für eine gerätespezifische Ausgabe aufbereitet. (Beispielsweise Inhalte aus CMS-, Shop- oder PIM-Systemen die via JSON-API's mithilfe der Vue- und Nuxt-Frameworks gerendert werden.)

Cloud-native beschreibt, dass diese Systeme einerseits nur in der Cloud betrieben werden können. Architektonisch bedingt ist es nun möglich nur einzelne Services skalieren zu lassen, wenn dies benötigt wird. Warum sollten Sie auch Ihr PIM skalieren, nur weil es gerade viele Zugriffe auf den Warenkorb gibt. Das spart im Betrieb viele Ressourcen und somit auch Kosten für die Betreiber:innen.

Headless ist kein CMS. Es ist auch keine Website, kein Online-Shop und kein CRM. Headless ist ein Bestandteil von MACH und beschreibt eine Architektur, in der Systeme Daten und Strukturen vorhalten und die spezifische Ausgabe dieser Daten in einer getrennten Schicht erfolgt. Die einzelnen Headless-Systeme werden in der Darstellung über APIs miteinander verbunden und gewähren somit eine durchgehende Nutzer:innen-Erfahrung ohne Medienbrüche, etc.. Anbieter:innen haben dadurch vereinfachte Möglichkeiten, Inhalte und Angebote aus verschiedenen Systemen zu verbinden und damit wesentlich relevantere Angebote zu schaffen.

Gibt es auch monolithische Systeme, die headless betrieben werden können?

Viele monolithische Systeme sind bereits für einen Headless-Betrieb vorbereitet und konzipiert. Eine Reihe von Systemen werden zudem auch durch Erweiterungen headless-fähig und stellen Ihre Daten per API zur Verfügung. Das gilt beispielsweise auch für das bewährte und verbreitete CMS TYPO3. Dies bietet den Vorteil, dass monolithische Bestandssysteme mit allen headlessfähigen Systemen verknüpft werden können. Dadurch wird auch der schrittweise Umstieg von monolithischen zu MACH-Systemen erleichtert.

Was macht den Unterschied?

Der frühere Ansatz macht den - in den meisten Fällen zu bevorzugende - Best-of-Breed Ansatz komplex, risikoreich und fehleranfällig, da letztendlich immer ein führendes System definiert werden musste. Der unterschiedliche Ansatz der Systeme bezüglich des Datenhandlings bzw. der Architektur verkomplizieren dies zusätzlich. Möchte man einen Online-Shop integrieren und die Shopdaten über ein PIM verwalten, müssen alle Systeme tief miteinander verknüpft werden. Dadurch stellen technische Upgrades einzelner (Teil-)Systeme auch immer ein zusätzliches Risiko dar. Will man die enthaltenen Daten dann noch für weitere Zwecke nutzen, um mobile Apps, IoT (Internet of Things), Smart Home oder Sonstiges zu bedienen, werden die technischen Hürden entsprechend größer und noch komplexer.

Hier mal eine Gegenüberstellung:

Was sind die Vorteile von MACH?

Da gibt es so einiges. Wir versuchen uns mal an einer Aufzählung:

• Updates werden im Gegensatz zu monolithischen Systemen sehr viel einfacher und kostengünstiger, da nur Teilbereiche oder Services aktualisiert werden müssen. Der Rest bleibt unberührt. In MACH-Systemen werden Updates nach Bedarf ausgerollt und haben keine Abhängigkeiten zu anderen Services.
• Systeme können in jeder erdenklichen Kombination miteinander über diverse APIs kommunizieren.
• MACH unterstützt den Best-of-Breed-Ansatz in optimaler Weise, da die Systeme über definierte APIs miteinander kommunizieren und die Architektur der Systeme und Services sich unterscheiden kann.
• Durch optimiertes Caching werden auch Offline-Funktionalitäten möglich, Stichwort PWA (Progressive Web App).
• Werden Datensätze geändert, aktualisieren sich diese in jedem System, welches diese Daten nutzt.
• Zum Thema IT-Sicherheit: Die Daten werden dezentral gespeichert, der Zugriff erfolgt verschlüsselt und wird über API-Keys berechtigt.
• Die Frontend-Performance steigt merklich, da nicht die gesamte Website auf Nutzerseite geladen werden muss, sondern nur einzelne Komponenten, die dann die benötigten Daten nachladen.
• Bei einem Update des Backends leidet das SEO-Ranking nicht, da im Frontend alles gleich bleibt.
• Und nicht zuletzt ist auch weniger spezifisches Wissen (TYPO3, TypoScript, Architektur) seitens der Entwickler:innen von Nöten, was sich gerade in Zeiten von Fachkräftemangel bemerkbar macht.

Ist Headless für alle der richtige Ansatz?

Um ein Headless-System aufzustellen, wird erstmal ein größeres Setup benötigt. Deshalb muss vorher überlegt werden, wann der RoI erreicht wird. Bei kurzlebigen Seiten ist das wahrscheinlich der falsche Ansatz. Bei mehrjähriger Nutzung in Verbindung mit Multi-Channel und einer gewissen Weiterentwicklung werden die TCO (Total Cost of Ownership) äußerst attraktiv und günstiger im Vergleich zum klassischen Weg.

Für welche Projekte ist MACH zu empfehlen?

MACH ist sinnvoll für große Unternehmens-Portale, die eine lange Lebensdauer haben sollen und Updates ohne großen Aufwand überstehen müssen. Insbesondere für Systeme, die eng verzahnt miteinander agieren, ist diese Form der Architektur ein maßgeblicher Vorteil. Die mögliche weltweite Verteilung der BE-Systeme erleichtert internationalen Teams die Redaktionsarbeit, da die Übertragungsszeiten wesentlich kürzer werden. Wenn dann auch noch zusätzliche Systeme und Services dazukommen sollen, sind Sie im MACH-Umfeld genau richtig.

Wann genau ist denn nun der Headless-Ansatz zu wählen?

Wenn Sie bereits ein monolithisches System nutzen und dies Ihren Bedürfnissen entspricht, haben sie keinen Grund zu wechseln. Möchten Sie allerdings das System um weitere Funkionen wie E-Commerce, ein PIM, eine bessere Suche, etc. in absehbarer Zeit erweitern, dann sollten Sie Ihr System auf headless umstellen.

Würden wir Ihnen MACH und Headless empfehlen?

Wie Sie lesen konnten ist das keine triviale Entscheidung. Wir beraten Sie gerne dazu, welche Systemarchitektur die für Sie passendste ist. Lassen Sie uns sprechen!
 

References

[1] TYPO3 Headless: Ist das die Zukunft des Content Managements?
[2] Was genau ist Headless?