Wichtige Punkte
- Seit einigen Jahren wird uns versprochen, dass serverloses Computing (serverlos) eine neue Ära ohne ein bestimmtes Betriebssystem zum Ausführen von Anwendungen eröffnen wird. Uns wurde gesagt, dass eine solche Struktur viele Skalierbarkeitsprobleme lösen würde. Tatsächlich ist alles anders.
- Obwohl viele die serverlose Technologie als eine neue Idee betrachten, lassen sich ihre Wurzeln bis ins Jahr 2006 mit Zimki PaaS und Google App Engine zurückverfolgen, die beide eine serverlose Architektur verwenden.
- Es gibt vier Gründe, warum die serverlose Revolution ins Stocken geraten ist: von eingeschränkter Programmiersprachenunterstützung bis hin zu Leistungsproblemen.
- Serverloses Computing ist gar nicht so nutzlos. Weit davon entfernt. Sie sollten jedoch nicht als direkter Ersatz für Server angesehen werden. Für manche Anwendungen können sie ein praktisches Werkzeug sein.
Der Server ist tot, es lebe der Server!
Das ist der Schlachtruf der Anhänger der serverlosen Revolution. Ein kurzer Blick auf die Branchenpresse der letzten Jahre reicht aus, um zu dem Schluss zu kommen, dass das traditionelle Servermodell tot ist und wir in ein paar Jahren alle serverlose Architekturen nutzen werden.
Wie jeder in der Branche weiß und wie wir auch in unserem Artikel darauf hingewiesen haben , das ist nicht so. Trotz vieler Artikel in der Sache , es hat nie stattgefunden. Tatsächlich, dass diese Revolution möglicherweise in eine Sackgasse geraten ist.
Einige der Versprechen für serverlose Modelle haben sich sicherlich erfüllt, aber nicht alle. Nicht jeder.
In diesem Artikel möchte ich die Gründe für diesen Zustand betrachten. Warum die mangelnde Flexibilität serverloser Modelle immer noch ein Hindernis für ihre breitere Einführung darstellt, obwohl sie unter bestimmten, genau definierten Umständen weiterhin nützlich sind.
Was die Anhänger des Serverless Computing versprochen haben
Bevor wir uns den Problemen des Serverless Computing zuwenden, wollen wir uns ansehen, was sie zu bieten hatten. waren zahlreich und teilweise sehr ehrgeizig.
Für diejenigen, die mit dem Begriff nicht vertraut sind, hier eine kurze Definition. Serverless Computing definiert eine Architektur, in der Anwendungen (oder Teile von Anwendungen) bei Bedarf in Laufzeitumgebungen ausgeführt werden, die normalerweise remote gehostet werden. Darüber hinaus können serverlose Systeme gehostet werden. Der Aufbau robuster serverloser Systeme war in den letzten Jahren ein Hauptanliegen von Systemadministratoren und SaaS-Unternehmen, da diese Architektur (angeblich) mehrere entscheidende Vorteile gegenüber dem „traditionellen“ Client/Server-Modell bietet:
- Serverlose Modelle erfordern nicht, dass Benutzer ihre eigenen Betriebssysteme verwalten oder sogar Anwendungen erstellen, die mit bestimmten Betriebssystemen kompatibel sind. Stattdessen erstellen Entwickler gemeinsam genutzten Code, laden ihn auf eine serverlose Plattform hoch und beobachten, wie er ausgeführt wird.
- Ressourcen in serverlosen Frameworks werden normalerweise minutenweise (oder sogar sekundenweise) abgerechnet. Das bedeutet, dass Kunden nur für die Zeit zahlen, die sie tatsächlich für die Ausführung des Codes benötigen. Dies ist im Vergleich zur herkömmlichen Cloud-VM günstig, bei der die Maschine die meiste Zeit im Leerlauf ist, Sie aber dafür bezahlen müssen.
- Auch das Problem der Skalierbarkeit wurde gelöst. Ressourcen in serverlosen Frameworks werden dynamisch zugewiesen, sodass das System plötzliche Nachfragespitzen problemlos bewältigen kann.
Kurz gesagt, serverlose Modelle bieten flexible, kostengünstige und skalierbare Lösungen. Ich bin überrascht, dass wir nicht schon früher auf diese Idee gekommen sind.
Ist das wirklich eine neue Idee?
Eigentlich ist die Idee nicht neu. Das Konzept, den Benutzern zu erlauben, nur für die Zeit zu zahlen, in der der Code tatsächlich ausgeführt wird, gibt es schon seit seiner Einführung im Jahr XNUMX Etwa zur gleichen Zeit entwickelte Google App Engine im Jahr 2006 eine sehr ähnliche Lösung.
Tatsächlich ist das, was wir heute als „serverloses“ Modell bezeichnen, älter als viele der heute als „Cloud-nativ“ bezeichneten Technologien, die fast dasselbe bieten. Wie bereits erwähnt, sind serverlose Modelle im Wesentlichen nur eine Erweiterung des SaaS-Geschäftsmodells, das es schon seit Jahrzehnten gibt.
Es ist auch erwähnenswert, dass das serverlose Modell keine FaaS-Architektur ist, obwohl zwischen beiden ein Zusammenhang besteht. FaaS ist im Wesentlichen der rechenzentrierte Teil einer serverlosen Architektur, repräsentiert jedoch nicht das gesamte System.
Warum also dieser ganze Hype? Nun, da die Internetverbreitung in Entwicklungsländern weiterhin rasant zunimmt, steigt auch die Nachfrage nach Computerressourcen. Beispielsweise verfügen viele Länder mit schnell wachsenden E-Commerce-Sektoren einfach nicht über die Computerinfrastruktur für Anwendungen auf diesen Plattformen. Hier kommen kostenpflichtige serverlose Plattformen ins Spiel.
Probleme mit serverlosen Modellen
Der Haken ist, dass serverlose Modelle … Probleme haben. Verstehen Sie mich nicht falsch: Ich sage nicht, dass sie an sich schlecht sind oder unter bestimmten Umständen für manche Unternehmen keinen nennenswerten Mehrwert bieten. Aber die Hauptaussage der „Revolution“ – dass die serverlose Architektur die traditionelle schnell ersetzen wird – wird nie Wirklichkeit.
Deshalb.
Begrenzte Unterstützung für Programmiersprachen
Die meisten serverlosen Plattformen erlauben nur die Ausführung von Anwendungen, die in bestimmten Sprachen geschrieben sind. Dies schränkt die Flexibilität und Anpassungsfähigkeit dieser Systeme stark ein.
Es wird davon ausgegangen, dass serverlose Plattformen die meisten wichtigen Sprachen unterstützen. AWS Lambda und Azure Functions bieten auch einen Wrapper für die Ausführung von Anwendungen und Funktionen in nicht unterstützten Sprachen, allerdings geht dies oft mit Leistungseinbußen einher. Für die meisten Organisationen ist diese Einschränkung daher normalerweise keine große Sache. Aber hier ist die Sache. Einer der Vorteile serverloser Modelle soll darin liegen, dass unbekannte, selten genutzte Programme günstiger genutzt werden können, da man nur für die Laufzeit zahlt. Und obskure, selten verwendete Programme werden oft in... obskuren, selten verwendeten Programmiersprachen geschrieben.
Dies untergräbt einen der Hauptvorteile des serverlosen Modells.
Bindung an einen Anbieter
Das zweite Problem bei serverlosen Plattformen oder zumindest der Art und Weise, wie sie derzeit implementiert werden, besteht darin, dass sie sich auf betrieblicher Ebene normalerweise nicht ähneln. Es gibt praktisch keine Standardisierung in Bezug auf Schreibfunktionen, Bereitstellung und Verwaltung. Das bedeutet, dass die Migration von Funktionen von einer Plattform auf eine andere äußerst zeitaufwändig ist.
Der schwierigste Teil bei der Umstellung auf ein serverloses Modell sind nicht die Rechenfunktionen, bei denen es sich normalerweise nur um Codeschnipsel handelt, sondern die Art und Weise, wie Anwendungen mit verbundenen Systemen wie Objektspeicher, Identitätsverwaltung und Warteschlangen kommunizieren. Funktionen können verschoben werden, der Rest der Anwendung jedoch nicht. Dies ist das genaue Gegenteil der versprochenen günstigen und flexiblen Plattformen.
Einige argumentieren, dass serverlose Modelle neu seien und noch keine Zeit sei, ihre Funktionsweise zu standardisieren. Aber sie sind nicht so neu, wie ich oben erwähnt habe, und viele andere Cloud-Technologien wie Container sind aufgrund der Entwicklung und weiten Verbreitung guter Standards bereits viel komfortabler geworden.
Leistung
Die Rechenleistung serverloser Plattformen ist schwer zu messen, auch weil Anbieter dazu neigen, Informationen geheim zu halten. Die meisten argumentieren, dass Funktionen auf Remote-Plattformen ohne Server genauso schnell laufen wie auf internen Servern, abgesehen von einigen unvermeidlichen Latenzproblemen.
Einige Beweise deuten jedoch auf etwas anderes hin. Die Initialisierung von Funktionen, die zuvor auf einer bestimmten Plattform nicht oder schon seit einiger Zeit nicht ausgeführt wurden, dauert einige Zeit. Dies liegt wahrscheinlich daran, dass ihr Code auf ein weniger leicht verfügbares Speichermedium portiert wurde, obwohl Ihnen die meisten Anbieter – wie bei Benchmarks – nichts über die Portierung von Daten sagen.
Natürlich gibt es mehrere Möglichkeiten, dies zu umgehen. Eine besteht darin, Funktionen für jede Cloud-Sprache zu optimieren, auf der Ihre serverlose Plattform läuft, aber das untergräbt etwas den Anspruch, dass diese Plattformen „agil“ sind.
Ein anderer Ansatz besteht darin, sicherzustellen, dass leistungskritische Programme regelmäßig ausgeführt werden, um sie „frisch“ zu halten. Dieser zweite Ansatz widerspricht natürlich ein wenig der Behauptung, dass serverlose Plattformen kostengünstiger seien, weil Sie nur für die Zeit bezahlen, die Ihre Programme laufen. Cloud-Anbieter haben neue Möglichkeiten zur Reduzierung von Kaltstarts eingeführt, aber viele von ihnen erfordern eine „Skalierung auf eins“, was den ursprünglichen Wert von FaaS untergräbt.
Das Problem des Kaltstarts lässt sich teilweise dadurch lösen, dass serverlose Systeme intern betrieben werden. Dies geht jedoch auf eigene Kosten und bleibt eine Nischenoption für gut ausgestattete Teams.
Sie können nicht ganze Anwendungen ausführen
Schließlich ist vielleicht der wichtigste Grund, warum serverlose Architekturen traditionelle Modelle nicht so schnell ersetzen werden, dass sie (im Allgemeinen) keine vollständigen Anwendungen ausführen können.
Genauer gesagt ist es aus Kostengesichtspunkten unpraktisch. Ihr erfolgreicher Monolith sollte wahrscheinlich nicht in einen Satz von vier Dutzend Funktionen umgewandelt werden, die durch acht Gateways, vierzig Warteschlangen und ein Dutzend Datenbankinstanzen miteinander verbunden sind. Aus diesem Grund eignet sich Serverless besser für Neuentwicklungen. Praktisch keine bestehende Anwendung (Architektur) kann portiert werden. Sie können migrieren, müssen aber bei Null anfangen.
Das bedeutet, dass in den allermeisten Fällen serverlose Plattformen als Ergänzung zu Back-End-Servern eingesetzt werden, um rechenintensive Aufgaben auszuführen. Dies unterscheidet sich stark von den beiden anderen Formen des Cloud Computing, Containern und virtuellen Maschinen, die eine ganzheitliche Möglichkeit zur Durchführung von Remote Computing bieten. Dies verdeutlicht eine der Herausforderungen bei der Migration von Microservices zu serverlosen Systemen.
Natürlich ist das nicht immer ein Problem. Die Möglichkeit, regelmäßig riesige Rechenressourcen zu nutzen, ohne eigene Hardware kaufen zu müssen, kann für viele Unternehmen echte und dauerhafte Vorteile bringen. Wenn sich jedoch einige Anwendungen auf internen Servern und andere auf serverlosen Cloud-Architekturen befinden, erreicht die Verwaltung eine neue Ebene der Komplexität.
Lang lebe die Revolution?
Trotz all dieser Beschwerden bin ich nicht grundsätzlich gegen serverlose Lösungen. Ehrenwort. Entwickler müssen sich lediglich darüber im Klaren sein, dass diese Technologie kein direkter Ersatz für Server ist, insbesondere wenn sie sich zum ersten Mal mit serverlosen Modellen befassen. Schauen Sie sich stattdessen unsere Tipps und Ressourcen an und entscheiden Sie, wie Sie dieses Modell am besten anwenden.
Source: habr.com