Headless-Architektur ist auf dem Vormarsch

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die rasante und weitreichende Nutzung von APIs trägt zum Aufstieg der Headless-Architektur bei und verschafft GraphQL einen prominenten Platz in dieser neomodernen Anwendungsarchitektur.

Seit mehr als zwei Jahrzehnten wirken sich bedeutende Paradigmenwechsel bei Anwendungsarchitekturen unmittelbar auf die Weiterentwicklung der Anwendungsbereitstellung aus. In der Vergangenheit kamen etwa alle fünf Jahre Anwendungsarchitekturen auf, die unseren Markt maßgeblich beeinflussen und prägen sollten. Rund fünf Jahre später setzten sie sich als dominierender Ansatz durch und trieben damit wiederum Veränderungen im Markt für Anwendungsbereitstellung voran.

Microservices (Cloud-native) gewannen 2015 an Aufmerksamkeit im Markt, doch erst 2020 kamen Service Mesh und Ingress Control auf und bestimmten zunehmend die Entwicklung der Anwendungsbereitstellung. Nun zeichnen sich erste Anzeichen für den Aufstieg einer neuen Architektur ab – Headless –, die Microservices als treibende Kraft bei der Anwendungsbereitstellung ablösen wird.

Ausgehend von historischen Trends wird die Headless-Architektur bis 2025 eine breite Marktakzeptanz erreichen und Veränderungen im Markt für die Anwendungsbereitstellung vorantreiben. Die Verlässlichkeit dieses Zyklus lässt in Verbindung mit den zunehmenden Aktivitäten und dem wachsenden Marktinteresse an APIs und Graphtechnologien bis zum Jahr 2030 erhebliche Auswirkungen auf die Anwendungsbereitstellung erwarten.

Trends, die die Headless-Architektur vorantreiben

Mehrere externe Faktoren führen dazu, dass zwei Technologietrends zusammenlaufen, die den nächsten großen Wandel bei der Bereitstellung von Anwendungen bewirken werden: API-First-Design und die Demokratisierung von Daten.

1. Digitale Transformation

Das Bestreben, Unternehmen zu digitalisieren, zeigt sich in „digitalen Diensten“, die von einem „digitalen Unternehmen“ bereitgestellt werden. Digitale Dienste sind kurzlebige Geschäftskonstrukte, die aus Anwendungen, Anwendungsbereitstellung, Anwendungssicherheit und Daten bestehen und mithilfe von APIs integriert, orchestriert und betrieben werden. Heute stellen 82 Prozent der Unternehmen sowohl internen als auch externen Nutzern digitale Dienste bereit (SOAS 2022).

Gleichzeitig hat die Verbreitung von Microservices, die hauptsächlich über APIs kommunizieren, weiter zugenommen. Laut unseren eigenen Untersuchungen schätzen wir, dass „die Zahl der öffentlichen und privaten APIs heute auf 200 Millionen zugeht und bis 2031 in die Milliarden gehen könnte.“

Trend: Das Ergebnis ist eine Verlagerung hin zu APIs in einem Ausmaß, das den etablierten Markt für die Anwendungsbereitstellung grundlegend verändern wird – ähnlich wie mobile Technologien und Microservices diesen Markt zwischen 2010 und 2020 verändert haben.

Dezentralisierung

Dezentralisierung ist das Ergebnis verteilter digitaler Aktivitäten, die durch Remote-Arbeit, die breite Einführung des IoT und Bedenken hinsichtlich des Datenschutzes entstehen. Dezentralisierung wird häufig mit Web3-Technologien wie Blockchain sowie mit Edge Computing in Verbindung gebracht, insbesondere beim Einsatz im industriellen IoT. Tatsächlich sind es jedoch die Auswirkungen der Dezentralisierung, die den Wandel vorantreiben. Sowohl Daten als auch Anwendungen werden „dezentralisiert“, wodurch die für verteilte Systeme typischen Herausforderungen in Bezug auf Leistung und Sicherheit entstehen. Dazu gehören die 77 % der Unternehmen, die Datenverarbeitungs- und digitale Frontend-Workloads am Netzwerkrand bereitstellen möchten (SOAS 2022).

Trend: Die Dezentralisierung hat Auswirkungen, die über verteilte Anwendungen hinausgehen, da sie auch die Möglichkeit zur Verteilung von Daten umfasst. Bei herkömmlichen Ansätzen werden Daten einer geschützten Ebene hinter den Anwendungen zugeordnet. Die Dezentralisierung erzwingt einen neuen Ansatz, bei dem Daten direkt über APIs bereitgestellt werden, ohne dass ein Vermittler (eine Anwendung) erforderlich ist. Dieser Wandel löst den ebenenbasierten Ansatz der Anwendungsarchitektur ab und ermöglicht externen Partnern, Drittentwicklern und Verbrauchern einen direkten Zugriff auf Daten. Die Anfänge dieser Demokratisierung von Workloads innerhalb der Anwendungsarchitektur zeigen sich in Microservices-Architekturen. Der bereits vorhandene geschäftliche Nutzen der Datendemokratisierung zeigt sich auch in Geschäftsmodellen, die auf Inversion beruhen, also darauf, Daten über APIs freizugeben, um Mehrwert für Partner und Drittentwickler zu schaffen.

