Serverlos: Was ist das und warum ist es anders?

Was ist Serverless Computing?

Sie haben vielleicht den ganzen jüngsten Hype um Serverless in der Entwickler-Community gesehen. Was genau ist es also? Ich meine, der Code muss noch irgendwo richtig laufen, also wie ist es eigentlich serverlos?

Das bedeutet lediglich, dass das Entwickler- und Betriebsteam die eigentlichen Server nicht beaufsichtigen, verwalten oder sich auch nur um sie kümmern müssen. Das mag nach Cloud Computing sehr ähnlich klingen, aber es gibt ein paar wesentliche Unterschiede. Und diese Unterschiede liegen hauptsächlich darin, was Sie im Vergleich zu anderen Modellen nicht wissen.

Betriebssystem unbekannt!?!?

Eine der einfachen Möglichkeiten, Serverless von einer Form ausgefallener Cloud-Orchestrierung wie Kubernetes zu unterscheiden, besteht darin, dass niemand in Ihrem Unternehmen weiß, welches Betriebssystem der Server verwendet, auf dem Ihr Code ausgeführt wird. Sie glauben vielleicht, dass es Windows ist, weil Sie .Net-Code ausführen, oder dass es auf Linux läuft, weil es Ruby ist, aber am Ende sind Sie sich nicht sicher, und es hat keine Auswirkungen auf Ihre Entwicklung.

Sie sind in der Lage, Code mit einer Sprache zu schreiben, die vom Serverless-Anbieter unterstützt wird, und solange Sie sich innerhalb der Grenzen der von ihnen bereitgestellten Box bewegen, sind Sie in Ordnung, ohne zu wissen, welches Betriebssystem, welche Versionen usw. das unterstützen.

Tatsächlich besteht eine der Stärken von Serverless darin, dass Ihre Anwendung jederzeit auf mehreren verschiedenen Betriebssystemen ausgeführt werden kann. All dies wird von Ihrem Anbieter für Sie verwaltet und betrieben.

Wie viele Server benötigen Sie, um Ihren Datenverkehr zu bewältigen?

Wenn Sie diese Frage mit einer Vermutung über etwa X-Server beantworten können oder wir Y-CPUs benötigen, dann betreiben Sie keine serverlose Entwicklung.

Der serverlose Vertrag impliziert, dass die Anzahl und Stärke der Rechenleistung, die für den Betrieb Ihrer Anwendung erforderlich ist, für den Entwickler keine Rolle spielt. Das bedeutet nicht, dass Ihnen nichts dafür in Rechnung gestellt wird, sondern dass es nichts ist, was Sie oder Ihr Team verwalten oder sich darum kümmern werden. Gute Anbieter kümmern sich automatisch um die Verwaltung Ihres Dienstes, sodass eine hohe Verfügbarkeit und Reaktionsfähigkeit gewährleistet sind.

Abrechnungsmodell basierend auf Rechenleistung, Speicher und Netzwerk. Nicht Server, CPUs und Festplatten

Da Sie nicht wissen, welche tatsächliche Hardware unter Ihrer Anwendung läuft, kommt eine neue Art der Abrechnung hinzu. Anbieter von serverlosen Cloud-Plattformen berechnen die gemessene Nutzung von Berechnung, Speicherung und Netzwerkübertragung. Dies ersetzt andere Abrechnungsmodelle, die nach CPU, Laufwerken und Netzwerkverbindungen abrechnen. In einer serverlosen Welt haben sie die Kontrolle über dieses Teil und Ihnen wird nur die genaue Nutzung für Ihre App in Rechnung gestellt.

Dies rückt das Rechnen viel näher an das Modell der Elektrizität. Ihr Energieversorger stellt Ihnen die KWH in Rechnung, die der gemessene Stromverbrauch ist. Die Energie selbst wird durch Kohle, Atomkraft, Gas oder was auch immer erzeugt. Die Abrechnung erfolgt jedoch unabhängig von der Quelle gleich.

Leerlauf auf Null

Die andere große Änderung bei Serverless besteht darin, dass Ihre App automatisch auf null skaliert wird, wenn sie nicht verwendet wird. Da Sie nicht nach CPU, sondern nach Berechnung abgerechnet werden, ist Ihre Rechnung null, wenn Sie sie nicht verwenden.

Der Anbieter ist immer bereit, die Berechnung nach Bedarf zu dosieren, aber Sie müssen nicht dafür bezahlen, dass ein Server bereit ist, wenn er verwendet wird. Es ist einfach eine Berechnung, bei der für die Sekunde der tatsächlich verbrauchten Berechnung bezahlt wird, wenn Ihre App ausgeführt wird.

Man kann es sich ein bisschen wie einen Lebensmittelladen vorstellen. Ihre Aufgabe ist es, den Laden mit Milch aufgefüllt zu halten, damit Sie als Kunde, wenn Sie durstig sind, vorbeikommen, die Milch zum Trinken kaufen und dann gehen können. Sie zahlen nicht im Voraus, wenn Sie die Milch benötigen, und Sie zahlen nicht, wenn sie Milch haben, die schlecht wird, weil niemand sie gekauft hat. Das ist alles, was der Lebensmittelladen tun muss, um sicherzustellen, dass er verfügbare Bestände hat, während er darauf achtet, dass er nicht zu viele Vorräte hat und verdorbene Milch verschwendet. Alles, was Sie wissen, ist, dass sie haben, was Sie wollen, wenn Sie es wollen, und der Rest wird von Ihrer Sorge vereinfacht.

