Mit Microservices die Headless CMS Architektur optimieren
Der Innovationsdruck für Marketing- und IT-Verantwortliche in großen und mittelständischen Unternehmen ist enorm: Kunden orientieren sich bei ihrer Customer Journey an den Erfahrungen, die sie mit den UX-optimierten Consumer Brands machen. Alles muss einfach, schnell und problemfrei funktionieren. Das stellt Unternehmen im B2B Sektor zunehmend vor Herausforderungen. Die IT muss die technologischen Grundlagen für die Anforderungen von Marketing und Vertrieb schaffen und die Infrastruktur innovieren. Der Wechsel auf einen Headless Ansatz im Content Management und die Integration von Microservices ist ein Weg, bestehende Systemlandschaften evolutionär auf das nächste Level zu heben. In dem Artikel erklären wir die wichtigsten Fakten und geben Insights aus unserem Beratungsgeschäft mit Unternehmen in klassischen B2B Märkten.
Schauen wir auf den Status Quo im IT-Maschinenraum von vielen B2B Unternehmen. Noch viel zu oft übernimmt ein traditionelles (Headful) CMS die gesamte Contentverwaltung und -ausspielung. Es besteht aus einem Backend, in dem Daten organisiert werden und einem Frontend, das dem Nutzer über seinen Browser angezeigt wird. Im Gegensatz dazu verzichtet ein Headless CMS – auch entkoppeltes Content Management System genannt – auf das integrierte Frontend. Dieses wird stattdessen individuell erstellt und verwaltet. In der Architektur finden sich Backend, APIs und verschiedene Microservices. Das Backend verwandelt sich in ein flexibles Content Repository, in dem Content-Manager Inhalte hinzufügen, bearbeiten und verwalten können. Die Headless Architektur ermöglicht auch die Integration weiterer Systeme wie PIM, DAM, MAM mit all ihren relevanten Daten.
In dieser Flexibilität liegt der größte Vorteil, den ein Headless CMS Unternehmen bietet. Durch die Entkopplung des Backends von einem festgelegten Frontend, können Inhalte medienneutral verarbeitet und anschließend auf allen Kanälen – beispielsweise Websites, Apps, soziale Medien, Smartspeaker bis hin zu Print on Demand Anwendungen und mehr – ausgespielt werden. Das erhöht die Wiederverwendbarkeit des Contents und verkürzt die Time to Market erheblich, da Inhalte nur einmalig erstellt werden müssen.
Neben dem Backend und den standardisierten Schnittstellen finden sich auch Microservices in der Headless CMS Architektur. Wie sich Microservices definieren, wo ihren wichtigsten Anwendungsbereichen in der Praxis liegen und welche Vor- und Nachteile „Monolithic vs. Microservices Architekturen“ haben, erklären wir in den nächsten Abschnitten.
Maximieren Sie Ihre IT-Effizienz mit Composable ArchitectureWas leisten Microservices in der Softwarearchitektur?
Laut Microservices Definition handelt es sich dabei um Mini-Softwarelösungen, die jeweils nur eine Funktion oder einen Prozess übernehmen. Allein haben diese kleinen Anwendungen keinen Nutzen. Stattdessen werden Microservices in der Headless CMS Umgebung eingesetzt und dort in ein bestehendes System integriert, um es zu vervollständigen und zu personalisieren. Da ein Headless CMS aus einem Backend und standardisierten APIs besteht, können Microservices in die Architektur nahtlos eingebunden werden. Die Schnittstellen ermöglichen einen reibungslosen Datenaustausch. Da jeder Microservice eine eigene Domäne und einen klar definierten Nutzen hat, sollte es keine Überschneidungen mit Daten aus anderen Prozessen geben. Microservices Beispiele sind Übersetzer, Tools zur Content-Klassifizierung oder für den Log-in und die Registrierung. Auch die Einbindung von Wetterdaten oder Kreditkartenzahlungen für In-App-Käufe werden über Microservices gelöst.
Das Gegenstück zur Microservices Architecture ist eine Monolithic Architecture, in der die Anwendung als komplette Einheit ähnlich einem Monolithen zur Verfügung gestellt wird. Dieses System ist in sich geschlossen und unabhängig von anderen Anwendungen und Anbietern.
Microservices in einer Headless CMS Architektur
Ein Headless CMS mit Backend, APIs und einem externen Frontend stellt noch keine Microservice-Landschaft dar, obwohl diese Systembestandteile voneinander getrennt sind. Vielmehr werden in der Microservice Architektur das Frontend und Backend in einzelne Teilsysteme unterteilt, die ihre eigenen Funktionen haben. Diese Mini-Softwarelösungen sind aufgrund der bestehenden standardisierten APIs sehr einfach zu implementieren, was Programmierern und Entwicklern die Einbettung der Services erleichtert. Die Integration kann sowohl im Backend für zusätzliche Funktionen als auch im Frontend zur Ausspielung für die Kunden erfolgen.
Auf Nutzer und Kunden haben die Microservices keine oder nur sehr geringe Auswirkungen. Werden die zusätzlichen Features im Frontend integriert, bemerken Kunden keinen Unterschied zwischen den Daten, die vom Backend oder vom Microservice zur Verfügung gestellt werden. Auch bei der Nutzung durch Content Manager im Backend fallen Microservices nur gering bis gar nicht auf, denn sie fügen sich nahtlos in das bestehende System ein. Dadurch entstehen kaum Unterschiede zwischen Monolithic vs. Microservices Umgebungen. Stattdessen profitieren Nutzer von zusätzlichen Funktionen und erfahren damit höchste Flexibilität. Unternehmen können die gewählten Microservices jederzeit austauschen, beispielsweise den Google Translator gegen den DeepL Translator, sodass stets die bestmögliche Lösung für ein bestimmtes Problem gefunden werden kann. Diesen Ansatz nennt man auch Best-of-Breed.
Mythen über Microservices
Nach all den genannten Vorteilen der Microservices Architecture, könnte man vermuten, dass es sich dabei um die optimale Lösung für alle Probleme handelt. Das ist jedoch ein Mythos, denn diese Architektur birgt auch Nachteile. Im Gegensatz zu einem monolithischen Ansatz sind Microservices mit einem erheblichen Mehraufwand verbunden. Zudem kommen zusätzliche Kosten auf ein Unternehmen zu. Die Kosten für eine All-in-One-Lösung sind meist überschaubar und von Anfang an klar ersichtlich, währenddessen jeder Microservice seine eigenen Kosten mit sich bringt. Je nachdem, wie viele dieser Mini-Softwarelösungen in ein System integriert werden, können die Kosten wesentlich höher ausfallen. Werden die Microservices über eine Integrationsschicht organisiert, entsteht ein komplexeres Gesamtbild – jedoch sind die einzelnen Lösungen weniger komplex als ein Monolithsystem.
Monolithische Architekturen vs. Microservices-Struktur
Die Wahl zwischen einem Monolithsystem und einer Microservices Infrastructure muss jedes Unternehmen für sich fällen, denn beide Systemarten haben bestimmte Vor- und Nachteile.
Ladezeiten
Die Anforderungen an eine moderne Microservice Architektur sind hoch, vor allem, wenn es um die Optimierung der Ladezeiten geht, um die gesamte User-Experience zu verbessern. Unternehmen können selbst festlegen, welche Microservices auf ihre Ladezeiten optimiert werden. So kann beispielsweise die Suchfunktion priorisiert werden, während die Übersetzungsfunktion eine längere Ladezeit besitzt. Es ist auch möglich, einzelne Funktionen aus einem Monolithsystem herauszulösen und zu optimieren, diese Optionen sind jedoch begrenzt und nicht für alle Features möglich.
Releases
Da es sich bei einer Monolithic Architektur um ein in sich geschlossenes Gesamtsystem handelt, ist es häufig mit einem höheren manuellen Aufwand und einem insgesamt längeren Release Management verbunden. Der Vorteil daran ist jedoch die Stabilität dieses Managements, da alle Komponenten des Systems, Daten und Versionen aufeinander abgestimmt sind. Microservices haben den Vorteil, dass sie unabhängig voneinander veröffentlicht werden können. Entwickler sind dadurch flexibler in ihrer Arbeit und können die Time to Market verkürzen. Es besteht außerdem die Möglichkeit, verschiedene Teams an einzelnen Microservices arbeiten zu lassen. Jedoch tragen Unternehmen selbst die Verantwortung dafür, Microservices, APIs und Integrationen optimal aneinander anzupassen und auf Kompatibilitäten zu achten, damit keine Probleme entstehen.
Wartungsfreundlichkeit
Mit gut durchdachten Microservice Architekturen profitieren Unternehmen von einer sehr hohen Wartungsfreundlichkeit. Kleinere Anpassungen und Änderungen können in der Regel schnell und einfach durchgeführt werden. Sind die einzelnen Komponenten jedoch unzureichend aufeinander abgestimmt und bestehen dabei zu viele Abhängigkeiten, erschwert das die Wartung der Microservices Architecture erheblich. Eine Monolith-Struktur dagegen ist weniger komplex in der Wartung, jedoch auch sehr träge. Die technologische Entwicklung verläuft meist schneller als die Implementierung in das System, sodass es schnell veraltet und neue Features langsamer einfließen.
Recruiting
Monolithic Content Management Systeme haben durchschnittlich eine geringere Auswahl beim Recruiting, da Unternehmen überwiegend an einen einzelnen Anbieter gebunden sind. In einer Microservice Architektur sind die einzelnen Services weniger komplex und können unabhängig voneinander entwickelt und weiterentwickelt werden. Die Entwicklung kann von verschiedenen Teams, Dienstleistern oder auch von Drittanbietern erfolgen, sodass beim Recruiting eine größere Auswahl entsteht. Eine Best-of-Breed-Lösung ist hier möglich.
Empfehlungen für eine Herangehensweise in die Praxis
Effektive und saubere Content-Architektur
Über APIs werden Daten und Inhalte ausgetauscht und eine Kommunikation zwischen den einzelnen Microservices ermöglicht. Damit dieser Austausch reibungslos verlaufen kann, sollten Unternehmen auf eine saubere und effiziente Content-Architektur achten und Inhalte sinnvoll strukturieren.
Den Anwendungsfall verstehen
Sowohl eine Microservices-Architektur als auch ein Monolith-System haben ihre Vor- und Nachteile, weshalb es keine optimale Lösung gibt. Vielmehr muss die Lösung zum jeweiligen Unternehmen und dem Anwendungsfall passen. In diesen Beispielen werden Situationen hervorgehoben, in denen Microservices und Monolithen bevorzugt werden sollten:
Fall 1: Wann sind Microservice hilfreich?
Nutzt ein Unternehmen verschiedene Systeme, die untereinander verknüpft werden müssen, um Daten auszutauschen und Prozesse abzuwickeln, eignet sich eine Microservice Architektur. PIM oder DAM sind prominente Beispiele dafür, da hier viele Querverbindungen notwendig sind. Die Auftrennung in einzelne Services und Microservices erleichtert die Integration und hilft dabei, eine dezentrale Datenarchitektur – auch Data Mesh genannt – zu verwirklichen. Ein ESB (Enterprise Service Bus) dient als Rückgrat der Netzwerkarchitektur, die die Integration verschiedener Dienste für Unternehmen ermöglicht und vereinfacht. Eine Steigerung dieser Architektur nennt sich Event-driven-Microservices oder Event-driven-Architecture, wobei das Zusammenspiel der einzelnen Komponenten und Services durch Ereignisse gesteuert wird.
Fall 2: Wann ist ein Monolith sinnvoll?
Für Unternehmen, die ein einheitliches „Look-and-Feel“ wünschen und dabei nur wenige Schnittstellen – beispielsweise eine Eingangs- und Ausgangsschnittstelle – benötigen, ist der Einsatz eines Monolithen sinnvoll. Ein Domain-driven-Design gestaltet eine komplexe, monolithische Anwendung, wie ERP, CRM, CMS, PIM oder DAM, transparenter. Damit wird sie für Nutzer einfacher zu verstehen und zu bedienen. In diesem Fall können Microservices eine ohnehin komplexe Anwendung noch weiter verkomplizieren und unübersichtlich gestalten. Das in sich geschlossene und nutzerfreundliche Monolith-System ist in diesem Fall zu bevorzugen.
Fall 3: Realitätsnahe Anwendungen
In der Realität finden sich jedoch oft Mischformen oder Hybrid-Formen beider Systemarten. Sowohl Coremedia als auch Magnolia Headless CMS gelten als Mischformen zwischen einem Monolith-System und einer Microservice Architektur und lassen sich in eine bestehende Systemarchitektur einbinden.
Verwendung eines Frameworks
Microservices allein sind nicht nutzbar – sie benötigen ein Framework, in das sie eingebunden werden. Dieses System sollte die passenden Schnittstellen bieten, um Datenintegrationen und die Einbindung von Drittsystemen zu ermöglichen. Eine Composable DXP (Digital Experience Platform) oder ein Headless CMS bilden eine optimale Basis, da sie einfach durch Microservices zu ergänzen sind. Hier findet die sogenannte MACH (Mircoservices, API-first, Cloud-native und Headless) Architektur Anwendung.
Fazit: Headless CMS Architektur mit Microservices ist eine Option
Sowohl der Monolith-Ansatz als auch die Microservices haben ihre Daseinsberechtigung, denn es gibt keine perfekte Lösung, die auf alle Unternehmen gleichermaßen zugeschnitten ist. Vielmehr müssen bei der Entscheidung für eine Systemarchitektur individuelle Überlegungen stattfinden und die bestehenden Anforderungen genau analysiert werden, um herauszufinden, welches System sich für ein Unternehmen besser eignet.
Die Installation eines Monolith-Systems kann aufwendig ausfallen und dauert in der Regel länger als einzelne Mini-Softwarelösungen. Doch auch, wenn sehr viele Microservices eingerichtet werden und diese problemlos untereinander kommunizieren müssen, kann der Aufwand größer werden. Je größer das Unternehmen, desto mehr Microservice-Lösungen kommen meist zum Einsatz, denn Marketing, Sales, Produktentwicklung und weitere Abteilungen bringen eigene Anforderungen mit, die das System bedienen muss. Hier entsteht eine hohe Komplexität. Gleichzeitig wird die Flexibilität zu einem wichtigen Stichwort, denn Unternehmen und ihre Anforderungen befinden sich in einem stetigen Wandel. In diesen Fällen muss auch das System mitwachsen und flexibel angepasst werden können. Da das mit einem Monolith-System nur begrenzt möglich ist, sind Microservices oft die bessere Lösung für große Unternehmen, deren Software mit den Anforderungen wachsen muss.
MACH-Architekturen (Microservices, API-first, Cloud-native und Headless) ermöglichen es dem Unternehmen, flexibel auf Veränderungen zu reagieren, da sie nachhaltig und widerstandsfähig im Wandel der Zeit sind. Somit kann die Wettbewerbsfähigkeit erhalten und gesteigert werden. Unternehmen sollten deshalb alle Vor- und Nachteile, wie die Flexibilität und den Mehraufwand durch hohe Komplexität, abwägen und sich für das System entscheiden, das ihren Anforderungen auf lange Sicht gerecht werden kann.
FAQs
Was sind Microservices?
Microservices sind eine Softwarearchitektur, bei der unabhängige Mini-Softwarelösungen einzelne Prozesse und Aufgaben übernehmen. Diese Microservices sind über APIs (standardisierte Schnittstellen) miteinander verbunden. Das Gegenstück zur Microservice Architektur ist ein Monolith-System.
Was sind die Vorteile einer Microservice-Architektur?
Microservices sind voneinander unabhängige Softwarelösungen, die jeweils ihre eigenen Aufgaben und Prozesse übernehmen. Daher können sie auch unabhängig voneinander entwickelt und gewartet werden – auch von verschiedenen Teams oder Anbietern. Diese Softwarearchitektur erlaubt einen Best-of-Breed-Ansatz, bei dem stets die bestmögliche Lösung für ein Problem genutzt werden kann. Unternehmen werden durch den Einsatz von Microservices flexibler und können schneller auf Veränderungen in der digitalen Landschaft oder neue Anforderungen der Kunden reagieren.
Was sind monolithische Architekturen?
Ein Monolith-System oder eine monolithische Architektur beschreibt einen Softwareansatz, das als geschlossene Einheit zur Verfügung gestellt wird und von externen Anwendungen und Anbietern unabhängig ist.
Wie können Microservices eine Headless CMS Architektur optimieren?
Ein CMS ist Headless, wenn Front- und Backend voneinander entkoppelt sind. Diese Headless Architektur basiert auf einem Backend und standardisierten APIs, die eine einfache Anbindung von Microservices ermöglichen. Dadurch können Zusatzfunktionen für den E-Commerce ergänzt und das System vervollständigt und personalisiert werden.
