Serverless Computing verstehen: Infrastrukturmanagement vereinfachen

Infrastrukturmanagement fügt dem modernen Software-Development-Workflow eine zusätzliche Komplexitätsebene hinzu. Server am Laufen halten, Security Updates pflegen und Ressourcen skalieren kostet DevOps-Teams wertvolle Zeit. Mit Serverless Computing werden alle Infrastructure-Operations vom Service Provider übernommen. Dadurch erlaubt Serverless Development Teams, sich auf Code-Schreiben zu fokussieren, statt zu viel Zeit auf Infrastrukturmanagement zu verwenden.

Dieser Artikel erklärt, was Serverless Computing ist und wie es sich zu verschiedenen Cloud-Deployment-Modellen verhält. Wir erkunden auch Vor- und Nachteile von Serverless und besprechen einige gängige Use Cases.

Was ist Serverless Computing?

Serverless Computing ist eine Methode, Code in der Cloud zu deployen und auszuführen, ohne sich um Server-Provisioning und Infrastrukturmanagement kümmern zu müssen. Trotz des Namens basiert Serverless weiterhin auf Cloud- oder physischen Servern für Code Execution. Entwickler müssen sich jedoch nicht um die zugrundeliegende Infrastruktur kümmern. Dies übernimmt der Serverless-Provider, der die notwendigen Compute-Ressourcen dynamisch allokiert und im Namen des Nutzers managt.

Für Entwickler bedeutet das: Null Zeit für Server-Administration, Maintenance, Resource Scaling oder Capacity Planning. Sie laden einfach ihren Code hoch und lassen den Provider die server-seitige Logik basierend auf verschiedenen Events oder Requests ausführen. Im Gegensatz zu bekannten Cloud-Billing-Modellen werden Serverless Services basierend auf der Anzahl der Code-Ausführungen oder beim Auslösen eines bestimmten Events abgerechnet.

Wie funktioniert Serverless Computing?

In einer Serverless-Umgebung wird Code durch Events getriggert und als Funktion ausgeführt. Deshalb wird Serverless oft mit „Functions-as-a-Service“ (FaaS) assoziiert – einem ähnlichen Konzept. FaaS ist ein event-getriebenes Cloud-Modell, das die server-seitige Logik für Code Execution ohne Nutzer-Intervention handhabt. Diese Events können alles sein – von simplen HTTP Requests, API Calls bis hin zu Database Queries oder File Uploads.

Funktionen werden in zustandslosen Containern ausgeführt. Das bedeutet, Compute-Ressourcen für das Ausführen einer Funktion werden nur bei Invocation provisioniert. Keine Daten persistieren in RAM oder werden auf Disk geschrieben. Sobald der Request erfüllt ist, wird der State der App zurückgesetzt und es gibt kein Memory der Transaktion. Ein neuer Request ruft die Provisionierung der Ressourcen von Grund auf neu hervor und der Code wird ohne Referenz zur vorherigen Invocation ausgeführt.

Um diesen zustandslosen State zu accommodieren, müssen Applikationen als Funktionen architekturiert sein, die in zustandslosen Containern laufen können. Dies wird meist durch Microservices erreicht. Große Monolith-Apps werden in kleinere Segmente zerlegt und über eine API miteinander verbunden. Monolith-Apps können zwar als einzelne Funktionen laufen, aber das ist unüblich. Da bei jedem Request ein neuer Compute Container provisioniert wird, beeinträchtigen große Funktionen Execution Speed und Duration negativ.

FaaS Functions laufen nicht unendlich. Sie werden nach einer gewissen Zeit nach Aufruf terminiert. In den meisten Fällen timeout Functions nach ca. fünf Minuten. Das bedeutet, Apps, die Long-Duration Tasks laufen, müssen redesigned werden, um Termination Limits Rechnung zu tragen.

Provisioning und Initialisierung von Containern für Function Execution nimmt auch Zeit in Anspruch. Dies wird meist in Millisekunden gemessen. Komplexe Functions können jedoch mehrere Sekunden für Initialisierung brauchen, was größere Latenz verursacht.

Es gibt zwei gängige Methoden für Function Initialisierung – Warm Start und Cold Start. Ein Warm Start reused Ressourcen von einem vorherigen Event, während ein Cold Start einen neuen Container deployed. Die Zeit für Initialisierung und Execution einer Function hängt von Code-Menge, Programmiersprache, Anzahl der Libraries, die das Script nutzt, und vielen weiteren Faktoren ab. In Sachen Latenz braucht ein Cold Start mehr Zeit für den Function Start.

Vergleich: Serverless Computing vs. BaaS, PaaS und IaaS

Wie bei jedem Software-Trend gibt es keine offizielle Definition, die beschreibt, was Serverless ist und was nicht. Deshalb wird Serverless Computing oft mit anderen Cloud Services und Deployment-Modellen verwechselt. Das Konzept von Serverless Computing dreht sich um zwei ähnliche Bereiche:

