Definition „Serverless“

Was ist Serverless Computing?

| Autor / Redakteur: Pyrocco / Stephan Augsten

Serverless Computing dient der Vereinfachung der Anwendungsentwicklung und -bereitstellung in der Cloud.
Serverless Computing dient der Vereinfachung der Anwendungsentwicklung und -bereitstellung in der Cloud. (Bild gemeinfrei: Lee Campbell / Pexels)

Serverless Computing ist ein Cloud-Computing-Modell, bei dem der Anbieter die Ressourcen für eine Anwendung dynamisch verwaltet. Der Entwickler benötigt kein näheres Wissen über das Backend. Abgerechnet wird nur die tatsächliche Ressourcennutzung.

Serverless Computing dient der Vereinfachung der Anwendungsentwicklung und -bereitstellung in der Cloud. Skalierungs-, Kapazitätsplanungs- und Wartungsvorgänge der Infrastruktur, auf der eine Anwendung läuft, liegen in der Verantwortung des Cloud-Anbieters. Daher stellt sich die Entwicklung und der Betrieb aus Kundensicht quasi „serverlos“ dar, auch wenn im Backend weiterhin Server arbeiten. Der Entwickler kann sich so auf die Funktionalität der Anwendung konzentrieren.

Architektur: Function-as-a-Service

Bei Serverless Computing stellt sich das Backend der Anwendung als leichtgewichtige Funktionen dar. Jede davon führt eine eigene Aufgabe in der Anwendung aus und startet und stoppt auf Ereignisse (Events) hin. Entwickler müssen für Serverless Computing also Funktionen definieren, die für bestimmte Ereignisse aufgerufen werden.

Diese Architektur wird daher Function-as-a-Service (FaaS) genannt. Die einzelnen Serverless-Funktionen, die jeweils nur eine einzige fachliche Aufgabe erfüllen, lassen sich in der Regel klein und kompakt halten. Die Komplexität der Anwendung entsteht durch die Komposition. Updates können allein auf der Ebene der kleinen Funktionen durchgeführt werden.

Serverless-Komponenten auf Seiten des Providers

Eine Serverless-Architektur auf Providerseite umfasst die Bestandteile

  • Entgegennehmen und Sammeln von Events,
  • Strategie für die Speicher- und Prozessorzuteilung,
  • Rechen- und Netzwerkkapazität zur Bearbeitung der Events.

Vergleich mit bisherigen „As-a-Service“-Konzepten

Trotz des Begriffs „serverless“ beinhaltet das Konzept also weiterhin Server. Diese werden aber für den Anwender noch weiter abstrahiert als bei bisherigen „As-a-Service“-Diensten. Gegenüber den Konzepten Platform-as-a-Service und Backend-as-a-Service vereinfacht sich die Entwicklung.

Anwendungen können aus FaaS-Funktionen ohne Wissen über die Infrastruktur der Serverseite entwickelt werden. Der Entwickler und Anwendungsanbieter muss sich nicht um Server-Rechner, Netzwerkkonfigurationen, Firewalls, Installationen und Updates auf der Serverseite kümmern. Um die Skalierbarkeit müssen sich Entwickler daher ebenfalls nicht kümmern; dies ist die Aufgabe des Cloud-Providers.

Kosten nach tatsächlicher Ressourcennutzung

Serverless Computing wird nach genutzten Ressourcen abgerechnet und lässt sich damit dem Utility Computing zuordnen. Kunden zahlen nur für tatsächlich genutzte Speicher- und Rechenressourcen.

Im Vergleich zum Cloud-native Computing findet bei Serverless Computing eine effizientere Nutzung der Ressourcen statt. Beim Cloud-nativen Ansatz sind beständig Microservices in Containern aktiv. Serverless-Funktionen werden dagegen erst bei Erfordernis durch Events ausgelöst. Container sind zudem nicht automatisch skalierbar.

Vorteile

  • Geringere Kosten: Serverless Computing ist im Allgemeinen sehr kosteneffektiv, da bei herkömmlichen Backend-Diensten der Kunde auch für nicht genutzten Speicherplatz und nicht genutzte CPU-Zeit bezahlt.
  • Vereinfachte Skalierbarkeit: Entwickler, die eine Serverless-Architektur verwenden, müssen sich keine Gedanken zur Skalierung ihres Codes machen. Der Serverless-Computing-Anbieter übernimmt die gesamte Skalierung.
  • Vereinfachter Backend-Code: Mit FaaS können Entwickler Anwendungen aus einfachen Funktionen erstellen nach dem Vorbild von Microservices, die unabhängig voneinander einen einzigen Zweck erfüllen.
  • Vereinfachte Wartung: Updates können wie bei Microservices unterbrechungslos eingeführt werden. Es muss keine Anwendung als Ganzes neu verteilt werden. Updates erfolgen durch neue Versionen der leichtgewichtigen Funktionen, aus denen sich Serverless-Computing-Anwendungen zusammensetzen.
  • Schnellere Abwicklung: Serverless Computing kann die Markteinführungszeit von Software erheblich verkürzen. Es entfällt die Aufgabe, die Software auf ein spezifisches Backend abzustimmen, dieses zu verwalten und die Skalierbarkeit einzubeziehen.

Nachteile

  • Debugging: Bei Debugging und Monitoring müssen Entwickler mit Einschränkungen rechnen. Da sie zur Vereinfachung vom Wissen über die Serverseite entbunden sind, haben sie auch kaum Einblicke in die Backend-Prozesse. Tiefere Analysen mit Debuggern und Performance Management-Tools sind meist nicht möglich. In den Plattformen der großen Anbieter ist einfaches Debugging integriert, das aber hinter den Möglichkeiten heutiger Entwicklertools zurückbleibt. In lokalen Testumgebungen lassen sich proprietäre Umgebungen des Providers nicht genau nachbilden.
  • Performance: Da sich die Ressourcen automatisch dem Bedarf anpassen, werden Funktionen erst bei Bedarf gestartet. Dieser (Neu-)Start kann Geschwindigkeitsnachteile bringen.
  • Vendor-Lock-In: Um sich nicht nur auf die Infrastruktur eines einzelnen Prodviders hin zu entwickeln, gibt es Frameworks wie beispielsweise das Node.js-basierte Serverless Framework. Dieses bietet Unterstützung für Amazon AWS, Apache OpenWhisk, Microsoft Azure und Google Cloud Functions.

Fazit

Unter Beachtung der Nachteile können Unternehmen mit Serverless Computing von der schnellen Bereitstellung und Skalierung und der nutzungsabhängigen Abrechnung profitieren.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Aktuelle Beiträge zu diesem Thema

Cloud-native Alternativen zu Jenkins

Consol testet moderne CI- und CD-Tools

Cloud-native Alternativen zu Jenkins

Beim Cloud-native Development stoßen gängige Continuous-Integration- und -Delivery-Tools an ihre Grenzen. Auf Microservice-Architekturen sind diese Werkzeuge schlicht nicht ausgerichtet, meint das Consulting-Unternehmen Consol, das einige Alternativen identifiziert hat. lesen

Entwickler wählen Tools, Container-Hype stagniert

Weltweite Umfrage der Cloud Foundry Foundation

Entwickler wählen Tools, Container-Hype stagniert

Entwickler werden bei steigender IT-Komplexität im Unternehmen mehr in die Entscheidungsfindung mit einbezogen. Ihr eigenes Credo lautet dann: „Mehr Abstraktion und weniger Komplexität“, sagt die Cloud Foundry Foundation mit Blick auf die jüngste „Global Perception Study“. lesen

Läuft Go bald Java den Rang ab?

Golang für Cloud-native Entwicklung

Läuft Go bald Java den Rang ab?

Verteilte Anwendungsarchitekturen überfordern traditionelle Programmiersprachen. Entwickler von Microservices suchen händeringend nach besseren Alternativen. Kann Go die Platzhirsche ablösen? lesen

Entwickeln für Serverless-Umgebungen

Function as a Service

Entwickeln für Serverless-Umgebungen

Wer vorrangig eine Anwendung coden und sie nicht zusätzlich orchestrieren möchte, entwickelt für Serverless. Doch der „Function as a Service“- oder kurz FaaS-Ansatz hat seine ganz eigenen Spielregeln und bricht mit dem klassischen DevOps-Gedanken. lesen

Wo Microservice-Architekturen sinnvoll sind

Bereitstellung nach dem Prinzip „Teile und herrsche“

Wo Microservice-Architekturen sinnvoll sind

Leichtgewichtig, zustandslos und bedarfsgerecht skalierbar: Microservice-Architekturen haben es in sich. Gleichzeitig verändern sie die Art und Weise, wie Unternehmen ihre Software entwickeln und bereitstellen. lesen

Die ideale DevOps-Teamstruktur

Kooperation nach dem Gesetz von Conway

Die ideale DevOps-Teamstruktur

Die Zusammenarbeit von Development und Operations verbessert und beschleunigt Prozesse. Doch erst eine wohlüberlegte DevOps-Struktur hilft dabei, dass die beiden völlig unterschiedlichen Bereiche reibungslos miteinander kooperieren. lesen

Vorteile der verteilten Datenhaltung

Dokumentorientierte NoSQL-Datenbanken, Teil 2

Vorteile der verteilten Datenhaltung

Die verteilte Datenhaltung von NoSQL-Plattformen bietet einige Vorteile, darunter Hochverfügbarkeit, Workload Isolation und Datenlokalität. Wie die Technik dahinter funktioniert, schauen wir uns hier genauer an. lesen

Lambda-Entwicklung mit Cloudlocal

Stackery will Serverless Computing vorantreiben

Lambda-Entwicklung mit Cloudlocal

Stackery ermöglicht es Entwicklern, lokal Lambda-Funktion in jeder Sprache und jedem Framework zu entwickeln und zu debuggen. Mit Cloudlocal soll die serverlose Entwicklung beschleunigen. lesen

Amazon Polly und Pinpoint konfigurieren

Serverless-Architekturen unter AWS, Teil 2

Amazon Polly und Pinpoint konfigurieren

Als Vorbereitung für unsere serverlose Text-to-Speech-App widmet sich dieser Artikel den Grundlagen von Amazon Polly und Pinpoint. Mithilfe der beiden AWS-Dienste wollen wir Sprachnachrichten automatisiert versenden. lesen

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46197303 / Definitionen)