Wichtige Punkte
- Seit mehreren Jahren wird uns versprochen, dass serverloses Computing (serverless) eine neue Ära ohne spezifisches Betriebssystem für die Ausführung von Anwendungen einleitet. Man sagte uns, dass diese Struktur viele Skalierungsprobleme lösen würde. In Wirklichkeit ist alles anders.
- Obwohl viele serverlose Technologie als neue Idee betrachten, lassen sich ihre Wurzeln bis ins Jahr 2006 zurückverfolgen, als Zimki PaaS und Google App Engine auftauchten — in beiden Fällen kam eine serverlose Architektur zum Einsatz.
- Es gibt vier Gründe, warum die serverlose Revolution ins Stocken geraten ist: von begrenzter Unterstützung für Programmiersprachen bis hin zu Leistungsproblemen.
- Serverless Computing ist keineswegs nutzlos. Überhaupt nicht. Allerdings sollte man es nicht als direkte Alternative zu Servern betrachten. Für bestimmte Anwendungen kann es ein nützliches Werkzeug sein.
Der Server ist tot, es lebe der Server!
So klingt der Kampfruf der Anhänger der serverlosen Revolution. Ein flüchtiger Blick in die Branchenpresse der letzten Jahre reicht aus, um zu verstehen, dass das traditionelle Servermodell tot ist und wir in ein paar Jahren alle serverlose Architekturen nutzen werden.
Jedem in der Branche bekannt ist, und wie wir auch in unserem Artikel über , ist das nicht der Fall. Trotz zahlreicher Artikel über die Vorteile der , hat sie nie stattgefunden. Tatsächlich zeigen , dass diese Revolution möglicherweise in eine Sackgasse geraten ist.
Einige der Versprechen für serverlose Modelle wurden zweifellos erfüllt, aber nicht alle. Bei weitem nicht alle.
In diesem Artikel möchte ich die Gründe für diesen Zustand untersuchen. Warum bleibt der Mangel an Flexibilität bei serverlosen Modellen ein Hindernis für deren breitere Einführung, obwohl sie sich in bestimmten, klar definierten Umständen als nützlich erweisen.
Was die Anhänger serverloser Berechnungen versprochen haben
Bevor wir uns den Herausforderungen des serverlosen Computings zuwenden, lassen Sie uns betrachten, was es bieten sollte. waren zahlreich und manchmal sehr ehrgeizig.
Für diejenigen, die mit dem Begriff nicht vertraut sind, hier eine kurze Definition. Serverloses Computing definiert eine Architektur, in der Anwendungen (oder Teile von Anwendungen) Bedarfsorientiert in Umgebungen ausgeführt werden, die in der Regel remote gehostet werden. Zudem können serverlose Systeme auch lokal gehostet werden. In den letzten Jahren war die Entwicklung robuster serverloser Systeme eine Hauptanliegen für Systemadministratoren und SaaS-Unternehmen, da diese Architektur angeblich mehrere wichtige Vorteile gegenüber dem "traditionellen" Client-Server-Modell bietet:
- Serverlose Modelle erfordern nicht, dass Benutzer eigene Betriebssysteme verwalten oder sogar Anwendungen erstellen, die mit bestimmten Betriebssystemen kompatibel sind. Stattdessen erstellen Entwickler gemeinsamen Code, laden ihn auf eine serverlose Plattform hoch und beobachten dessen Ausführung.
- Ressourcen in serverlosen Frameworks werden in der Regel nach Minuten (oder sogar Sekunden) abgerechnet. Das bedeutet, dass die Kunden nur für die Zeit bezahlen, in der sie tatsächlich Code ausführen. Das unterscheidet sich vorteilhaft von einer traditionellen Cloud-VM, bei der die Maschine die meiste Zeit im Leerlauf ist, aber trotzdem Kosten verursacht.
- Auch das Problem der Skalierbarkeit wurde gelöst. Ressourcen in serverlosen Frameworks werden dynamisch zugewiesen, sodass das System mühelos mit plötzlichen Nachfragesteigerungen umgehen kann.
Kurz gesagt, serverlose Modelle bieten flexible, kostengünstige und skalierbare Lösungen. Es ist erstaunlich, dass wir nicht schon früher auf diese Idee gekommen sind.
Ist das wirklich eine neue Idee?
Tatsächlich ist die Idee nicht neu. Das Konzept, das es Benutzern ermöglicht, nur für die Zeit zu zahlen, in der der Code tatsächlich ausgeführt wird, gibt es, seit es im Rahmen von im Jahr 2006 eingeführt wurde, und ungefähr zur gleichen Zeit bot Google App Engine eine sehr ähnliche Lösung an.
Tatsächlich ist das, was wir heute als "serverloses" Modell bezeichnen, älter als viele Technologien, die derzeit als "native Cloud" bezeichnet werden und nahezu dasselbe bieten. Wie bereits erwähnt, sind serverlose Modelle im Grunde genommen lediglich eine Fortsetzung des Geschäftsmodells von SaaS, das bereits seit mehreren Jahrzehnten existiert.
Es ist auch anzuerkennen, dass das serverlose Modell keine FaaS-Architektur ist, obwohl ein Zusammenhang zwischen beiden besteht. FaaS ist im Wesentlichen der rechenzentrische Teil der serverlosen Architektur, stellt jedoch nicht das gesamte System dar.
Warum all der Aufruhr? Nun, da die Internetdurchdringung in Entwicklungsländern weiterhin rasant zunimmt, steigt gleichzeitig die Nachfrage nach Rechenressourcen. Viele Länder mit schnell wachsenden E-Commerce-Sektoren verfügen beispielsweise einfach nicht über die nötige Infrastruktur für Anwendungen auf diesen Plattformen. Hier kommen kostenpflichtige serverlose Plattformen ins Spiel.
Herausforderungen serverloser Modelle
Das Problem ist, dass serverlose Modelle… Schwierigkeiten haben. Verstehen Sie mich nicht falsch: Ich sage nicht, dass sie an sich schlecht sind oder für einige Unternehmen unter bestimmten Umständen keinen signifikanten Wert bieten. Aber die Hauptbehauptung der «Revolution» — dass serverlose Architektur traditionelle Architekturen schnell ersetzen wird — wird niemals Realität werden.
Deshalb.
Eingeschränkte Unterstützung von Programmiersprachen
Die meisten serverlosen Plattformen erlauben nur das Ausführen von Anwendungen, die in bestimmten Sprachen geschrieben sind. Das schränkt die Flexibilität und Anpassungsfähigkeit dieser Systeme erheblich ein.
Es wird angenommen, dass serverlose Plattformen die meisten gängigen Programmiersprachen unterstützen. AWS Lambda und Azure Functions bieten zudem eine Umgebung zum Ausführen von Anwendungen und Funktionen in nicht unterstützten Sprachen, obwohl dies oft mit Performance-Kosten verbunden ist. Für die meisten Organisationen stellt dieses Einschränkung in der Regel kein großes Problem dar. Aber hier ist das Problem. Ein Vorteil model von serverlosen Modellen besteht darin, dass weniger bekannte, selten verwendete Programme kostengünstiger eingesetzt werden können, da Sie nur für die Ausführungszeit zahlen. Und weniger bekannte, selten verwendete Programme werden häufig in… weniger bekannten, selten verwendeten Programmiersprachen geschrieben.
Dies untergräbt eines der wichtigsten Vorteile des serverlosen Modells.
Vendor-Lock-in
Das zweite Problem mit serverlosen Plattformen oder zumindest ihrer aktuellen Umsetzung besteht darin, dass sie auf operativer Ebene oft nicht vergleichbar sind. Es gibt praktisch keine Standardisierung im Hinblick auf das Schreiben von Funktionen, das Deployen und das Management. Das bedeutet, dass die Migration von Funktionen von einer Plattform zur anderen äußerst zeitaufwendig ist.
Der schwierigste Teil des Übergangs zu einem serverlosen Modell sind nicht die Compute-Funktionen, die in der Regel einfach Codefragmente darstellen, sondern die Art und Weise, wie Anwendungen mit angebundenen Systemen verbunden sind, wie z.B. Objektspeichern, Identitätsmanagement und Warteschlangen. Funktionen können verschoben werden, aber der Rest der Anwendung nicht. Das steht in direkter Gegenüberstellung zu den versprochenen kostengünstigen und flexiblen Plattformen.
Einige behaupten, dass serverlose Modelle neu sind und nicht genügend Zeit war, um deren Funktionsweise zu standardisieren. Doch sie sind nicht so neu, wie ich bereits oben erwähnt habe, und viele andere Cloud-Technologien, wie Container, haben sich bereits erheblich verbessert durch die Entwicklung und weitreichende Einführung guter Standards.
Leistung
Die Rechenleistung von serverlosen Plattformen ist schwer zu messen, teilweise weil Anbieter dazu neigen, Informationen geheim zu halten. Die meisten behaupten, dass Funktionen auf remote, serverlosen Plattformen ebenso schnell laufen wie auf internen Servern, abgesehen von einigen unvermeidlichen Verzögerungsproblemen.
Einige Einzelheiten zeigen jedoch das Gegenteil. Funktionen, die zuvor nicht auf einer bestimmten Plattform ausgeführt wurden oder eine Zeit lang nicht aktiviert waren, benötigen einige Zeit zur Initialisierung. Dies könnte daran liegen, dass deren Code auf ein weniger zugängliches Speichermedium verschoben wurde, obwohl die meisten Anbieter, ähnlich wie bei Benchmarks, Ihnen nicht über die Datenverschiebung informieren werden.
Natürlich gibt es verschiedene Möglichkeiten, dies zu umgehen. Eine besteht darin, Funktionen für jede Cloud-Sprache zu optimieren, auf der Ihre serverlose Plattform läuft, was jedoch die Behauptung untergräbt, dass diese Plattformen "flexibel" sind.
Ein anderer Ansatz besteht darin, sicherzustellen, dass kritische Programme für die Leistung regelmäßig ausgeführt werden, damit sie ‚frisch‘ bleiben. Dieser zweite Ansatz steht natürlich etwas im Widerspruch zu der Behauptung, dass serverlose Plattformen wirtschaftlicher sind, da man nur für die Laufzeit seiner Programme zahlt. Cloud-Anbieter haben neue Methoden zur Reduzierung von Kaltstarts eingeführt, viele von ihnen erfordern jedoch ein „Scaling to one“, was den ursprünglichen Wert von FaaS untergräbt.
Das Problem des „Kaltstarts“ kann teilweise durch den eigenständigen Betrieb serverloser Systeme gelöst werden, ist jedoch mit eigenen Kosten verbunden und bleibt eine Nischenoption für gut ausgestattete Teams.
Sie können keine gesamten Anwendungen ausführen
Schließlich könnte der vielleicht wichtigste Grund, warum serverlose Architekturen traditionelle Modelle in naher Zukunft nicht ersetzen werden: Man kann darauf (im Allgemeinen) keine gesamten Anwendungen ausführen.
Genauer gesagt, aus Kostensicht ist es nicht sinnvoll. Ihr erfolgreiches Monolith wird wahrscheinlich nicht in eine Sammlung von vier Dutzend Funktionen verwandelt, die durch acht Gateways, vierzig Warteschlangen und ein Dutzend Datenbankinstanzen verbunden sind. Aus diesem Grund eignet sich serverless besser für neue Entwicklungen. Praktisch keine bestehende Anwendung (Architektur) kann einfach migriert werden. Sie können migrieren, müssen jedoch von Grund auf neu beginnen.
Das bedeutet, dass in der überwältigenden Mehrheit der Fälle serverless Plattformen als Ergänzung zu internen Servern verwendet werden, um Aufgaben mit hohem Rechenaufwand auszuführen. Dies unterscheidet sie stark von den beiden anderen Formen der Cloud-Technologie – Containern und virtuellen Maschinen, die einen ganzheitlichen Ansatz für die Ausführung von Remote-Berechnungen bieten. Dies veranschaulicht eine der Herausforderungen beim Übergang von Mikroservices zu serverless Systemen.
Natürlich ist das nicht immer ein Problem. Die Möglichkeit, zeitweise große Rechenressourcen zu nutzen, ohne eigene Hardware zu kaufen, kann für viele Organisationen einen echten und langfristigen Nutzen bringen. Wenn jedoch einige Anwendungen auf internen Servern und andere auf serverlosen Cloud-Architekturen betrieben werden, erhöht sich die Komplexität des Managements erheblich.
Es lebe die Revolution?
Trotz all dieser Beschwerden stehe ich serverlosen Lösungen als solche positiv gegenüber. Ehrlich gesagt. Entwickler sollten jedoch verstehen – insbesondere, wenn sie serverlose Modelle zum ersten Mal erkunden – dass diese Technologie keinen direkten Ersatz für Server darstellt. Stattdessen sollten Sie sich mit unseren Ratschlägen und Ressourcen zur vertraut machen und entscheiden, wie dieses Modell am besten angewendet werden kann.
Quelle: habr.com