Backend-as-a-Service (BaaS) – BaaS ermöglicht Entwicklern, sich auf Frontend-Interfaces zu fokussieren, während alle Backend-Operationen an einen Service Provider ausgelagert werden. Diese Behind-the-Scenes Tasks involvieren meist Ready-to-go User Authentication, Storage, Database Management und Hosting Services. Auch müssen Entwickler keine Server managen, die ihr Backend laufen lassen – was schnellere App Deployments ermöglicht.

Functions-as-a-Service (FaaS) – Dieses Serverless Cloud Service Model macht Infrastrukturmanagement überflüssig. Der Service Provider ist tasked mit On-Demand Deployment von Compute-Ressourcen zur Execution des User Codes. Das passiert immer, wenn ein Event oder Request getriggert wird. Serverless Functions laufen in zustandslosen Containern – Compute Ressourcen werden nur deployed, wenn die Function invoked wird.

Der Hauptverwirrungspunkt liegt zwischen Backend-as-a-Service und Platform-as-a-Service (PaaS). Ersteres ist eine Technik des Serverless Computing, letzteres ein Cloud Deployment Model. Obwohl sie einige Basischarakteristika teilen, ist PaaS nicht aligned mit Serverless-Anforderungen.

Platform-as-a-Service (PaaS) – Bei PaaS mieten Nutzer Hardware und Software Solutions, die für Development Workloads nötig sind, von einem Service Provider für eine Subscription Fee. Es erlaubt Entwicklern, mehr Zeit mit Coding zu verbringen, ohne sich um Infrastrukturmanagement zu kümmern. Andererseits bietet BaaS zusätzliche Features wie Out-of-the-box User Authentication, Managed Databases, Email Notifications etc. BaaS erlaubt Entwicklern auch, sich ausschließlich auf Frontend Building zu fokussieren, während verschiedene Backend Services on Demand integriert werden.

Infrastructure-as-a-Service (IaaS) – IaaS bezeichnet eine Self-Service Cloud Solution, bei der der Provider die Infrastruktur im Namen des Nutzers hostet. Alle Server Provisioning und Management Operations einschließlich Software Installation werden vom Nutzer gehandhabt. Manche IaaS Provider bieten auch Serverless Solutions an – aber als distinkte, separate Produkte.

Gängige Serverless Computing Use Cases

Wie bereits erwähnt, ist Serverless nicht für jeden. Aber wenn Ihre Bedürfnisse mit einigen dieser Use Cases alignen, könnten Sie von Serverless profitieren.

APIs bauen

Ohne Server zu managen, ist das Bauen hochskalierbarer und responsiver APIs einer der beliebteren Use Cases für Serverless. Das Auto-Scaling Feature von Serverless stellt sicher, dass APIs auch unter schwerem Traffic immer verfügbar sind. Zusätzlich wird der Nutzer für Idle Resources nicht belastet, wenn keine Calls an die API erfolgen.

Websites und Applikationen

Das Deployen von Websites und Web-based Apps auf einer Serverless Plattform erfordert kein vorheriges Infrastructure Setup. Das verkürzt die Time-to-Launch einer voll funktionsfähigen Web App signifikant. Das Auto-Scaling Feature spielt auch hier eine große Rolle, weil der Nutzer sich nicht um Provisioning weiterer Server für Demand-Spikes kümmern muss. Resultat: 100% Uptime ist viel einfacher zu halten.

Multi-Language Applikationen

Mit Serverless kann eine einzelne App in verschiedenen Sprachen geschrieben werden. Serverless erlaubt Entwicklern, eine Monolith App in kleinere Teile zu zerlegen und als Microservices laufen zu lassen. Diese Microservices kommunizieren dann via API miteinander. Jedes Segment einer App kann mit einer anderen Programmiersprache geschrieben werden.

CI/CD Pipelines

Automation ist der Schlüssel für erfolgreiche Development, Testing und Integration Pipelines. Serverless erlaubt Entwicklern, Code automatisch zu testen und Bugs schneller zu fixen. Da Serverless event-basiert ist, können Nutzer Events setzen, die automatisierte Tests ohne manuelle Intervention triggern.

Was sind die Vorteile von Serverless Computing?

Im Vergleich zu traditionellem server-orientiertem Cloud Computing abstrahiert Serverless Computing Infrastructure Operations weg. Alles funktioniert Out-of-the-box, was schnellere Code Releases und automatisierte Skalierbarkeit zu einem niedrigeren Preis sicherstellt.

Das sind die drei häufigsten Vorteile von Serverless:

Auto-Scaling

Der Serverless Provider skaliert Infrastructure Ressourcen basierend auf Demand. Scaling Operations werden dynamisch und automatisch ohne Developer Intervention durchgeführt.

Faster Time to Market

