Serverless bedeutet nicht, dass es physisch keine Server gibt. Es ist kein „Killer“ für Container und kein vorübergehender Trend. Es ist ein neuer Ansatz zur Entwicklung von Cloud-Systemen. In diesem Artikel werden wir die Architektur von Serverless-Anwendungen behandeln, die Rolle des Serverless-Dienstanbieters und Open-Source-Projekte beleuchten. Am Ende sprechen wir über die Anwendungsmöglichkeit von Serverless.
Ich möchte den Serverteil der Anwendung schreiben (zum Beispiel eines Onlineshops). Das kann ein Chat sein, ein Dienst zur Veröffentlichung von Inhalten oder ein Lastverteiler. In jedem Fall wird es einige Kopfschmerzen geben: Ich muss die Infrastruktur vorbereiten, die Abhängigkeiten der Anwendung definieren und über das Betriebssystem des Hosts nachdenken. Anschließend muss ich kleine Komponenten aktualisieren, die die Funktionalität des restlichen Monolithen nicht beeinträchtigen. Und wir sollten das Skalieren unter Last nicht vergessen.
Was, wenn wir flüchtige Container verwenden, in denen die erforderlichen Abhängigkeiten bereits vorinstalliert sind, und die Container zudem voneinander und vom Host-Betriebssystem isoliert sind? Den Monolith zerlegen wir in Mikrodienste, die unabhängig voneinander aktualisiert und skaliert werden können. Indem ich den Code in einen solchen Container lege, kann ich ihn auf jeder Infrastruktur ausführen. Das klingt schon besser.
Was ist, wenn ich keine Container konfigurieren möchte? Wenn ich nicht über das Skalieren der Anwendung nachdenken möchte? Wenn ich nicht für die Leerlaufzeit der gestarteten Container bezahlen möchte, wenn die Last auf den Dienst minimal ist? Ich möchte Code schreiben. Mich auf die Geschäftslogik konzentrieren und Produkte mit Lichtgeschwindigkeit auf den Markt bringen.
Diese Gedanken führten mich zu serverlosen Berechnungen. Serverless bedeutet in diesem Fall nicht das physische Fehlen von Servern, sondern das Fehlen von Kopfschmerzen bei der Verwaltung der Infrastruktur.
Die Idee ist, dass die Logik der Anwendung in unabhängige Funktionen aufgeteilt wird. Diese haben eine ereignisgesteuerte Struktur. Jede Funktion erfüllt eine „Mikroaufgabe“. Alles, was vom Entwickler gefordert wird, ist, die Funktionen in der von dem Cloud-Anbieter bereitgestellten Konsole hochzuladen und sie mit den Ereignisquellen zu verknüpfen. Der Code wird auf Anfrage in einem automatisch vorbereiteten Container ausgeführt, und ich zahle nur für die Ausführungszeit.
Lass uns anschauen, wie der Entwicklungsprozess für die Anwendung jetzt aussehen wird.
Aus Sicht des Entwicklers
Früher haben wir über eine Anwendung für den Online-Shop gesprochen. In einem traditionellen Ansatz wird die Hauptlogik des Systems von einer monolithischen Anwendung ausgeführt. Und der Server mit der Anwendung läuft ständig, auch wenn keine Last vorhanden ist.
Um zu serverless zu wechseln, zerlegen wir die Anwendung in Mikrotasks. Für jede von ihnen schreiben wir eine eigene Funktion. Die Funktionen sind unabhängig voneinander und speichern keine Zustandsinformationen (stateless). Sie können sogar in verschiedenen Sprachen geschrieben werden. Wenn eine von ihnen „ausfällt“, wird die gesamte Anwendung nicht gestoppt. Die Architektur der Anwendung sieht dann so aus:
Die Aufteilung in Funktionen im Serverless ähnelt der Arbeit mit Mikrodiensten. Doch ein Mikrodienst kann mehrere Aufgaben erfüllen, während eine Funktion idealerweise nur eine Aufgabe erfüllen sollte. Stellen wir uns vor, es gibt die Aufgabe, Statistiken zu sammeln und auf Anfrage des Benutzers auszugeben. Im mikrodienstlichen Ansatz erledigt ein Dienst diese Aufgabe über zwei Eingabepunkte: einen für das Schreiben und einen für das Lesen. In der serverlosen Architektur sind dies zwei separate Funktionen, die nicht miteinander verbunden sind. Der Entwickler spart Rechenressourcen, wenn beispielsweise die Statistik häufiger aktualisiert wird, als sie abgerufen wird.
Serverless-Funktionen müssen innerhalb eines kurzen Zeitrahmens (timeout), der vom Dienstanbieter festgelegt wird, ausgeführt werden. Zum Beispiel beträgt der Timeout für AWS 15 Minuten. Das bedeutet, dass langlebige Funktionen (long-lived) an diese Anforderungen angepasst werden müssen – so unterscheidet sich Serverless von anderen heute beliebten Technologien (Containern und Platform as a Service).
Jeder Funktion weisen wir ein Ereignis zu. Ein Ereignis ist ein Auslöser für eine Aktion:
Ereignis
Die Aktion, die die Funktion ausführt
Ein Bild des Produkts wurde im Speicher hochgeladen
Bild komprimieren und in das Verzeichnis hochladen
Die Adresse des physischen Geschäfts wurde in der Datenbank aktualisiert
Neuen Standort in Karten laden
Der Kunde bezahlt das Produkt
Zahlungsverarbeitung starten
Ereignisse können HTTP-Anfragen, Streaming-Daten, Warteschlangen für Nachrichten usw. sein. Die Quellen der Ereignisse sind Änderungen oder das Auftreten von Daten. Darüber hinaus können Funktionen auch nach einem Timer gestartet werden.
Die Architektur wurde erarbeitet und die Anwendung ist fast serverlos geworden. Jetzt gehen wir zum Dienstanbieter über.
Vom Anbieter aus
Normalerweise bieten Cloud-Dienstanbieter serverless Computing an. Sie werden unterschiedlich benannt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Wir werden den Dienst über die Konsole oder das persönliche Konto des Anbieters nutzen. Den Funktionscode können wir auf eine der folgenden Arten hochladen:
- den Code in eingebetteten Editoren über die Webkonsole schreiben,
- ein Archiv mit dem Code hochladen,
- oder mit öffentlichen oder privaten Git-Repositories arbeiten.
Hier konfigurieren wir auch die Ereignisse, die die Funktion aufrufen. Bei verschiedenen Anbietern können die Ereignissets unterschiedlich sein.
Der Anbieter hat auf seiner Infrastruktur ein System für Function as a Service (FaaS) aufgebaut und automatisiert:
- Der Funktionscode gelangt in ein Speicher auf der Seite des Anbieters.
- Wenn ein Ereignis auftritt, werden automatisch Container mit der vorbereiteten Umgebung auf dem Server bereitgestellt. Jeder Instanz der Funktion steht ein eigener isolierter Container zur Verfügung.
- Aus dem Speicher wird die Funktion in den Container gesendet, berechnet und gibt das Ergebnis zurück.
- Die Anzahl der parallelen Ereignisse wächst – die Anzahl der Container wächst. Das System skaliert automatisch. Wenn keine Nutzer auf die Funktion zugreifen, bleibt sie inaktiv.
- Der Anbieter legt die Leerlaufzeit der Container fest – wenn innerhalb dieser Zeit keine Funktionen im Container erscheinen, wird er zerstört.
Auf diese Weise erhalten wir Serverless „out of the box“. Wir zahlen für den Dienst nach dem Modell pay-as-you-go und nur für die Funktionen, die genutzt werden, und nur für die Zeit, in der sie genutzt wurden.
Um Entwicklern den Dienst vorzustellen, bieten die Anbieter bis zu 12 Monate kostenlose Testphase an, schränken jedoch die gesamte Rechenzeit, die Anfragen pro Monat, die finanziellen Mittel oder die verbrauchten Ressourcen ein.
Der größte Vorteil der Zusammenarbeit mit einem Anbieter ist die Möglichkeit, sich keine Gedanken über die Infrastruktur (Server, virtuelle Maschinen, Container) machen zu müssen. Der Anbieter kann FaaS sowohl mit eigenen Entwicklungen als auch mit Open-Source-Tools umsetzen. Darüber werden wir gleich sprechen.
Auf der Seite von Open Source
Hat die Open-Source-Community in den letzten paar Jahren aktiv an Serverless-Tools gearbeitet. Unter anderem haben die größten Akteure des Marktes zur Entwicklung von serverlosen Plattformen beigetragen:
- Google bietet den Entwicklern sein Open-Source-Tool an – . An seiner Entwicklung waren IBM, RedHat, Pivotal und SAP beteiligt;
- IBM arbeitete an der Serverless-Plattform , die dann ein Projekt der Apache Foundation wurde;
- von Microsoft hat teilweise den Code der Plattform .
Entwicklungen erfolgen auch im Bereich der Serverless-Frameworks. und die innerhalb von zuvor vorbereiteten Kubernetes-Clustern bereitgestellt werden, funktioniert sowohl mit Kubernetes als auch mit Docker Swarm. Das Framework agiert als eine Art Controller – auf Anfrage bereitet es innerhalb des Clusters eine Laufzeitumgebung vor und startet dann die Funktion.
Frameworks bieten Spielraum für die Konfiguration des Tools nach eigenen Bedürfnissen. So kann im Kubeless der Entwickler das Timeout für die Ausführung der Funktion einstellen (Standardwert: 180 Sekunden). Fission versucht, das Problem des Cold Starts zu lösen, indem es einige Container ständig laufen lässt (obwohl dies Kosten für ungenutzte Ressourcen verursacht). OpenFaaS bietet eine Vielzahl von Triggern für jeden Geschmack: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs und weitere.
Anleitungen zum Einstieg sind in der offiziellen Dokumentation der Frameworks zu finden. Die Arbeit mit ihnen erfordert etwas mehr Fähigkeiten als die Arbeit mit einem Anbieter – das mindestens beinhaltet, einen Kubernetes-Cluster über die CLI zu starten. Im besten Fall werden andere Open-Source-Tools (zum Beispiel einen Kafka-Queue-Manager) integriert.
Unabhängig davon, ob wir mit Serverless über einen Anbieter oder mithilfe von Open-Source arbeiten, erhalten wir eine Reihe von Vor- und Nachteilen des Serverless-Ansatzes.
Aus der Perspektive von Vor- und Nachteilen
entwickelt Serverless die Ideen der Container-Infrastruktur und des Mikroservice-Ansatzes weiter, bei denen Teams in einem mehrsprachigen Modus arbeiten können, ohne an eine Plattform gebunden zu sein. Der Aufbau des Systems wird vereinfacht, und das Beheben von Fehlern wird leichter. Die mikroservicebasierte Architektur ermöglicht das Hinzufügen neuer Funktionalitäten zum System wesentlich schneller als bei einer monolithischen Anwendung.
Serverless verkürzt die Entwicklungszeit noch weiter, indem es dem Entwickler ermöglicht, sich ausschließlich auf die Geschäftslogik der Anwendung und das Schreiben von Code zu konzentrieren. Als Folge davon verkürzt sich die Time-to-Market der Entwicklungen.
Als Bonus erhalten wir automatisches Scaling unter Last, und zahlen nur für die genutzten Ressourcen und nur in der Zeit, in der sie genutzt werden.
Wie jede Technologie hat auch Serverless Nachteile.
Ein solcher Nachteil kann die Zeit des kalten Starts sein (im Durchschnitt bis zu 1 Sekunde für Sprachen wie JavaScript, Python, Go, Java, Ruby).
Einerseits hängt die tatsächliche Zeit des Kaltstarts von vielen Variablen ab: der Programmiersprache, in der die Funktion geschrieben ist, der Anzahl der Bibliotheken, dem Codeumfang und der Kommunikation mit zusätzlichen Ressourcen (wie Datenbanken oder Authentifizierungsservern). Da der Entwickler diese Variablen steuern kann, kann er die Startzeit verkürzen. Andererseits kann der Entwickler jedoch nicht die Zeit steuern, die zum Start des Containers benötigt wird – hier hängt alles vom Anbieter ab.
Ein Kaltstart kann zu einem Warmstart werden, wenn die Funktion den zuvor von einem Event betriebenen Container wiederverwendet. Diese Situation tritt in drei Fällen auf:
- wenn die Kunden den Service häufig nutzen und die Anzahl der Funktionsaufrufe steigt;
- wenn der Anbieter, die Plattform oder das Framework es erlauben, dass Teile der Container ständig laufen;
- wenn der Entwickler Funktionen nach einem Timer (zum Beispiel alle 3 Minuten) startet.
Für viele Anwendungen ist ein Kaltstart kein Problem. Hier kommt es auf die Art und die Aufgaben des Dienstes an. Eine Startverzögerung von einer Sekunde ist nicht immer kritisch für eine biznesanwendung, kann jedoch für medizinische Dienste entscheidend sein. Wahrscheinlich wäre in diesem Fall der serverlose Ansatz nicht mehr geeignet.
Ein weiterer Nachteil von Serverless ist die kurze Lebensdauer der Funktion (Timeout, innerhalb dessen die Funktion ausgeführt werden muss).
Wenn man jedoch mit langanhaltenden Aufgaben arbeiten muss, kann eine hybride Architektur verwendet werden – eine Kombination aus Serverless und einer anderen Technologie.
Nicht alle Systeme können nach dem Serverless-Modell betrieben werden.
Einige Anwendungen werden weiterhin Daten und Zustände während der Ausführung speichern. Manche Architekturen bleiben monolithisch, während einige Funktionen langanhaltend sein werden. Doch (wie einst Cloud-Technologien und später Container) ist Serverless eine Technologie mit einer großen Zukunft.
In diesem Zusammenhang möchte ich sanft über die Anwendung des Serverless-Ansatzes überleiten.
Aus der Anwendungsperspektive
Im Jahr 2018 wuchs der Anteil der Nutzung von Serverless . Zu den Unternehmen, die die Technologie bereits in ihre Dienste integriert haben, gehören Marktgiganten wie Twitter, PayPal, Netflix, T-Mobile und Coca-Cola. Dabei muss man verstehen, dass Serverless kein Allheilmittel ist, sondern ein Werkzeug zur Lösung bestimmter Aufgaben:
- Die Stillstandszeiten der Ressourcen zu reduzieren. Es ist nicht notwendig, die virtuelle Maschine für Dienste, die selten genutzt werden, ständig am Laufen zu halten.
- Daten "in Echtzeit" verarbeiten. Bilder komprimieren, Hintergründe ausschneiden, Video-Codierungen ändern, mit IoT-Sensoren arbeiten, mathematische Operationen ausführen.
- "Verknüpfen" Sie andere Dienste miteinander. Git-Repository mit internen Programmen, Chatbot in Slack mit Jira und Kalender.
- Lastverteilung vornehmen. Hier bleiben wir detaillierter.
Angenommen, es gibt einen Dienst, der von 50 Personen genutzt wird. Dafür gibt es eine virtuelle Maschine mit schwacher Hardware. Gelegentlich steigt die Last auf den Dienst um ein Vielfaches. Dann kann die schwache Hardware nicht mithalten.
Man kann einen Lastverteiler in das System einfügen, der die Last beispielsweise auf drei virtuelle Maschinen verteilt. In dieser Phase können wir die Last nicht genau vorhersagen, daher halten wir einige Ressourcen "auf Vorrat" in Betrieb und zahlen zu viel für Leerlauf.
In dieser Situation können wir das System über einen hybriden Ansatz optimieren: Hinter dem Lastverteiler lassen wir eine virtuelle Maschine laufen und setzen einen Link zu einem Serverless Endpoint mit Funktionen. Wenn die Last den Schwellenwert überschreitet, startet der Lastverteiler Instanzen von Funktionen, die einen Teil der Anfrageverarbeitung übernehmen.
Auf diese Weise kann Serverless dort eingesetzt werden, wo man nicht allzu häufig, aber intensiv eine große Anzahl von Anfragen verarbeiten muss. In diesem Fall ist es günstiger, mehrere Funktionen für 15 Minuten zu starten, anstatt ständig eine virtuelle Maschine oder einen Server am Laufen zu halten.
Trotz aller Vorteile von serverlosen Berechnungen sollte vor der Implementierung zunächst die Logik der Anwendung bewertet werden, um zu verstehen, welche Aufgaben Serverless in diesem speziellen Fall lösen kann.
Serverless und Selectel
Bei Selectel haben wir bereits über unser Bedienfeld. Jetzt bauen wir unsere eigene FaaS-Plattform. Wir möchten, dass Entwickler ihre Aufgaben mithilfe von Serverless über eine benutzerfreundliche, flexible Schnittstelle lösen können.
Wenn Sie Ideen haben, wie eine ideale FaaS-Plattform aussehen sollte und wie Sie Serverless in Ihren Projekten nutzen möchten, teilen Sie uns Ihre Gedanken in den Kommentaren mit. Wir werden Ihre Wünsche bei der Entwicklung der Plattform berücksichtigen.
Verwendete Materialien im Artikel:
Quelle: habr.com
