Headless-Architektur ist auf dem Vormarsch
Die explosive und weitverbreitete Nutzung von APIs trägt zum Aufstieg der Headless-Architektur bei und verschafft GraphQL einen prominenten Platz in dieser neomodernen Application .
Seit mehr als zwei Jahrzehnten haben bedeutende Paradigmenwechsel in der App-Architektur die Entwicklung der App-Bereitstellung direkt beeinflusst. Historisch gesehen entstehen alle fünf Jahre Application , die dazu bestimmt sind, unseren Markt zu dominieren und zu beeinflussen. Sie beginnen, den Markt zu prägen und erlangen etwa fünf Jahre später die dominante Stellung, was wiederum zu Veränderungen im Markt für App-Bereitstellung führt.
Microservices (Cloud-native) erlangten 2015 Marktanteile, aber erst 2020 kamen Service Mesh und Ingress Control ins Spiel und bestimmten die Richtung der App-Bereitstellungslandschaft. Wir sehen jetzt erste Anzeichen für die Entstehung einer neuen Architektur – Headless –, die Microservices als treibende Kraft bei der App-Bereitstellung ersetzen wird.
Basierend auf historischen Trends wird die Headless-Architektur bis 2025 die Aufmerksamkeit des Marktes gewinnen und den Wandel im Markt der App-Bereitstellung vorantreiben. Die Zuverlässigkeit dieses Zyklus sowie die zunehmende Aktivität und das zunehmende Interesse am Markt im Zusammenhang mit APIs und Grafiktechnologie lassen darauf schließen, dass die Bereitstellung von Apps bis zum Jahr 2030 erheblich beeinträchtigt wird.
Trends, die die Headless-Architektur vorantreiben
Es gibt mehrere externe Kräfte, die zur Konvergenz zweier Technologietrends führen, die den nächsten großen Wandel bei der App-Bereitstellung zur Folge haben werden: API-First-Design und die Demokratisierung von Daten .
- Digitale Transformation
- „APIs werden in großem Umfang genutzt. Bei den an der Umfrage teilnehmenden Organisationen sind durchschnittlich 15.564 APIs im Einsatz und die Wachstumsrate liegt bis 2021 bei 201 %“ ( Noname Security ).
- 18 % der Marktaktivitäten, die ich im Geschäftsjahr 22 verfolgt habe, standen in irgendeiner Weise mit APIs in Zusammenhang. Laut 89 % der Befragten im „State of the API Report 2022“ von Postman , für den mehr als 37.000 API-Experten befragt wurden, werden die Investitionen in APIs in Unternehmen in den nächsten zwölf Monaten steigen oder gleich bleiben.
- Dezentralisierung
- Wenig Code/Kein Code
Der Drang zur Digitalisierung von Unternehmen manifestiert sich in „ digitalen Diensten “, die von einem „ digitalen Unternehmen “ bereitgestellt werden. Digitale Dienste sind flüchtige Geschäftskonstrukte, die aus Apps, App-Bereitstellung, App-Sicherheit und Daten bestehen und durch die Verwendung von APIs integriert, orchestriert und betrieben werden. 82 Prozent der Organisationen bieten heute sowohl internen als auch externen Verbrauchern digitale Dienste an (SOAS 2022 ).
Gleichzeitig hat die Nutzung von Microservices, die hauptsächlich über APIs kommunizieren, weiter zugenommen. Laut unserer eigenen Forschung gehen wir davon aus, dass „die Anzahl öffentlicher und privater APIs heute bei fast 200 Millionen liegt und bis 2031 könnte diese Zahl in die Milliarden gehen.“
Trend: Das Ergebnis ist eine Verlagerung hin zu APIs in einem Ausmaß, das den Markt für die Bereitstellung reifer Apps auf den Kopf stellen wird – ähnlich wie Mobilgeräte und Mikrodienste den Markt für die Bereitstellung von Apps zwischen 2010 und 2020 auf den Kopf gestellt haben.
Dezentralisierung ist das Ergebnis verteilter digitaler Aktivitäten, die durch Fernarbeit, die massenhafte Einführung des IoT und Bedenken hinsichtlich des Datenschutzes entstehen. Dezentralisierung wird oft mit Web3-Technologien wie Blockchain und Edge-Computing in Verbindung gebracht, insbesondere bei der Anwendung auf das industrielle IoT. Das Ergebnis der Dezentralisierung ist jedoch der eigentliche Treiber der Disruption. Sowohl Daten als auch Applications werden „dezentralisiert“, was die erwarteten Leistungs- und Sicherheitsherausforderungen jedes verteilten Systems mit sich bringt. Dazu gehören 77 % der Unternehmen, die Datenverarbeitung und digitale Front-End-Workloads am Edge bereitstellen möchten ( SOAS 2022 ).
Trend: Die Dezentralisierung hat Folgen, die über verteilte Applications hinausgehen, da sie auch die Möglichkeit zur Verteilung von Daten mit sich bringt. Bei herkömmlichen Ansätzen werden Daten auf einer geschützten Ebene hinter Applications gespeichert. Die Dezentralisierung erzwingt einen neuen Ansatz, bei dem Daten direkt über APIs verfügbar gemacht werden, ohne dass ein Vermittler (Application) erforderlich ist. Durch diesen Wechsel wird der ebenenbasierte Ansatz der Application eliminiert und ein direkter Datenzugriff für externe Partner, Drittentwickler und Verbraucher ermöglicht. Der Beginn dieser Demokratisierung von Workloads innerhalb der Application ist in Microservices-Architekturen zu erkennen. Wir erkennen auch den bestehenden Geschäftswert der Demokratisierung von Daten in Geschäftsmodellen, die auf Inversion beruhen, d. h. der Freigabe von Daten durch APIs, um einen Mehrwert für Partner und externe Entwickler zu schaffen.
Wir erkennen auch den bestehenden Geschäftswert der Demokratisierung von Daten in Geschäftsmodellen, die auf Inversion basieren – das heißt, der Freigabe von Daten durch APIs, um einen Mehrwert für Partner und externe Entwickler zu schaffen.
Aufgrund der Digitalisierung besteht eine Nachfrage nach mehr Ingenieurtalenten, als auf dem Markt vorhanden sind. Dies führt dazu, dass Unternehmen nicht auf die enormen Datenmengen zugreifen können, die ein digitales Unternehmen generiert. Die vorhandenen Talente sind überlastet und können sich oft nicht so schnell entwickeln, wie es das Geschäft erfordert.
Diese Lücke zwischen Angebot und Nachfrage führt zu einem Anstieg von Low-Code/No-Code-Lösungen, um einem breiteren Benutzerkreis die Entwicklung von Lösungen und Diensten zu ermöglichen. Untersuchungen zeigen, dass 75 % der Unternehmen eine „Mischung aus Low-Code/No-Code und konventioneller Innovation“ einführen werden.
Trend: Low-Code/No-Code-Lösungen basieren auf dem Zugriff auf Geschäftslogik und Daten, die beide durch die Demokratisierung von Daten und das API-First-Design allgemein verfügbar gemacht werden. Der Bedarf an diesen Lösungen beschleunigt die Reifung sowohl von Daten- als auch von API-Trends.
Die auf dem Markt verwendete Sprache im Zusammenhang mit APIs (Router, Gateways, Middleware) ähnelt der Sprache, die vor früheren Marktverschiebungen durch Microservices, mobile Geräte und Architekturänderungen verwendet wurde. Aktivität, Terminologie und Geschwindigkeit der API-Erstellung deuten darauf hin, dass dieser Wandel erhebliche Auswirkungen auf die Märkte für App-Bereitstellung und -Sicherheit haben wird.
Wir sehen bereits die Anfänge einer API-basierten Disruption in der Branche in Form von Produkten und Dienstleistungen, die sich speziell auf API-Beobachtbarkeit, Sicherheit, Bedrohungsinformationen und Föderation konzentrieren.
Diese Verschiebungen treten im Vakuum nicht auf. Tatsächlich ist die durch Mikrodienste verursachte Verschiebung bei der App-Bereitstellung größtenteils auf die weite Verbreitung von Kubernetes und die architektonische Entscheidung zurückzuführen, Funktionen, die traditionell von App-Bereitstellungstechnologien angeboten werden, wie etwa Ingress-Controller (L7-Routing), direkt zu integrieren.
Bei der Umstellung auf APIs ist das nicht anders, und aktuelle Trends deuten darauf hin, dass diese Umstellung den Aufstieg von GraphQL vorantreiben wird, einem Ansatz zur Entwicklung von APIs, der direkter mit Daten interagiert, Leistungsprobleme mit REST-basierten Lösungen behebt und – was noch wichtiger ist – App-Bereitstellungsfunktionen in seinen Kernfunktionsumfang integriert.
Headless-Architektur
Die Dominanz der APIs führt zu dem, was Analysten als „Headless-Architektur“ bezeichnen. Dabei handelt es sich um Geschäftsfunktionen und -kapazitäten, die als APIs ohne die traditionelle Präsentationsschicht bereitgestellt werden. Diese Architektur wird oft im Kontext „zusammensetzbarer Applications“ diskutiert, einem weiteren wachsenden Technologietrend auf dem Markt.
Headless-Architekturen eignen sich gut, um den Bedarf an Low-Code/No-Code-Lösungen zu decken, da APIs eine praktische Möglichkeit darstellen, zusammensetzbare Logik bereitzustellen, die ohne großen Aufwand leicht anpassbar ist. Darüber hinaus trägt die Headless-Architektur dem Bedürfnis Rechnung, digitale Dienste aus einer Vielzahl von Applications, Diensten und Systemen zusammenzustellen. Zudem bietet sie eine überaus praktische Möglichkeit, verteilte Arbeitslasten zu integrieren, wie der überwiegend API-gesteuerte IoT-Markt bereits zeigt.
Daher kann man wohl davon ausgehen, dass der nächste Wandel bei der Bereitstellung von Apps und bei Sicherheitstechnologien durch APIs vorangetrieben wird, die Headless-Architekturen zum Mainstream machen werden.
Die größten Auswirkungen wird es auf die API-Bereitstellung und die Sicherheitsdienste geben. Der Markt hat APIs lange Zeit lediglich als einen spezialisierten Anwendungsfall für die Bereitstellung und Sicherheit von Web-Apps betrachtet. Dieser Wandel wird die Realität offenlegen, dass APIs eine separate Klasse von Entitäten mit spezifischen Bereitstellungs- und Sicherheitsanforderungen sind, die mit herkömmlichen Mitteln nicht erfüllt werden können. Dies gilt insbesondere dann, wenn die Auswirkungen von Datendiensten untersucht werden, die direkt über APIs bereitgestellt werden. Im Großteil der Vergangenheit wurden Daten ausschließlich über Applications zugänglich gemacht. Die direkte Bereitstellung über eine API stellt an sich schon eine bedeutende Veränderung dar, ist aber auch ein perfektes Beispiel dafür, warum APIs nicht länger eine Untermenge von Web-Apps sind, sondern eine eigenständige, diskrete Architekturkomponente.
Die Rolle von GraphQL in der Headless-Architektur
Dieser Wandel in der App-Architektur findet zudem zu einer Zeit statt, in der sich auch die API-Ansätze historisch verändern, typischerweise als Reaktion auf die Art und Weise, wie APIs verwendet werden. Alle APIs dienen letztendlich dem Datenaustausch. Im Laufe der Zeit ändern sich jedoch Typ und Format dieser Daten, um die Einschränkungen und Fähigkeiten der Application widerzuspiegeln. So erfreuten sich beispielsweise REST und JSON gleichzeitig mit der Verlagerung hin zu mobilen Geräten und Mikrodiensten großer Beliebtheit als Reaktion auf die Notwendigkeit häufigerer Datenaustausche und die verringerte Rechenleistung mobiler Plattformen. SOAP und XML erforderten umfangreiches Parsen und verbrauchten übermäßig viel Bandbreite. REST und JSON reduzierten den Aufwand, indem sie vorhandene HTTP-Konstrukte zur Beschreibung von Endpunkten nutzten und auf ein einfacheres Datenformat in JSON umstiegen.
Allerdings erfordern sowohl SOAP/XML als auch REST/JSON herkömmliche Entwicklerkenntnisse und der Trend geht in Richtung Low-Code/No-Code, was kaum oder gar keine Entwicklerkenntnisse voraussetzt. GraphQL ist eine einfache Abfragesprache, die sich an Nicht-Entwickler richtet und eine hohe Affinität zu einfachen Tools aufweist, sodass sie einem größeren Benutzerkreis zugänglich ist. Dadurch werden APIs zugänglich und können in digitale Dienste aller Art integriert werden. Dies macht es zu einem perfekten Ersatz für REST/JSON, da sich die Architekturen in Richtung API-only (headless) bewegen.
GraphQL ist derzeit die bevorzugte Lösung für das Problem der API-Ausbreitung und derselben Leistungsprobleme, die zur Umstellung von SOA (serviceorientierte Architektur) auf REST beigetragen haben. GraphQL bietet außerdem den Vorteil einer Spezifikation , die die Entwicklung von Low-Code/No-Code-Lösungen unterstützt, die eine Linderung des Problems des Fachkräftemangels bieten.
Und schließlich können GraphQL-basierte Lösungen den Application „Mittelsmann“ effektiv eliminieren und direkt zur Datenquelle selbst gelangen, weil GraphQL APIs abfragt und die große Mehrheit der heutigen Datenspeicher API-fähig ist. Dies ist besonders hilfreich für verteilte Applications , die einen schnellen, direkten Zugriff auf Daten an entfernten Standorten benötigen.
Dadurch ist GraphQL hervorragend geeignet, als „Gateway“ zur Headless-Architektur zu fungieren, ähnlich wie Ingress-Controller als „Gateway“ zur Microservices-Architektur fungierten.
Abschluss
Man sagt, die einzige Konstante sei der Wandel, und das gilt auch für die Technologie. Wir stehen selten länger als ein paar Jahre still, bevor jemand die Spielregeln ändert. In der Welt der App-Bereitstellung und -Sicherheit werden diese Regeln teilweise durch die Application definiert. Daher treten keine wesentlichen Änderungen in der Application auf, ohne dass dies auch eine zwingende Funktion für die Weiterentwicklung der App-Bereitstellung und -Sicherheit darstellt.
Dieser Wandel wird noch einige Jahre entfernt sein, aber man kann bereits jetzt die tiefgreifenden Auswirkungen erkennen, die Technologien wie GraphQL und APIs auf alles von der Infrastruktur über Edge bis hin zur App-Bereitstellung haben.
Headless-Architektur ist auf dem Vormarsch und GraphQL wird eine bedeutende Rolle spielen.