Wir erkennen auch den bestehenden geschäftlichen Nutzen der Demokratisierung von Daten in Geschäftsmodellen, die auf Inversion setzen – also darauf, Daten über APIs frei zugänglich zu machen, um Mehrwert für Partner und externe Entwickler zu schaffen.

Low-Code/No-Code

Die Digitalisierung führt zu einer Nachfrage nach technischen Fachkräften, die das Angebot auf dem Markt übersteigt. Dadurch können Unternehmen die riesigen Datenmengen, die im digitalen Geschäft entstehen, nicht ausschöpfen. Die verfügbaren Fachkräfte sind überlastet und häufig nicht in der Lage, Lösungen so schnell zu entwickeln, wie es die geschäftlichen Anforderungen erfordern.

Diese Diskrepanz zwischen Angebot und Nachfrage führt zu einem starken Anstieg von Low-Code-/No-Code-Lösungen, die es einem breiteren Nutzerkreis ermöglichen, Lösungen und Services zu entwickeln. Untersuchungen zufolge werden 75 % der Unternehmen auf eine „Mischung aus Low-Code/No-Code und konventioneller Innovation“ setzen.

Trend: Low-Code-/No-Code-Lösungen sind auf den Zugriff auf Geschäftslogik und Daten angewiesen. Beides wird durch die Demokratisierung von Daten und einen API-First-Ansatz allgemein zugänglich gemacht. Der Bedarf an diesen Lösungen beschleunigt die Weiterentwicklung sowohl von Daten- als auch von API-Trends.

Die im Markt im Zusammenhang mit APIs verwendete Sprache – Router, Gateways, Middleware – ähnelt der Sprache, die bereits vor früheren, durch Microservices, Mobiltechnologien und Architekturänderungen ausgelösten Marktveränderungen verwendet wurde. Die Aktivitäten, die Terminologie und die Geschwindigkeit der API-Erstellung deuten darauf hin, dass dieser Wandel erhebliche Auswirkungen auf die Märkte für Anwendungsbereitstellung und Sicherheit haben wird.

Wir sehen bereits erste Anzeichen für einen API-basierten Umbruch in der Branche – in Form von Produkten und Diensten, die speziell auf die Beobachtbarkeit und Sicherheit von APIs sowie auf Bedrohungsinformationen und Föderation ausgerichtet sind.

Diese Veränderungen finden nicht im luftleeren Raum statt. Tatsächlich war der durch Microservices ausgelöste Wandel bei der Anwendungsbereitstellung größtenteils auf die breite Einführung von Kubernetes und dessen Architekturentscheidung zurückzuführen, Funktionen direkt zu integrieren, die traditionell von Technologien zur Anwendungsbereitstellung angeboten werden, etwa von Ingress-Controllern (L7-Routing).

Beim Wandel im API-Bereich verhält es sich nicht anders. Aktuelle Trends deuten darauf hin, dass dieser Wandel den Aufstieg von GraphQL vorantreiben wird – einem Ansatz für die Entwicklung von APIs, der direkter mit Daten interagiert, Leistungsprobleme REST-basierter Lösungen behebt und, was noch wichtiger ist, Funktionen für die Anwendungsbereitstellung in seinen zentralen Funktionsumfang integrieren wird.

Headless-Architektur

Die Dominanz von APIs treibt das voran, was Analysten als „Headless-Architektur“ bezeichnen: Geschäftsfunktionen und -fähigkeiten werden dabei ohne die herkömmliche Präsentationsschicht als APIs bereitgestellt. Diese Architektur wird häufig im Zusammenhang mit „Composable Applications“ diskutiert, einem weiteren aufkommenden Technologietrend am Markt.

Headless-Architekturen eignen sich gut, um den Bedarf an Low-Code-/No-Code-Lösungen zu decken, da APIs eine praktische Möglichkeit bieten, kombinierbare Logik bereitzustellen, die sich ohne großen Aufwand individuell anpassen lässt. Die Headless-Architektur erfüllt zudem die Anforderung, digitale Dienste aus einer Vielzahl von Anwendungen, Diensten und Systemen zusammenzustellen. Darüber hinaus bietet sie äußerst praktikable Möglichkeiten zur Integration verteilter Workloads, wie der überwiegend API-gesteuerte IoT-Markt bereits zeigt.

Daher kann man mit Fug und Recht sagen, dass der nächste Wandel bei Technologien für die Anwendungsbereitstellung und -sicherheit von APIs vorangetrieben wird, die wiederum Headless-Architekturen zum Durchbruch verhelfen werden.