Kompromisse für Serverless

All diese Vereinfachungen klingen also ziemlich nett. Warum sollte man all diese Dinge nicht wollen: einfachere Abrechnung, weniger Betriebsverantwortung, einfache Skalierung. Nun, wie bei allen Dingen, bringt dies einige Kompromisse mit sich. Reden wir also über sie.

Ersetzen Sie den Lock-in des Betriebssystems durch den Lock-in des Cloud-Anbieters

Bei anderen Modellen gab es verschiedene Kompromisse und Einschränkungen aufgrund der Betriebssysteme oder Server, auf denen Ihr Code ausgeführt wurde. Jetzt, da serverlose Frameworks diese Verantwortung an den Anbieter abgeben, gibt es neue Einschränkungen, mit denen Sie leben müssen.

Bis jetzt gibt es keinen vereinbarten Satz von Standards, die Beschränkungen und Garantien zwischen Dienstanbietern definieren. Das bedeutet, dass es in der Vergangenheit ähnlich schwierig war, Anwendungen beispielsweise von Windows auf Linux zu verschieben. Damit werden Sie jetzt konfrontiert, wenn Sie versuchen, Ihre serverlosen Apps von der Google-Cloud in die von Amazon zu verschieben.

Diese Unternehmen bieten noch kein gemeinsames Framework, das es Kunden ermöglicht, serverlose Workloads einfach zwischen ihnen zu verschieben. Und ehrlich gesagt ist es nicht in ihrem besten Interesse, dies im Moment zu tun, da sie es vorziehen, Sie so weit wie möglich an ihre Angebote zu binden. Sie müssen sich also sehr bewusst sein, dass frühe serverlose Angebote viele proprietäre Knackpunkte haben, die es Ihnen erschweren, sie zu verlassen.

Weniger Transparenz bei Leistung und Kosten

Die Tools zum Eintauchen in die Leistung von Code sind für frühere Programmiermodelle sehr gut etabliert. Dinge wie das Herausfinden, wie viel CPU oder RAM ein bestimmtes Programm verwendet, sind alltäglich.

Beim serverlosen Modell ändern sich die Optimierungen dahingehend, wie viel Berechnung, Netzwerk und API-Aufrufe Ihr Code verwendet. Um fair zu sein, diese beziehen sich auf die CPU und den Arbeitsspeicher der Vergangenheit. Aber wenn sie noch weiter abstrahiert werden, werden diese Werkzeuge daran gehindert, so nützlich zu sein.

Ich bin fest davon überzeugt, dass neue Open-Source-Tools zum Debuggen und zur Leistungsoptimierung erscheinen werden, um diesen Markt zu bedienen. Sie erfordern jedoch ein besseres Verständnis dafür, wie die serverlose Architektur von den Anbietern implementiert wird. Dies könnte bedeuten, dass die Cloud-Anbieter die einzigen sind, die in der Lage sind, einen ausreichend tiefen Einblick zu geben, um diese Tools effektiv zu machen. Und es ist nicht in ihrem Interesse, Ihnen zu helfen, weniger Ressourcen zu verbrauchen, da sie diese Ressourcen in Rechnung stellen, unabhängig davon, ob Sie sie effizient genutzt haben oder nicht.

Anwendungen mit langer Laufzeit sind nicht der Sweet Spot

Um die gesamte Flexibilität zu erhalten, die Serverless bietet, beschränkt es den Anwendungsentwickler im Allgemeinen auf zeitbasierte Einschränkungen für diese Funktionen als Service. Dies bedeutet, dass es optimiert wird, damit Ihr Code auf eine Webanfrage antworten kann, in der er maximal 1 Minute Zeit hat, um zu antworten.

Diese festgelegten Zeitmaxima helfen dem Anbieter dabei, die Serverless-Versprechen an Sie erfüllen zu können. Sie erwarten, in der Lage zu sein, Workloads nach Bedarf zwischen tatsächlichen physischen CPUs und Standorten zu verschieben, um Entwicklungsteams einen Service bereitzustellen, der automatisch skaliert und nach Geräteausfällen heilt. Lang andauernde Workloads brechen diese Annahme. Tatsächlich wird dies normalerweise als eine der Anforderungen ihres Angebots aufgeführt. Dabei muss der Code innerhalb von X abgeschlossen oder beendet werden.

Für Dinge wie Webanfragen oder APIs für mobile Anwendungen sind diese Einschränkungen keine große Sache. Aber für andere Anwendungsfälle wie das Kodieren von Videos, den Betrieb von Echtzeit-Gameservern oder Videokonferenzlösungen sind diese Einschränkungen nicht praktikabel. In vielen Fällen können Sie diese Grenzen umgehen, indem Sie die serverlosen Ressourcen kreativ nutzen, aber Sie begnügen sich normalerweise mit einer Lösung, die Sie mehr kostet und viel langsamer arbeitet. Die Cloud-Anbieter unterstützen Sie gerne dabei, denn mehr Nutzung kostet sie mehr Geld. Stellen Sie also sicher, dass Sie Serverless für Webanwendungen und Systeme verwenden, wo es am besten passt.