{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless nach Racks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless bedeutet nicht, dass es physisch keine Server gibt. Es ist kein \u201eKiller\u201c f\u00fcr Container und kein vor\u00fcbergehender 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 \u00fcber die Anwendungsm\u00f6glichkeit von Serverless.
\n<\/a><\/noindex>
\nIch m\u00f6chte den Serverteil der Anwendung schreiben (zum Beispiel eines Onlineshops). Das kann ein Chat sein, ein Dienst zur Ver\u00f6ffentlichung von Inhalten oder ein Lastverteiler. In jedem Fall wird es einige Kopfschmerzen geben: Ich muss die Infrastruktur vorbereiten, die Abh\u00e4ngigkeiten der Anwendung definieren und \u00fcber das Betriebssystem des Hosts nachdenken. Anschlie\u00dfend muss ich kleine Komponenten aktualisieren, die die Funktionalit\u00e4t des restlichen Monolithen nicht beeintr\u00e4chtigen. Und wir sollten das Skalieren unter Last nicht vergessen.<\/p>\n

Was, wenn wir fl\u00fcchtige Container verwenden, in denen die erforderlichen Abh\u00e4ngigkeiten bereits vorinstalliert sind, und die Container zudem voneinander und vom Host-Betriebssystem isoliert sind? Den Monolith zerlegen wir in Mikrodienste, die unabh\u00e4ngig voneinander aktualisiert und skaliert werden k\u00f6nnen. Indem ich den Code in einen solchen Container lege, kann ich ihn auf jeder Infrastruktur ausf\u00fchren. Das klingt schon besser. <\/p>\n

Was ist, wenn ich keine Container konfigurieren m\u00f6chte? Wenn ich nicht \u00fcber das Skalieren der Anwendung nachdenken m\u00f6chte? Wenn ich nicht f\u00fcr die Leerlaufzeit der gestarteten Container bezahlen m\u00f6chte, wenn die Last auf den Dienst minimal ist? Ich m\u00f6chte Code schreiben. Mich auf die Gesch\u00e4ftslogik konzentrieren und Produkte mit Lichtgeschwindigkeit auf den Markt bringen. <\/p>\n

Diese Gedanken f\u00fchrten 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.<\/em><\/p>\n

Die Idee ist, dass die Logik der Anwendung in unabh\u00e4ngige Funktionen aufgeteilt wird. Diese haben eine ereignisgesteuerte Struktur. Jede Funktion erf\u00fcllt eine \u201eMikroaufgabe\u201c. 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\u00fcpfen. Der Code wird auf Anfrage in einem automatisch vorbereiteten Container ausgef\u00fchrt, und ich zahle nur f\u00fcr die Ausf\u00fchrungszeit. <\/p>\n

Lass uns anschauen, wie der Entwicklungsprozess f\u00fcr die Anwendung jetzt aussehen wird.<\/p>\n

Aus Sicht des Entwicklers<\/h2>\n

\nFr\u00fcher haben wir \u00fcber eine Anwendung f\u00fcr den Online-Shop gesprochen. In einem traditionellen Ansatz wird die Hauptlogik des Systems von einer monolithischen Anwendung ausgef\u00fchrt. Und der Server mit der Anwendung l\u00e4uft st\u00e4ndig, auch wenn keine Last vorhanden ist.<\/p>\n

Um zu serverless zu wechseln, zerlegen wir die Anwendung in Mikrotasks.<\/strong> F\u00fcr jede von ihnen schreiben wir eine eigene Funktion. Die Funktionen sind unabh\u00e4ngig voneinander und speichern keine Zustandsinformationen (stateless). Sie k\u00f6nnen sogar in verschiedenen Sprachen geschrieben werden. Wenn eine von ihnen \u201eausf\u00e4llt\u201c, wird die gesamte Anwendung nicht gestoppt. Die Architektur der Anwendung sieht dann so aus:<\/p>\n

\"Serverless
\nDie Aufteilung in Funktionen im Serverless \u00e4hnelt der Arbeit mit Mikrodiensten. Doch ein Mikrodienst kann mehrere Aufgaben erf\u00fcllen, w\u00e4hrend eine Funktion idealerweise nur eine Aufgabe erf\u00fcllen 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 \u00fcber zwei Eingabepunkte: einen f\u00fcr das Schreiben und einen f\u00fcr 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\u00e4ufiger aktualisiert wird, als sie abgerufen wird. <\/p>\n

Serverless-Funktionen m\u00fcssen innerhalb eines kurzen Zeitrahmens (timeout), der vom Dienstanbieter festgelegt wird, ausgef\u00fchrt werden. Zum Beispiel betr\u00e4gt der Timeout f\u00fcr AWS 15 Minuten. Das bedeutet, dass langlebige Funktionen (long-lived) an diese Anforderungen angepasst werden m\u00fcssen \u2013 so unterscheidet sich Serverless von anderen heute beliebten Technologien (Containern und Platform as a Service).<\/p>\n

Jeder Funktion weisen wir ein Ereignis zu.<\/strong> Ein Ereignis ist ein Ausl\u00f6ser f\u00fcr eine Aktion:<\/p>\n

Ereignis<\/strong>
\nDie Aktion, die die Funktion ausf\u00fchrt<\/strong><\/p>\n

Ein Bild des Produkts wurde im Speicher hochgeladen
\nBild komprimieren und in das Verzeichnis hochladen<\/p>\n

Die Adresse des physischen Gesch\u00e4fts wurde in der Datenbank aktualisiert
\nNeuen Standort in Karten laden<\/p>\n

Der Kunde bezahlt das Produkt
\nZahlungsverarbeitung starten<\/p>\n

Ereignisse k\u00f6nnen HTTP-Anfragen, Streaming-Daten, Warteschlangen f\u00fcr Nachrichten usw. sein. Die Quellen der Ereignisse sind \u00c4nderungen oder das Auftreten von Daten. Dar\u00fcber hinaus k\u00f6nnen Funktionen auch nach einem Timer gestartet werden.<\/p>\n

Die Architektur wurde erarbeitet und die Anwendung ist fast serverlos geworden. Jetzt gehen wir zum Dienstanbieter \u00fcber.<\/p>\n

Vom Anbieter aus<\/h2>\n

\nNormalerweise bieten Cloud-Dienstanbieter serverless Computing an. Sie werden unterschiedlich benannt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Wir werden den Dienst \u00fcber die Konsole oder das pers\u00f6nliche Konto des Anbieters nutzen. Den Funktionscode k\u00f6nnen wir auf eine der folgenden Arten hochladen:<\/p>\n