Die größten Auswirkungen werden bei Diensten für die API-Bereitstellung und -Sicherheit zu spüren sein. Der Markt hat APIs lange Zeit lediglich als speziellen Anwendungsfall für die Bereitstellung und Sicherheit von Webanwendungen betrachtet. Dieser Wandel wird deutlich machen, dass APIs eine eigene Klasse von Entitäten mit spezifischen Anforderungen an Bereitstellung und Sicherheit darstellen, die sich mit herkömmlichen Mitteln nicht erfüllen lassen. Dies gilt insbesondere bei der Betrachtung der Auswirkungen von Datendiensten, die direkt über APIs zugänglich gemacht werden. Über weite Teile der Geschichte hinweg wurden Daten ausschließlich über Anwendungen zugänglich gemacht. Der direkte Zugriff über eine API stellt bereits für sich genommen einen bedeutenden Wandel dar und veranschaulicht zugleich perfekt, warum APIs nicht länger eine Unterkategorie von Webanwendungen sind, sondern eine eigenständige Architekturkomponente.

Die Rolle von GraphQL in der Headless-Architektur

Dieser Wandel der Anwendungsarchitekturen vollzieht sich zu einer Zeit, in der sich auch API-Ansätze verändern – wie schon in der Vergangenheit meist als Reaktion auf die Art und Weise, wie APIs genutzt werden. Letztlich dienen alle APIs dem Datenaustausch, doch Art und Format dieser Daten verändern sich im Laufe der Zeit, um den Einschränkungen und Möglichkeiten von Anwendungsarchitekturen Rechnung zu tragen. So gewannen REST und JSON mit dem Übergang zu mobilen Anwendungen und Microservices an Beliebtheit, da Daten häufiger ausgetauscht werden mussten und mobile Plattformen über weniger Rechenleistung verfügten. SOAP und XML erforderten eine aufwendige Verarbeitung und beanspruchten übermäßig viel Bandbreite. REST und JSON verringerten diesen Aufwand, indem sie vorhandene HTTP-Konstrukte zur Beschreibung von Endpunkten nutzten und mit JSON auf ein einfacheres Datenformat setzten.

Sowohl SOAP/XML als auch REST/JSON erfordern jedoch klassische Entwicklerkenntnisse. Der Trend geht hingegen zu Low-Code/No-Code, wofür kaum oder gar keine Programmierkenntnisse vorausgesetzt werden. GraphQL ist eine einfache Abfragesprache, die sich an Nichtentwickler richtet und sich besonders gut für einfache Tools eignet, durch die sie einem breiteren Nutzerkreis zugänglich wird. Dadurch werden APIs leicht zugänglich und lassen sich zu digitalen Diensten aller Art kombinieren. Damit ist GraphQL der ideale Ersatz für REST/JSON, wenn Architekturen auf reine APIs (Headless) umgestellt werden.

GraphQL ist derzeit die bevorzugte Lösung für das Problem der unkontrollierten Ausbreitung von APIs und für dieselben Leistungsprobleme, die den Wechsel von SOA (serviceorientierter Architektur) zu REST mit vorangetrieben haben. Ein weiterer Vorteil von GraphQL ist eine Spezifikation, die die Entwicklung von Low-Code-/No-Code-Lösungen fördert und dazu beiträgt, die Herausforderungen des Fachkräftemangels zu bewältigen.

Da GraphQL APIs abfragt und die überwiegende Mehrheit der Datenspeicher heute API-fähig ist, können GraphQL-basierte Lösungen schließlich die Anwendung als „Zwischeninstanz“ effektiv umgehen und direkt auf die Datenquelle zugreifen. Dies ist besonders hilfreich für verteilte Anwendungen, die einen schnellen, direkten Zugriff auf Daten an entfernten Standorten benötigen.

Damit ist GraphQL hervorragend positioniert, um als „Gateway“ zu einer Headless-Architektur zu fungieren – ganz ähnlich wie Ingress-Controller zum „Gateway“ für Microservices-Architekturen wurden.

Fazit

Man sagt, die einzige Konstante sei der Wandel – und das gilt auch für die Technologie. Selten herrscht länger als ein paar Jahre Stillstand, bevor jemand die Spielregeln ändert. In der Welt der Anwendungsbereitstellung und -sicherheit werden diese Regeln zum Teil durch Anwendungsarchitekturen bestimmt. Daher führt jede wesentliche Veränderung der Anwendungsarchitekturen zwangsläufig dazu, dass sich auch die Anwendungsbereitstellung und -sicherheit weiterentwickeln.

Dieser Wandel liegt zwar noch einige Jahre in der Zukunft, doch schon heute ist deutlich zu erkennen, welch tiefgreifende Auswirkungen Technologien wie GraphQL und APIs auf sämtliche Bereiche haben – von der Infrastruktur über den Edge-Bereich bis hin zur Anwendungsbereitstellung.

Headless-Architekturen sind auf dem Vormarsch, und GraphQL wird dabei eine wichtige Rolle spielen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie