Bei Serverless geht es nicht um Server, sondern um Apps
Das Konzept des „Serverless Computing“ sorgt für große Verwirrung. Das könnte daran liegen, dass der Name völlig falsch ist. Es geht weder um Server noch um Computer. Zumindest nicht im traditionellen Sinne des Wortes, in dem die meisten IT-Experten es verwenden.
Serverless bezeichnen wir besser als Functions as a Service (FaaS), denn genau das bietet es. Genau wie FaaS ist auch SaaS serverlos und man kann mit Recht schließen, dass PaaS es ebenfalls ist. Denn der Server – die Rechenleistung – entfällt aus Sicht des Verbrauchers, meist eines Entwicklers. Rechenressourcen (Server, Netzwerk) verbergen sich im Hintergrund, werden automatisch bereitgestellt, verwaltet und skaliert – über ein Netz aus Automatisierung und Orchestrierung, dessen Steuerung der Dienstanbieter übernimmt. Sie bezahlen dafür, doch Sie müssen es nie sehen.
Serverloses FaaS ist kein Ersatz für SaaS, PaaS oder die Cloud im Allgemeinen. Es handelt sich um eine weitere Option auf der Basis vorhandener Modelle, die Entwicklern die spannende Möglichkeit bietet, Funktionen bei Bedarf aufzurufen. Es ist ereignisgesteuert, das heißt, die Funktion wird durch ein Ereignis ausgelöst. Bei diesem Ereignis handelt es sich häufig um die Ausführung eines API-Aufrufs, der die Form einer HTTP-Anforderung mit einer ganz bestimmten URI hat. Ja, ein API-Aufruf.
Der häufigste Anwendungsfall für FaaS ist die Bild- oder Videoverarbeitung. Das liegt daran, dass der Ressourcenbedarf in Häufigkeit und Umfang oft unvorhersehbar ist. FaaS ermöglicht es Ihnen, solche Medien kostengünstig und effizient pro Aufruf zu verarbeiten. Ein weiteres Beispiel stammt aus dem IoT-Bereich, wo Aktionen durch Ereignisse ausgelöst werden, die entweder von einer Steuerungs-App oder direkt vom Gerät ausgehen. Und natürlich gibt es immer den API-Backend-Anwendungsfall, der für die meisten am meisten Sinn macht, weil APIs häufig als URIs beschrieben werden, die Funktionen aufrufen. Egal, was die Funktion tut, sie läuft nur, wenn ein bestimmtes Ereignis sie auslöst, und sie sollte eine einzelne, isolierte Funktion sein.
Dies ist nicht die Cloud, wie wir sie normalerweise sehen oder diskutieren. Das liegt daran, dass es bei der Cloud (IaaS) um Infrastruktur und Betrieb geht, während es bei FaaS (und PaaS und SaaS) um Applications geht. Sie sind als Entwicklungsumgebung gedacht, in der Entwickler Code implementieren können, um einige Aufgaben als Teil einer größeren Application auszuführen. Können Sie eine App aus mehreren FaaS-Implementierungen erstellen? Absolut. In dieser Hinsicht verhält sich FaaS zu SaaS tatsächlich wie Microservices zu Monolithen.
Aber genau das ist der Punkt. Bei FaaS geht es um Applications, nicht um Server. Mit FaaS können Sie keine Cloud implementieren, aber Sie können eine Application entwickeln. Sie können eine App nicht einfach in eine „serverlose“ Umgebung verschieben. Es muss dekonstruiert und dann neu aufgebaut bzw. als eine Sammlung von FaaS neu konzipiert werden.
Die Kombinationen (oder sind es Permutationen?) sind umfangreich. Man könnte FaaS zusammen mit PaaS aus einer in IaaS bereitgestellten App integrieren. IaaS und PaaS könnten vor Ort sein, während FaaS öffentlich ist.
Das Problem bei SaaS, PaaS und FaaS ist, dass Sie die „Server“ nie sehen. Dies gilt nicht für IaaS, wo wir Server „Instanzen“ nennen und diese verwalten und warten müssen. Denn bei IaaS – ob vor Ort oder öffentlich – geht es um die Bereitstellung von Infrastruktur und Betrieb, nicht um Applications. Das war schon immer so, aber wir konnten es im letzten Jahrzehnt ignorieren, weil „Server == Application“ so lange die Norm war.
Doch mit dem Aufkommen von Microservices und APIs und nun auch FaaS können wir nicht länger im Modus „Server == Application“ arbeiten, weil das einfach nicht mehr zutrifft.
Letzten Endes geht es bei FaaS nicht um Server oder wirklich um die Cloud (in dem Sinne, wie wir sie verstehen). Es handelt sich jedoch um einen erheblichen Wandel in der Art und Weise, wie wir Applications konzipieren und entwickeln.