Ohne komplexe Server Cluster provisionieren zu müssen, können Entwickler sich mehr auf höhere Release Velocity fokussieren. Das beschleunigt die Zeit, die es braucht, Code in Production zu releasen oder inkrementelle Code Changes zu implementieren – resultierend in schnellerer Delivery von Apps an Kunden.

Optimierte Kosten

Da alles On-Demand provisioniert wird, müssen Organisationen nie für ungenutzten Storage Space, Compute Time oder Networking zahlen. Consumption von Serverless Services wird typischerweise in Millisekunden gemessen und entsprechend abgerechnet.

Was sind die Nachteile von Serverless Computing?

Wie bei jeder Software Solution kommt Serverless mit einigen Downsides. Aber je nach App, die Sie bauen, könnten Sie sich um manche dieser Serverless-Nachteile weniger sorgen.

Latenz

Bei Execution einer Function deployen Serverless Provider automatisch notwendige Ressourcen bei jeder Invocation. Je nach Workload Size werden Container typischerweise in Millisekunden provisioniert, können aber auch mehrere Sekunden dauern. Latenz kann durch „Warm Starts“ reduziert werden, die Instanzen von vorherigen Executions wiederverwenden.

Execution Duration

Die Execution Time einer Serverless Function ist begrenzt und wird nach einer gewissen Periode abgebrochen. Das sind meist ca. fünf Minuten nach Invocation, variiert aber across Providern. Execution Limits sind ein Major Drawback für Apps, die Long-Duration Processes initiieren. Mitigation ist möglich durch Segmentierung des Codes in kleinere Chunks und Ausführung als Microservices.

Vendor Lock-In

Provider nutzen meist proprietäre Technologien für ihre Serverless Services. Das kann Issues für Nutzer verursachen, die Workloads auf eine andere Plattform migrieren wollen. Beim Wechsel zu einem anderen Provider sind Änderungen an Code und App-Architektur unvermeidlich.

Sicherheit

Nutzer haben wenig Kontrolle über die Instanz-Konfiguration, die ihren Code läuft. Das ist vor dem User verborgen und fällt in den Bereich des Service Providers. Dementsprechend fallen Security Operations auch in die Hände des Providers. Der Nutzer ist hilflos, wenn ein Angriff erfolgt – er verlässt sich solely auf den Provider für Damage Mitigation und System Recovery. Applikationen mit mehreren Entry Points in einer Serverless Umgebung sind anfälliger für Vulnerabilities durch erhöhte Attack Surface.

Zukunft von Serverless Computing

Serverless Computing ist noch eine relativ neue Technologie. Ihre Zukunft hängt von der Fähigkeit der Service Provider ab, einige der oben genannten Drawbacks zu lösen – am wichtigsten Cold Starts. Provider müssen die Zeit verkürzen, die es braucht, eine Function nach Idle State auszuführen. Das Lösen dieses Issues wird Latenz verringern und nahtlose User Experience sicherstellen.

Serverless basiert aktuell auf zustandslosen Containern für Function Execution. Die Zukunft von Serverless bewegt sich Richtung Enabling von Stateful Apps, um die Benefits von Serverless zu nutzen. Das wird Entwicklern erlauben, Stateful Apps zu bauen, ohne sich um Backend Data Management zu kümmern.

In Sachen DevOps wird Serverless zur Expansion von NoOps führen. Dieser Trend wird dazu führen, dass Serverless Provider alle Infrastructure Operations im Namen des Kunden handhaben. In einem solchen Setting brauchen Unternehmen keine Inhouse Operations Teams mehr.

In den kommenden Jahren wird Kubernetes erwartet, zur Foundation von Serverless zu werden. Mit Support für Networking, agiles Auto-Scaling und Multi-Cloud Deployments enhancet Kubernetes Portability Serverless Computing in mehr als einer Hinsicht. Das Ausführen bestimmter App-Klassen in Serverless ist impraktisch, da Service Provider manchmal deren Verhalten limitieren. Mit Kubernetes können Entwickler diese Limitations überwinden und Serverless Plattformen basierend auf ihren spezifischen Bedürfnissen bauen.

Fazit

Auch wenn der Name das Fehlen von Servern suggeriert, basiert Serverless Computing weiterhin auf Cloud- oder physischen Servern. Es ist ein Computing Model, das Infrastructure Operations eliminiert und Entwicklern erlaubt, sich auf Writing und Deploying von Apps zu fokussieren. Das Serverless Model dreht sich um zwei Kernbereiche: Backend-as-a-Service und Functions-as-a-Service.

Ersteres bietet Nutzern eine Ready-to-go Backend Architektur, letzteres ermöglicht Apps in zustandslosen Containern laufen zu lassen. Diese Container werden automatisch basierend auf Events oder Triggers provisioniert. Serverless ist also keine Silver Bullet Lösung für alle aktuellen Development Probleme. Es istmostly ausgerichtet auf Non-Monolith Apps, die eine Microservices-basierte Architektur einsetzen.