Machen Sie sich bereit. Serverlos kommt.

 
Die Technologie entwickelt sich schnell. Oder vielleicht scheint es nur so, als ob alles schnell vorangeht, weil ständig neue Bewegungen, Ansätze und Architekturen auftauchen. In diesem Monat rücken „serverlose“ Architekturen plötzlich in den Vordergrund des Twitter-Streams und Bewusstseins aller. Zumindest, wenn Sie in der Dev/Ops-Welt tätig sind.

Für diejenigen unter Ihnen, die sich mit Infrastruktur- und Netzwerkarchitektur und -betrieb befassen und noch nicht von dieser neuen Architektur überschwemmt wurden, handelt es sich um eine logische Weiterentwicklung von monolithischen –> Mikroservices –> serverlosen Architekturen. Es handelt sich um eine weitere Aufschlüsselung der Apps nach geschäftlicher Nutzung –> Dienst –> Funktion.

Im wahrsten Sinne des Wortes geht es um Funktionen. Ereignisgesteuerte, feinkörnige Funktionen.

Und jeder von ihnen konzentriert sich auf einen noch kleineren Anwendungslogikbereich als ein Microservice. Während ein Microservice die gesamte Anwendungslogik enthalten kann, die zur Implementierung eines „Profildienstes“ erforderlich ist, zerlegt die serverlose Architektur diesen noch weiter in einzelne Funktionen. Eine zum Anmelden, eine zum Abmelden, eine zum Ändern Ihres Passworts und eine zum Zurücksetzen. Im Grunde ist es so, als würden Sie für jede Aktion, die Sie innerhalb einer App ausführen, einen kleinen, zielgerichteten Dienst erstellen.

Der Grund für die Bezeichnung „serverlos“ liegt darin, dass es sich grundsätzlich um eine hochentwickelte Form von PaaS handelt. Das ist gut für PaaS, denn als Markt hat sich PaaS nie wirklich zu dem Giganten entwickelt, der es werden wollte. Es hängt einfach da herum und bekommt Lob von Fanboys, die es lieben, wird aber größtenteils ignoriert und wächst in einem Tempo, das bei weitem nicht so aufregend ist wie das einer privaten oder öffentlichen Cloud und schon gar nicht das von SaaS. In einer serverlosen Architektur ist der Cloud-Anbieter für alles verantwortlich, außer für den Code, der erforderlich ist, um etwas zu tun, wenn ein Benutzer eine Schaltfläche oder ein Kontrollkästchen betätigt oder auf einen Link klickt. Das ist der Ereignisteil von „ereignisgesteuert“: Wenn der Benutzer die Schaltfläche drückt, wird die Funktion „in der Cloud“ ausgeführt . Diese Funktion ist im Allgemeinen Teil einer größeren API, die von einem anderen Dienst in der Cloud verwaltet wird.

Wichtig hierbei ist, dass die Person, die die Funktion schreibt, keine VM oder keinen Container bereitstellt, konfiguriert oder startet. Sie machen sich keine Gedanken über betriebliche Details wie die Größe. Sie schreiben einfach etwas Code und mit einem Mausklick: voilà! Sofortige Funktionalität.

Dies ist Cloud in ihrer extremsten Form, da die Stack-Entwickler nun für die Verkleinerung auf eine einzige Schicht, die Anwendungsschicht, verantwortlich sind. „Nichts anderes zählt“, wie Metallica sagen würde. Jedes betriebliche Detail wird durch die zugrunde liegende Plattform bereitgestellt. Es ist NoOps, zumindest aus der Sicht des Entwicklers.

Denn Sie wissen, dass es Server, Dienste, Infrastruktur und ein Netzwerk unter der Plattform gibt, die diese magische Fähigkeit bereitstellen. Es ist einfach nichts, worüber sich der Entwickler Gedanken machen muss. Aber für Sie als Fachmann für Infrastruktur- oder Netzwerkbetrieb ist das der Fall.

Aus diesem Grund ist es unwahrscheinlich, dass die Unternehmen so schnell auf diesen Zug aufspringen werden. Hierzu ist eine voll funktionsfähige Cloud-Computing-Umgebung erforderlich, die nicht nur Funktionen zur Bereitstellung virtueller Maschinen oder Container, sondern auch eine automatische Skalierung umfasst. Mit anderen Worten: Skalierung ohne Parameter oder Eingaben von Entwicklern. Es sollte einfach passieren, verdammt noch mal, und das ist alles. Es handelt sich nicht um Selbstbedienung, sondern um Auto -Service. Es geht nicht nur um Skalierung, sondern auch um automatische Bereitstellung. Und Überwachung, Berichterstattung und so ziemlich alles, was heute mit dem Betrieb zusammenhängt. Aus diesem Grund ist dies vor allem in den Umgebungen etablierter Cloud-Anbieter zu beobachten. Nur diese verfügen über die erforderliche zugrunde liegende Infrastruktur, Automatisierung und Orchestrierung, um ein derart weitgehend automatisiertes Betriebsmodell zu unterstützen.

Daher konzentriert sich die meiste Aufmerksamkeit im Bereich Serverless derzeit darauf, die Technologie auszuloten und herauszufinden, wie man mit den aktuellen, in der Cloud verfügbaren Varianten arbeiten kann: Amazon Lambda , Google Cloud Functions , Microsoft Azure Functions und IBM OpenWhisk . Nicht, dass es keine Angebote zur Unterstützung von On-Premise-Implementierungen wie Serverless und Iron.io gäbe. Aber im Moment ist es noch früh (früh) für Serverless.

Dennoch werden Sie wahrscheinlich bald Gerüchte über Serverless hören. Im Moment sind es im Wesentlichen nur die Motoren einer neuen Architektur, die anlaufen. Es ist unwahrscheinlich, dass es die meisten Organisationen kurzfristig (in den nächsten 12–15 Monaten) betreffen wird, aber es ist gut, zu verstehen, worum es geht, bevor es vor Ort zu einem Boxenstopp kommt. 

Wenn Sie mehr über Serverless und aktuelle Vorteile und Herausforderungen erfahren möchten, bietet NewStack eine hervorragende Übersicht .