Verstehen der serverlosen Cloud und klare

Serverless gilt als der Nachfolger von Containern. Doch obwohl es stark beworben wird, ist es noch immer nicht für jeden Anwendungsfall optimal geeignet. Wenn Sie die Fallstricke und Nachteile kennen, können Sie ganz einfach die Anwendungsfälle finden, die in dieses Muster passen. In diesem Beitrag finden Sie einige technologische Perspektiven zum heutigen Reifegrad von Serverless.

Beachten Sie zunächst, wie wir das Wort serverlos hier verwenden. Serverless ist eine Kombination aus 'Function as a Service' (FaaS) und bestimmten 'Platform as a Services' (PaaS). Nämlich solche, bei denen Sie nicht wissen, wie die Server aussehen. Zum Beispiel: RDS oder Beanstalk sind "von AWS verwaltete Server", bei denen Sie immer noch den Kontext des Servers/der Server sehen. DynamoDB und S3 sind lediglich eine Art von NoSQL- und Speicherlösung mit einer API, bei der Sie die Server nicht sehen können. Wenn Sie die Server nicht sehen, bedeutet dies, dass sie nicht bereitgestellt, gehärtet oder gewartet werden. Das bedeutet buchstäblich "weniger" Server. Eine serverlose Plattform arbeitet mit "Ereignissen". Beispiele für Ereignisse sind: die Aktion hinter einer Schaltfläche auf einer Website, die Backend-Verarbeitung einer mobilen App oder der Moment, in dem ein Bild in die Cloud hochgeladen wird und der Speicherdienst die Funktion auslöst.

Leistung

Alle an einer serverlosen Architektur beteiligten Dienste können praktisch unbegrenzt skaliert werden. Das bedeutet, wenn eine Funktion, sagen wir, 1000 Mal in einer Sekunde ausgelöst wird, ist garantiert, dass alle Ausführungen eine Sekunde später abgeschlossen sind. In der alten Container-Welt müssen Sie genügend Container-Anwendungen bereitstellen und abstimmen, um diese Menge an sofortigen Anfragen zu bewältigen. Klingt so, als würde Serverless bei dieser Performance-Herausforderung gewinnen, oder? Manchmal läuft der Serverless-Container mit Ihrer Funktion jedoch noch nicht und muss erst gestartet werden. Dies führt zu einem leichten Overhead bei der Gesamtausführung der 'kalten' Funktionen. Das fühlt sich nicht gut an, wenn Sie sicherstellen möchten, dass Ihre Benutzer (oder "Dinge") 100 % schnelle Antworten erhalten. Das bedeutet, dass Sie, wenn Sie wirklich eine vorhersehbare Reaktion wünschen, eine Container-Plattform bereitstellen und sich immer wieder fragen müssen: Ist der Overhead die Kosten wert? Nicht nur für den Betrieb der Container, sondern auch, ob es die damit verbundenen Investitionen in Zeit, Komplexität und Risiken wert ist.

Vorhersehbare Kosten

Bei Serverless zahlen Sie für jede Ausführung in Blöcken von 100 Millisekunden. Das bedeutet "100% Auslastung". Bei Container-Plattformen oder Servern zahlen Sie pro laufende Stunde. In Ausnahmefällen auch pro Minute oder Sekunde. Bei einer sehr vorhersehbaren und gleichmäßigen Arbeitslast könnten Sie eine Auslastung von etwa 70% erreichen. Das ist immer noch eine Menge Verschwendung. Bei plötzlichen Auslastungsspitzen müssen Sie immer eine Überversorgung vornehmen. Eine höhere Auslastung bedeutet weniger Kosten, aber höhere Risiken. Wenn der Datenverkehr unvorhersehbar und sehr sprunghaft ist, sollten Sie wirklich Serverless in Betracht ziehen.

Sicher

