Headless – aber warum?
In der Welt der Softwareentwicklung finden Sie verschiedene Arten von Architekturen und unterschiedliche Meinungen dazu, was der richtige Ansatz ist. In letzter Zeit hört man immer öfter, dass es einen Trend gibt, monolithische Architekturen durch eine Headless-Architektur (also eine entkoppelte Architektur) oder eine Microservices-Struktur zu ersetzen. Stimmt das? Und wenn ja, warum ist das so?
Monolithische Architekturen durch Headless-Architektur oder Microservices-Struktur ersetzen?
Betrachten wir zunächst das Konzept eines Monolithen an. Was ist das und welche Gründe gibt es, die gegen diesen Ansatz sprechen?
Ein Monolith ist eine Software, die aus einer einzigen Codebasis besteht, die alle Funktionalitäten umfasst, die für ein Projekt benötigt werden. Das CMS Drupal 8 ist ein Beispiel dafür. Drupal 8 verwendet sogenannte „Module und Plug-ins“, die – vereinfacht gesagt – Frontend- und Backend-Funktionalität verheiraten. Also was ist so schlecht daran?
Dieser Ansatz kann die Dinge verkomplizieren. Einige Beispiele:
Ladezeiten
Wenn User auf eine URL zugreifen, folgt eine monolithische Architektur einer Kaskadenlogik, um die Seite darzustellen: Erst einmal werden Daten abgerufen. Module und die auf das Projekt zugeschnittene Businesslogik verändern dann diese Daten. Danach wird HTML erzeugt, einschließlich Stylings und Frontend-Code. Dieser Code wird dann von anderen Modulen wieder überschrieben. Zu guter Letzt wird alles zu einer Website zusammengepuzzelt. Das klingt kompliziert – und ist es auch. Und es führt häufig zu langen Ladezeiten.
Releases
Auch die Release-Planung kann sich mühsam und zunehmend schwierig gestalten.
Der Grund dafür ist, dass man bei jedem Release die ganze Anwendung releasen müsste, auch wenn nur ein paar kleine Änderungen benötigt werden. Stellen Sie sich vor, Sie bauen ein Haus und unterschiedliche Handwerker arbeiten an verschiedenen Teilen der Baustelle. Einige kümmern sich um den Keller; andere reparieren das Dach; wieder andere verlegen die Böden usw. Wenn Sie jetzt eine einzelne Wand in einem einzigen Raum rosa streichen wollen, müssen ALLE Handwerker mit ihrer aktuellen Aufgabe fertig sein. Alle Arbeiten müssen geprüft und abgenommen sein. Der Keller, das Dach, alles. Für EINE rosa Wand.
Wartungsfreundlichkeit und Testen
Die Schwierigkeiten entstehen hauptsächlich wegen Abhängigkeiten. Ändern Sie eine Sache, ist diese womöglich mit fünf anderen Dingen verbunden. So kann aus kleinsten Änderungen eine große Sache werden – sowohl bei der Implementierung als auch beim Testen. Es wird immer schwieriger, die Anwendung zu warten.
Wenn man bei Estimation Meetings (zu) oft den Satz hört „Wie kann diese kleine Änderung fünf Story Points sein?!“, ist das schon ein Indiz, dass zu viele Abhängigkeiten herrschen. Auch das Testen wird zunehmend zu einer Herkulesaufgabe. Ich erinnere mich an eine Applikation, die uns zwang, endlose Regressionstestprotokolle zu erstellen, um sicherzugehen, dass nach jedem Release auch immer noch alles funktionierte. Natürlich muss man diesem Zustand mit automatisierten Tests entgegentreten, aber die Ursache ist damit nicht behoben.
Recruiting
Es ist schwieriger, neue Entwickler einzustellen. Wir brauchen Leute, die sich sowohl mit Frontend und als auch Backend gut auskennen, statt beispielsweise “nur” einen React-Experten. Neue Entwickler im Team einzuarbeiten kann ebenfalls mühsam sein. Da all diese Abhängigkeiten die Anwendung so komplex machen, ist es zunehmend schwierig, sie zu dokumentieren und nachzuvollziehen.
Wann sind monolithische Anwendungen sinnvoll?
Natürlich gibt es aber auch Anwendungsfälle, in denen eine monolithische Anwendung sinnvoll oder schlichtweg ausreichend ist. Ein gutes Beispiel ist Software, die Sie so verwenden, wie sie ist, und bei der Sie nur wenige individuelle Anpassungen vornehmen müssen. Die meisten Betriebssysteme sind zum Beispiel Monolithen. Viele wollen auch einfach schnell loslegen und sich dafür Software holen, die schon vieles kann. Auch dafür kann sich ein Monolith eignen.
Schauen wir uns den Headless-Ansatz an.
Headless bedeutet, dass Backend- von Frontend-Funktionalitäten getrennt sind. Die Kommunikation erfolgt über eine API. Man kann sich diese API als einen Vertrag vorstellen. Die Backend-Mitarbeiterinnen und -Mitarbeiter versprechen dem Frontend-Team, bestimmte Daten zu liefern. Und das Frontend-Team verlässt sich auf diese Zusage.
Schnelle Lieferung und gut strukturierter Code
Diese Struktur löst eine Reihe der oben genannten Probleme. Dank des Abbaus vieler Abhängigkeiten können Frontend-Änderungen unabhängig umgesetzt werden; das Engineering-Team bekommt einen besseren Überblick über die Codebasis und die Performance der Webseite kann gesteigert werden.
Und das ist nicht alles. Da die Businesslogik streng vom Frontend getrennt ist, ist man sehr viel flexibler, was die Verwendung der Daten auf verschiedenen Vertriebskanälen betrifft. Nehmen wir einmal an, dass Sie Inhalte veröffentlichen. Sie wollen die Inhalte auf Ihrer Website platzieren, aber vielleicht auch in einer App oder auf der Website eines Partners oder in einem sozialen Netzwerk verwenden. Das ist im Falle des entkoppelten Ansatzes deutlich einfacher umzusetzen. Alle unterschiedlichen Dienste nutzen den „Vertrag“ (die API). Sie verwenden also die Daten, die über diesen Punkt bereitgestellt werden, und erstellen das User-Interface für den jeweiligen Kanal mit der dafür am geeignetsten Frontend Technologie.
Integrationen und Spezialisierungen
Ein weiterer Pluspunkt ist, dass sie „spezialisierte Services“ einfacher integriert werden können. Stellen wir uns vor, Sie wollen Produkte in Ihr CMS integrieren. Da „Produktfunktionalität“ keine Standardfunktionalität in einem Content-Management-System ist, wollen Sie vielleicht einen (E-Commerce-ähnlichen) Dienst integrieren, der auf den Umgang mit Produkten spezialisiert ist. In einem klassischen monolithischen System (in dem die Seite vollständig vom Backend dargestellt wird) muss dieser Dienst tief im Backend integriert werden. Daraus entstehen wieder Abhängigkeiten. Bei einem Headless-Ansatz kann ein anderer Dienst leichter angefügt und gewartet werden – oder ausgetauscht, wenn sie sich eines Tages für einen anderen Dienst entscheiden.
Selbstverständlich ist nicht alles schwarz oder weiß. Es gibt auch einige Monolithen, die speziell so konzipiert sind, dass sie erweitert werden können. Grundsätzlich kann man aber sagen, dass das mit einer entkoppelten Architektur leichter ist.
Der Microservices-Ansatz
Der nächste Schritt in der „Entwicklung“ besteht darin, die ganzen unterschiedlichen Funktionalität-Häppchen auf Ihrer Website über spezialisierte Services anzubieten. Das ist der Microservices-Ansatz. Microservices sind klein und unabhängig und darauf ausgerichtet, eine konkrete Aufgabe auszuführen. Damit sind sie einfach zu warten und zu verbessern. Da sie für die Kommunikation ebenfalls auf eine API setzen, können sie unabhängig angepasst und bereitgestellt werden. Gibt es eine bessere Alternative, können sie einfach ausgetauscht werden.
Headless - individuelle Betrachtungsweise
Zu guter Letzt muss noch betont werden, dass keine Form der Architektur eine Wunderpille ist. Gutes Architekturdesign, Qualitätsmanagement und kontinuierliche Planung und Neuausrichtung Ihrer technischen Landschaft sind in jedem Fall unverzichtbar. Für jedes Projekt muss einzeln bewertet werden, was notwendig ist, um das Geschäft voranzutreiben. Weniger Abhängigkeiten sind jedoch in der Regel eine gute Sache, vor allem wenn Sie Ihre Projekte individuell ausgestalten wollen.
Es lohnt sich, tiefer in das Thema Headless einzutauchen. Möchten Sie die Möglichkeiten Ihres Unternehmens ausloten? Brauchen Sie Beratung?
