Durch Innovationen wie virtuelle Maschinen (VM), Container und die Public Cloud hat sich die Anwendungsentwicklung auf vielfältige Weise verbessert. Bei diesem Modell müssen zahlreiche Entscheidungen hinsichtlich Konfiguration, Wartung und Optimierung allerdings weiterhin von den Entwicklern gefällt werden, da die Technik ihnen diese nicht abnimmt.
Doch je mehr Zusatzaufgaben den Entwicklern aufgebürdet werden, desto weniger Zeit bleibt ihnen für die Arbeit an Produkten und internen Applikationen. Leider liegt bei vielen weit verbreiteten Verfahren die Verantwortung unter anderem für das Optimieren der Performance, das Skalieren von Anwendungen, Sicherheitspatches und Lastverteilung bei den Entwicklern. Das birgt die Gefahr, dass suboptimale Entscheidungen getroffen oder Fehler begangen werden, die das Budget belasten oder Sicherheitslücken und Ausfälle verursachen.
Eine solche Ineffizienz hat schwerwiegende Folgen. So schlägt die Zeit, die Entwickler mit anderen Aufgaben als dem Programmieren verbringen, bei Unternehmen erschreckenderweise mit mehr als 85 Milliarden US-Dollar im Jahr zu Buche.
Eine vereinfachte Anwendungsentwicklung kommt daher nicht nur dem Entwickler zugute, sondern erlaubt dem Unternehmen auch beträchtliche Kosteneinsparungen.
Die Serverless-Technologie ist darauf ausgelegt, zur Lösung dieser Probleme beizutragen, indem sie die Entwickler entlastet und ihnen so die Arbeit erleichtert. Allerdings lassen sich nicht alle Serverless-Plattformen über einen Kamm scheren. Frühe Versionen hatten noch mit vielen der Konfigurations-, Skalierungs- und Performance-Problemen zu kämpfen, die schon die ihnen zugrundeliegenden Technologien – Container, Regionen und die Public Cloud – geplagt hatten.
Was man heute unter „Serverless“-Technik versteht, ist deshalb oft eine lückenhafte Weiterentwicklung eines alten Modells.
Fortschrittliche Serverless-Plattformen haben diese Probleme jedoch durch mehrere Verbesserungen der Architektur überwunden. Zeitraubende Entscheidungen werden aus dem Entwicklungsprozess ausgegliedert, sodass Teams mehr Zeit darauf verwenden können, erstklassige Produkte und Anwendungen zu entwickeln.
Bevor es Serverless-Plattformen gab, wurden VM und Container genutzt. Bei VM handelt es sich um softwarebasierte Computer, die im Betriebssystem eines anderen Rechners angesiedelt sind. Container sind Standard-Softwareeinheiten, die alle für die Ausführung einer Anwendung erforderlichen Elemente enthalten.
Beide Verfahren erlauben es Entwicklern, sich stärker auf ihre Anwendungen zu konzentrieren als auf die Pflege von Hardware. Allerdings obliegen ihnen bei VM und Containern weiterhin Verwaltungs- und Konfigurationspflichten, die sie von ihrer eigentlichen Arbeit abhalten.
Folgende Aufgaben fallen dabei in unterschiedlichem Umfang für Entwickler und die mit ihnen zusammenarbeitenden IT- und Sicherheitsteams an:
Verwaltung von Sicherheitspatches sowie Identitäts- und Zugriffsberechtigungen
Netzwerk- und Lastverteilungskonfiguration
Sicherstellung der Verfügbarkeit und Redundanzintegration
Systeme zur Container-Orchestrierung wie Kubernetes erleichtern die Erfüllung vieler Konfigurationsanforderungen von Containern, einschließlich des Skalierungs- und Redundanzmanagements. Allerdings benötigen DevOps-Teams, deren Fokus nicht auf der Lösung von kundenseitigen Problemen, sondern auf der Behebung interner Schwierigkeiten liegt, zum effizienten Arbeiten unter Umständen Fachkenntnisse im Bereich Kubernetes. Ohne Kubernetes und ordentlich geschulte Mitarbeitende gelten weiterhin die Beschränkungen von Containern.
Doch VM und Container sind nur ein Teil eines großen Ganzen. Beide Technologien können in der Public Cloud eingesetzt werden, die ihre eigenen Einschränkungen mit sich bringt.
Die Public Cloud trägt zur Vereinfachung diverser Aspekte des Entwickelns bei, doch viele Konfigurationsschritte wie die Auswahl der Regionen, das Sicherheitsmanagement, die Ausgestaltung der Netzwerklösungen und die Gewährleistung der Verfügbarkeit unterliegen weiterhin der Verantwortung des Kundenunternehmens.
Außerdem setzt eine Public Cloud die manuelle Verknüpfung mehrerer Services wie Datenbanken, Message Queues und Speicherdienste voraus. Diese manuell zu konfigurieren und zu vernetzen ist zeitaufwendig und trägt daher zu Verlängerung des Entwicklungsprozesses bei.
Die Serverless-Entwicklung zielte darauf ab, Probleme mit VM, Containern und der Public Cloud zu überwinden. Doch frühe Ansätze waren nur zum Teil erfolgreich.
Zu den größten Herausforderungen von Serverless-Entwicklungsmodellen der ersten Generation zählen:
Latenz und Skalierbarkeit. Viele dieser serverlosen Plattformen werden in einer Public Cloud betrieben, die zur Senkung der Betriebskosten auf zentralisierte Rechenzentren zurückgreift. Bei diesem Modell müssen die Kunden Bereitstellungsregionen für den physischen Standort ihrer Ressourcen auswählen. Die Daten an einem zentralen Ort zu bündeln, verursacht Latenz, weil der Quellcode in großer Entfernung zu den Endnutzern ausgeführt wird. Hinzu kommt, dass eine Skalierung und Bereitstellung in mehreren Regionen zwar möglich, aber kompliziert zu konfigurieren ist.
Kaltstarts und Throttling. Auf Containern aufbauende Serverless-Plattformen haben mit Kaltstarts und Throttling des Prozessors zu kämpfen. Bei Kaltstarts handelt es sich um Verzögerungen beim Laden, zu denen es kommt, wenn eine serverlose Funktion erstmals ausgeführt wird. Sie treten auf, weil es mehrere Sekunden dauern kann, bis Container warmlaufen. Zum Throttling kommt es dagegen, wenn eine Plattform die festgelegte Obergrenze an Serverless-Instanzen erreicht und Anfragen deshalb verzögert werden.
Beeinträchtigtes Entwicklererlebnis. Entwickler müssen oft zeitraubende Aufgaben wie die Einrichtung von Orchestrierungs-Templates, die Bewertung des Umfangs einer künftigen Anwendung und die Festlegung der Speicherebenen übernehmen. Dabei kann es zu kostspieligen Fehlern kommen. Zudem geht dies auf Kosten der Programmierzeit, sodass das Unternehmen für Überstunden aufkommen muss.
Beschränkte Beobachtbarkeit. Viele serverlose Entwicklungsplattformen lassen sich nur schwer überwachen, weil sie keine angemessene Beobachtbarkeit bieten. Unter Beobachtbarkeit versteht man den Umfang, in dem sich ein Unternehmen unter anderem mittels Performance-Kennzahlen und Ereignisprotokollen einen Überblick über die Vorgänge in einem dezentralen System verschaffen kann. Ohne angemessene Beobachtbarkeit können Probleme innerhalb einer Serverless-Anwendung weder effizient diagnostiziert noch behoben werden.
Eingeschränkte Anwendungsfunktionalität aufgrund von Zustandslosigkeit. Die erste Generation serverloser Plattformen ist faktisch zustandslos. Diese Zustandslosigkeit erleichtert die Skalierung, kann aber das Entwickeln von Anwendungen erschweren, die eine hohe Einheitlichkeit oder eine Koordinierung zwischen verschiedenen Clients in Echtzeit erfordern, wie das bei interaktiven Chats, Videospielen oder gemeinsam genutzten Bearbeitungstools der Fall ist.
Kosten. Viele cloudbasierte Serverless-Plattformen bringen zusätzliche und oft verdeckte Kosten mit sich, beispielsweise in Form von Gebühren für API-Gateways oder für das Inbetriebhalten von Containern. Daher kann die Entwicklung von Anwendungen mit solchen Plattformen der ersten Generation insbesondere in einem gewissen Maßstab mit hohen Kosten verbunden sein.
Zweck von Serverless-Systemen war es immer, die Anwendungsentwicklung zu vereinfachen. Doch serverlose Plattformen, die in einer zentralisierten Public Cloud betrieben werden, können diesem Versprechen nicht voll und ganz gerecht werden.
Die nächste Generation von Serverless-Entwicklungsplattformen hat viele Defizite früherer Angebote überwunden. Diese Lösungen setzen nicht auf althergebrachte Infrastrukturen wie Container und die Public Cloud. Sie sind daher früheren Versionen in vieler Hinsicht überlegen und können den Entwicklern einen Teil ihrer Zeit zurückgeben.
Zu den Verbesserungen gehören:
Betrieb am Netzwerkrand. Die fortschrittlichsten Serverless-Plafformen werden in der Edge ausgeführt, einem dezentralen Netzwerk, das aus zahlreichen Rechenzentren besteht. Je größer das Netzwerk, desto besser wird es mit Performance- und Skalierungsproblemen fertig. Grund dafür ist, dass bei Edge-Netzwerken die Datenverarbeitung an einem dem Endnutzer am nächsten gelegenen Point of Presence erfolgt. Durch diesen dezentralen Ansatz sinkt die Latenz und er unterscheidet sich grundlegend von den zentralisierten Regionen der Public Cloud. Die Implementierung von Quellcode in einem aus Hunderten Rechenzentren bestehenden Netzwerk erlaubt daher eine höhere Performance als bei einem Netzwerk mit nur 20 Rechenzentren. Die ausgereiftesten Edge-Plattformen bieten lange Prozessorzeiten zur Entwicklung komplexer Workloads.
Verwendung von Isolaten anstelle von Containern. Mit dieser Herangehensweise entledigt man sich Problemen wie Kaltstarts und Throttling, die bei containerbasierter Architektur auftreten und deren Behebung mit hohen Kosten verbunden ist. Anders als Container müssen Isolate nicht in Betrieb gehalten werden, Kaltstarts sind daher kein Thema. Außerdem beanspruchen Isolate weniger Speicher, was die Betriebskosten senkt und Throttling-Schwierigkeiten aus der Welt schafft.
Weniger Vorabentscheidungen. Einige der neueren Serverless-Plattformen optimieren Anwendungen automatisch hinsichtlich Performance und Sicherheit. Darüber hinaus müssen Entwickler bei Lösungen mit globalen Edge-Netzwerken nicht entscheiden, in welchen Regionen ihre Workloads gehostet werden, weil der Quellcode in allen Rechenzentren des Netzwerks implementiert wird. Der Wegfall dieser lästigen Aufgaben macht den Entwicklern das Leben leichter.
Ausführliche Analysen und Protokolle. Während frühere Serverless-Plattformen kaum Analyse-, Fehlerbehebungs- oder Protokollfunktionen zu bieten hatten, zeichnen sich fortschrittliche serverlose Edge-Plattformen durch eine höhere Beobachtbarkeit aus. Ausführliche Analytics und Protokolle erleichtern den Entwicklern das Sammeln der Informationen, die sie für die Fehlerbehung benötigen. Einige Plattformen lassen sich zudem mit ausgefeilteren Überwachungstools kombinieren, was für komplexere Anwendungen erforderlich sein kann.
Integrierte Abstimmung und Speicherung. Diese Funktion ermöglicht eine zustandsbehaftete Architektur mit Serverless-Technologie. Voraussetzung dafür ist im Gegensatz zu zustandslosen Anwendungen, bei denen Daten nur übertragen werden, eine einheitliche Datenspeicherung. Ohne zustandsbehaftete Architektur ist die Entwicklung interaktiver Echtzeit-Anwendungen nicht möglich.
Kosteneffizienz. Ressourcenschonende serverlose Edge-Plattformen auf Isolat-Basis sind günstiger als ihre containerbasierten Vorgänger. Eine Isolat-Architektur bietet alle Vorteile hinsichtlich Skalierbarkeit und Flexibilität der Cloud, geht aber weder mit versteckten Gebühren noch mit einer Kostenexplosion einher.
Dank dieser Verbesserungen wird die gesamte Anwendungsoptimierung durch Serverless-Plattformen der nächsten Generation optimiert. Lästige Aufgaben entfallen, sodass sich die Entwickler auf ihr eigentliches Tätigkeitsfeld konzentrieren können und das Unternehmen Kosten spart.
Die richtige Serverless-Plattform überwindet Skalierbarkeitsgrenzen, entlastet Entwickler und erhöht die Gesamteffizienz der Anwendungsentwicklung. Cloudflare Workers ist eine Edge-basierte serverlose Plattform, die smarte Infrastruktur nutzt, um Entwicklern viele Vorabentscheidungen abzunehmen. Dank der Cloudflare-Infrastruktur sind auf Workers aufbauende Anwendungen hinsichtlich Sicherheit, Performance und Zuverlässigkeit grundsätzlich optimiert.
Skalierbarkeit ist nie ein Problem, weil Workers auf dem globalen Cloudflare-Netzwerk betrieben werden, das mehr als 330 Städte in über 120 Ländern umfasst. Quellcode wird automatisch in allen Regionen implementiert, ohne dass zusätzliche Kosten anfallen oder eine weitere Konfiguration erforderlich ist. Entwickler-Teams können mithilfe von Workers Unbound anspruchsvolle Anwendungen an der Edge erschaffen, die lange CPU-Laufzeiten mit sich bringen. Weil die Workers-Plattform nicht auf Container, sondern auf Isolierungen zurückgreift, sind Kaltstarts und Throttling kein Thema. Workers bietet integrierte Beobachtbarkeit und ist mit ausgefeilteren Überwachungstools wie New Relic oder Sentry und mit über das Workers Command Line Interface (CLI) verfügbaren Fehlerbehebungs- und Protokollierungslösungen kombinierbar. Durable Objects bieten eine latenzarme Abstimmungsfunktion und eine einheitliche Speicherung für die Workers-Plattform, was zustandsbehaftete Serverless-Anwendungen möglich macht. Zugleich sparen Kunden durch Workers Geld, weil keine versteckten Gebühren anfallen und wir konkurrenzlos günstig sind.
Workers erlaubt es Entwickler-Teams, dem Produktaufbau ihre gesamte Aufmerksamkeit zu schenken, anstatt sich mit Wartung und Konfiguration beschäftigen zu müssen. Dies verbessert die Entwicklererfahrung und kommt dem Unternehmen auf längere Sicht finanziell zugute.
Dieser Beitrag ist Teil einer Serie zu den neuesten Trends und Themen, die für Entscheidungsträger aus der Tech-Branche heute von Bedeutung sind.
Folgende Informationen werden in diesem Artikel vermittelt:
Was durch eine ineffiziente Entwicklungsarchitektur auf dem Spiel steht
Wie Serverless aus früheren Entwicklungsmethoden hervorgegangen ist
Inwiefern frühe Serverless-Versionen die Anwendungsentwicklung nicht vereinfacht haben
Die wichtigsten Unterschiede bei Serverless-Lösungen der nächsten Generation
Mehr über Serverless-Plattformen wie Workers erfahren Sie in dem Bericht The Forrester New Wave: Function-as-a-Service Platforms.