Sie würden erwarten, dass Cloud-Dienste vollkommen sicher sind. Leider ist das bei den Funktionen nicht der Fall. Bei den meisten Cloud-Diensten ist die "Angriffsfläche" begrenzt und kann daher vollständig geschützt werden. Bei serverlosen Diensten ist diese Oberfläche sehr dünn und breit und wird auf gemeinsam genutzten Servern ausgeführt, die weniger geschützt sind als z.B. EC2 oder DynamoDB. Aus diesem Grund sind Informationen wie Kreditkartendaten in Funktionen nicht zulässig. Das bedeutet nicht, dass es unsicher ist, aber es kann einer strengen und erforderlichen Prüfung noch nicht standhalten. Irgendwann wird das der Fall sein. Daher ist es gut, wenn Sie jetzt, wo bekannt ist, dass die serverlose Technologie das nächste große Ding ist, schon etwas Erfahrung mit ihr haben. Beginnen Sie mit Backend-Systemen mit weniger sensiblen Daten, wie Spielfortschritt, Einkaufslisten, Analysen usw. Oder verarbeiten Sie zum Beispiel Lebensmittelbestellungen, lagern aber die Bezahlung an einen Anbieter aus. Neben Kreditkartennummern sind dies für sich genommen sensible Daten, während die meisten von Funktionen verarbeiteten Daten nur dann sensibel sind, wenn sie in großen Mengen durchsickern. Was zum Beispiel passieren könnte: Daten im Speicher werden an andere Benutzer desselben zugrunde liegenden Servers weitergegeben. In diesem Fall kann die Preisgabe einer Kreditkartennummer ausgenutzt werden, aber das Wissen, dass jemand mit der ID: 3h7L8r Tomaten gekauft hat, nicht.

Zuverlässig

Ein weiterer Aspekt der Sicherheit ist die Verfügbarkeit von Diensten. Ein relativ "langsamer" Dienst, der nicht ausfallen kann, ist in der Regel besser als ein Dienst, der zwar schnell, aber nicht verfügbar ist. Oft werden bei einer Disaster Recovery-Einrichtung alle vor Ort befindlichen Server in die Cloud repliziert, was die Sache sehr komplex macht. In den meisten Fällen ist es besser, Ihre On-Premise-Server abzuschalten und ganz in die Cloud zu gehen. Wenn Sie zu diesem Schritt nicht bereit sind, kann Serverless auch als Failover-Plattform verwendet werden, um bestimmte Funktionen hochverfügbar zu halten. Natürlich nicht alle Funktionen, aber diejenigen, die geschäftskritisch sind, oder die eine vorübergehende Speicherung und Verarbeitung in einem Batch nach der Wiederherstellung erleichtern können. Das ist weniger kostspielig und sehr zuverlässig.

Wolke & Klar

Bis vor kurzem war es ziemlich schwierig, eine Live-Funktion zu starten und zu aktualisieren. Mehr und mehr Frameworks wie Serverless.com und SAM lösen die wichtigsten Probleme. In Kombination mit automatisiertem CICD ist es ein Leichtes, Ihre serverlose Plattform in einer sicheren Umgebung einzusetzen und zu testen. So stellen Sie sicher, dass die Bereitstellung in der Produktion jedes Mal erfolgreich und ohne Ausfallzeiten erfolgt. Mit Cloudformation oder Terraform "entwickeln" Sie die Cloud Native Services und konfigurieren Funktionen. Mit Programmiersprachen wie nodejs, python, java oder C# die Funktionen selbst, und Gitlab hat eine ziemlich süße und billige 'CICD as code' Lösung. Auch die Protokollierung und Überwachung ist in den letzten Monaten sehr ausgereift geworden. Der gesamte Quellcode gibt Ihnen einen 'cloud & clear' Überblick darüber, was sich unter der Haube Ihrer serverlosen Anwendung befindet. Wie sie bereitgestellt, entwickelt, bereitgestellt, getestet und überwacht wird und wie sie läuft.

Fazit

AWS begann 2014 mit der Einführung von Lambda, und obwohl dieser Beitrag hauptsächlich über AWS geschrieben wird, investieren auch Google und Microsoft stark in ihre Funktionen und ihren serverlosen Ansatz. In den letzten Monaten wurden vielversprechende Angebote und Demos von ihnen gezeigt. Die Welt ist noch nicht bereit, sich voll und ganz auf Serverless einzulassen, aber wir sehen bereits das wachsende Interesse von Entwicklern und Startups. Sie bauen sichere, zuverlässige, leistungsstarke und kosteneffiziente Lösungen und entschärfen die oben genannten Probleme auf einfache Weise. Eines Tages werden Sie aufwachen und feststellen, dass Serverless jetzt vollständig gesichert ist, eine zuverlässige Leistung bietet (vorgewärmt) und von vielen Wettbewerbern übernommen wird. Seien Sie also vorbereitet und beginnen Sie noch heute, in diese Technologie zu investieren.