Schlüsselelemente
- Bereits seit mehreren Jahren wird uns versprochen, dass serverlose Berechnungen eine neue Ära ohne spezifisches Betriebssystem zur Ausführung von Anwendungen einleiten werden. Es wurde uns gesagt, dass diese Struktur zahlreiche Skalierbarkeitsprobleme lösen würde. In Wirklichkeit ist alles anders.
- Obwohl viele die serverlose Technologie als neue Idee betrachten, reichen ihre Wurzeln bis ins Jahr 2006 zurück, als Zimki PaaS und Google App Engine erschienen – in beiden Fällen wird eine serverlose Architektur verwendet.
- Es gibt vier Gründe, warum die serverlose Revolution ins Stocken geraten ist: von begrenzter Unterstützung für Programmiersprachen bis hin zu Leistungsproblemen.
- Serverlose Berechnungen sind nicht völlig nutzlos. Überhaupt nicht. Dennoch sollten sie nicht als direkte Ersatz für Server angesehen werden. Für einige Anwendungen können sie ein nützliches Werkzeug sein.
Der Server ist tot, lang lebe der Server!
So lautet der Schlachtruf der Anhänger der serverlosen Revolution. Ein flüchtiger Blick in die Branchennachrichten der letzten Jahre lässt leicht den Schluss zu, dass das traditionelle Servermodell tot ist und dass wir in wenigen Jahren alle serverlose Architekturen nutzen werden.
Wie jeder in der Branche weiß, und wie wir auch in unserem Artikel über , ist das nicht der Fall. Trotz zahlreicher Artikel über die Vorteile hat sie sich nicht durchgesetzt. Tatsächlich zeigen , dass diese Revolution möglicherweise ins Stocken geraten ist.
Einige der Versprechen für serverlose Modelle sind zweifellos realisiert worden, aber nicht alle. Bei weitem nicht alle.
In diesem Artikel möchte ich die Gründe für diesen Zustand untersuchen. Warum ist das Fehlen von Flexibilität in serverlosen Modellen weiterhin ein Hindernis für ihre breitere Einführung, obwohl sie in bestimmten, klar definierten Umständen weiterhin nützlich bleiben?
Was die Anhänger der serverlosen Berechnungen versprochen haben
Bevor wir zu den Problemen der serverlosen Berechnungen übergehen, lassen Sie uns anschauen, was sie versprochen haben. waren zahlreich und manchmal sehr ehrgeizig.
Für diejenigen, die mit dem Begriff nicht vertraut sind, hier eine kurze Definition: Serverless Computing beschreibt eine Architektur, in der Anwendungen (oder Teile von Anwendungen) bedarfsgerecht in Laufzeitumgebungen ausgeführt werden, die normalerweise remote gehostet werden. Darüber hinaus können serverless Systeme auch intern gehostet werden. In den letzten Jahren war der Aufbau robuster serverloser Systeme eine Hauptsorge für Systemadministratoren und SaaS-Unternehmen, da (so behauptet man) diese Architektur mehrere entscheidende Vorteile im Vergleich zur "traditionellen" Client-Server-Modell bietet:
- Serverless Modelle erfordern nicht, dass Benutzer ihre eigenen Betriebssysteme verwalten oder sogar Anwendungen erstellen, die mit bestimmten Betriebssystemen kompatibel sind. Stattdessen erstellen Entwickler gemeinsamen Code, laden ihn in eine serverlose Plattform hoch und überwachen dessen Ausführung.
- Ressourcen in serverlosen Frameworks werden normalerweise pro Minute (oder sogar pro Sekunde) abgerechnet. Das bedeutet, dass Kunden nur für die Zeit bezahlen, in der sie den Code tatsächlich ausführen. Das unterscheidet sich vorteilhaft von einer traditionellen Cloud-VM, wo die Maschine die meiste Zeit untätig ist, aber trotzdem bezahlt werden muss.
- Das Problem der Skalierbarkeit wurde ebenfalls angegangen. Ressourcen in serverlosen Frameworks werden dynamisch zugewiesen, sodass das System plötzlich steigende Nachfragen problemlos bewältigen kann.
Kurz gesagt, serverlose Modelle bieten flexible, kostengünstige und skalierbare Lösungen. Es ist erstaunlich, dass wir nicht früher auf diese Idee gekommen sind.
Ist das wirklich eine neue Idee?
Tatsächlich ist die Idee nicht neu. Das Konzept, das es Nutzern ermöglicht, nur für die Zeit zu zahlen, in der der Code tatsächlich ausgeführt wird, existiert seit der Einführung von im Jahr 2006, und etwa zur gleichen Zeit bot Google App Engine eine sehr ähnliche Lösung an.
Tatsächlich ist das, was wir jetzt als "serverloses" Modell bezeichnen, älter als viele Technologien, die heute als "cloud-native" bezeichnet werden und fast dasselbe bieten. Wie bereits erwähnt, sind serverlose Modelle im Wesentlichen nur eine Fortsetzung des Geschäftsmodells von SaaS, das seit mehreren Jahrzehnten existiert.
Es ist auch anzuerkennen, dass das serverlose Modell keine FaaS-Architektur ist, obwohl zwischen ihnen eine Verbindung besteht. FaaS ist im Wesentlichen der rechenzentrische Teil der serverlosen Architektur, stellt aber nicht das gesamte System dar.
Warum all der Aufruhr? Nun, da die Geschwindigkeit des Internetzugangs in Entwicklungsländern weiterhin rasant steigt, wächst gleichzeitig die Nachfrage nach Rechenressourcen. Viele Länder mit schnell wachsenden E-Commerce-Sektoren haben beispielsweise einfach keine Recheninfrastruktur für Anwendungen auf diesen Plattformen. Hier kommen kostenpflichtige serverlose Plattformen ins Spiel.
Probleme serverloser Modelle
Das Problem ist, dass serverlose Modelle... Probleme haben. Verstehen Sie mich nicht falsch: ich sage nicht, dass sie per se schlecht sind oder keinen wesentlichen Wert für bestimmte Unternehmen in bestimmten Umständen bieten. Aber die Hauptbehauptung der "Revolution" – dass die serverlose Architektur die traditionelle schnell ersetzen wird – wird niemals erfüllt werden.
Deshalb.
Eingeschränkte Unterstützung von Programmiersprachen
Die meisten serverlosen Plattformen erlauben es nur, Anwendungen auszuführen, 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 Sprachen unterstützen. AWS Lambda und Azure Functions bieten auch eine Wrapper-Lösung, um Anwendungen und Funktionen in nicht unterstützten Sprachen auszuführen, obwohl dies oft mit Leistungseinbußen verbunden ist. Für die meisten Organisationen ist dieser Einschränkung in der Regel nicht sehr relevant. Aber hier ist das Problem. Es wird angenommen, dass einer der Vorteile serverloser Modelle darin besteht, dass unbekannte, wenig genutzte Programme günstiger genutzt werden können, da man nur für die Ausführungszeit zahlt. Diese unbekannten, wenig genutzten Programme werden jedoch oft in... unbekannten, wenig genutzten Programmiersprachen geschrieben.
Dies untergräbt einen der entscheidenden Vorteile des serverlosen Modells.
Vendor-Lock-in
Ein zweites Problem mit serverlosen Plattformen oder zumindest mit der Art und Weise, wie sie derzeit umgesetzt werden, besteht darin, dass sie auf Betriebssystemebene normalerweise nicht ähnlich sind. Es gibt praktisch keine Standardisierung beim Schreiben von Funktionen, beim Deployment und beim Management. Das bedeutet, dass die Migration von Funktionen von einer Plattform zur anderen äußerst zeitaufwendig ist.
Der schwierigste Teil des Wechsels zu einem serverlosen Modell sind nicht die rechenintensiven Funktionen, die in der Regel einfach Codefragmente sind, sondern die Art und Weise, wie Anwendungen mit angeschlossenen Systemen, wie Objekt-Speichern, Identitätsmanagement und Warteschlangen, verbunden sind. Funktionen können verschoben werden, aber der Rest der Anwendung nicht. Dies steht in vollem Widerspruch zu den versprochenen kostengünstigen und flexiblen Plattformen.
Einige behaupten, dass serverlose Modelle erst kürzlich entstanden sind und es keine Zeit gab, ihre Funktionsweise zu standardisieren. Aber sie sind nicht so neu, wie ich oben bereits angemerkt habe, und viele andere Cloud-Technologien, wie Container, haben sich bereits erheblich verbessert, dank der Entwicklung und breiten Einführung guter Standards.
Leistung
Die Rechenleistung serverloser Plattformen ist schwer zu messen, zum Teil weil die Anbieter bestrebt sind, Informationen geheim zu halten. Die meisten behaupten, dass Funktionen auf entfernten, serverlosen Plattformen genauso schnell arbeiten wie auf internen Servern, abgesehen von einigen unvermeidlichen Verzögerungsproblemen.
Einige Fakten deuten jedoch auf das Gegenteil hin. Funktionen, die zuvor auf einer bestimmten Plattform nicht ausgeführt wurden oder eine Zeit lang nicht ausgeführt wurden, benötigen einige Zeit zur Initialisierung. Wahrscheinlich liegt das daran, dass ihr Code auf ein weniger zugängliches Speichermedium übertragen wurde, obwohl – wie bei Benchmarks – die meisten Anbieter Ihnen nichts über die Datenübertragung sagen werden.
Natürlich gibt es mehrere Möglichkeiten, dies zu umgehen. Eine davon besteht darin, Funktionen für jede Cloud-Sprache zu optimieren, auf der Ihre serverlose Plattform läuft, aber das untergräbt ein wenig die Behauptung, 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 ein wenig im Widerspruch zu der Behauptung, dass serverlose Plattformen kostengünstiger sind, da man nur für die Ausführungszeit seiner Programme bezahlt. Cloud-Anbieter haben neue Wege zur Reduzierung kalter Starts eingeführt, aber viele von ihnen erfordern ein „Scale to One“, was den ursprünglichen Wert von FaaS untergräbt.
Das Problem des „kalten Starts“ lässt sich teilweise lösen, indem man serverlose Systeme selbst betreibt, was jedoch mit eigenen Kosten verbunden ist und weiterhin eine Nischenlösung für ressourcenstarke Teams bleibt.
Sie können keine gesamten Anwendungen ausführen.
Letztendlich ist möglicherweise der wichtigste Grund, warum serverlose Architekturen in naher Zukunft traditionelle Modelle nicht ersetzen werden: Sie sind (in der Regel) nicht dafür geeignet, ganze Anwendungen auszuführen.
Genauer gesagt, ist es aus Kostensicht unpraktisch. Ihr erfolgreiches Monolith-System wird wahrscheinlich nicht in ein Set aus vier Dutzend Funktionen umgewandelt, die von acht Gateways, vierzig Warteschlangen und einem Dutzend Datenbankinstanzen verbunden sind. Aus diesem Grund ist serverless besser für Neuentwicklungen geeignet. Praktisch keine bestehende Anwendung (Architektur) kann migriert werden. Sie können migrieren, aber Sie müssen von Grund auf neu beginnen.
Das bedeutet, dass in der überwältigenden Mehrheit der Fälle serverlose Plattformen als Ergänzung zu internen Servern verwendet werden, um rechenintensive Aufgaben auszuführen. Dies unterscheidet sie stark von den zwei anderen Formen der Cloud-Technologie – Containern und virtuellen Maschinen, die einen ganzheitlichen Ansatz für das Ausführen von Remote-Berechnungen bieten. Dies veranschaulicht eine der Herausforderungen beim Übergang von Mikrodiensten zu serverlosen Systemen.
Natürlich stellt das nicht immer ein Problem dar. Die Möglichkeit, gelegentlich enorme Rechenressourcen zu nutzen, ohne eigene Hardware kaufen zu müssen, kann für viele Organisationen einen echten und langfristigen Vorteil bringen. Wenn jedoch einige Anwendungen auf internen Servern und andere auf serverlosen Cloud-Architekturen gehostet werden, wird das Management auf ein neues Komplexitätsniveau gebracht.
Es lebe die Revolution?
Trotz all dieser Beschwerden bin ich nicht gegen serverlose Lösungen an sich. Ehrenwort. Die Entwickler sollten jedoch verstehen - insbesondere wenn sie serverlose Modelle zum ersten Mal erkunden - dass diese Technologie keinen direkten Ersatz für Server darstellt. Stattdessen informieren Sie sich über unsere Tipps und Ressourcen zur und entscheiden Sie, wie Sie dieses Modell am besten nutzen können.
Quelle: habr.com
