Nach Microservices ist die nächste Revolution in der Softwarearchitektur Serverless. Es gibt bereits viele großartige Blog-Beiträge zu diesem Thema und einige habe ich am Ende indexiert. Dies sind meine eigenen Ansichten zu Serverless.
Etwas Geschichte
Wie wir wissen, sind Server nur ein weiterer Computer. Ähnlich wie Desktops haben sie einen Prozessor, RAM usw., die auf der Hauptplatine befestigt sind, und die Hauptplatine benötigt Strom. Sie verfügen möglicherweise nicht über eine eigene Tastatur oder einen eigenen Monitor, sondern können aus der Ferne gesteuert werden. Diese physischen Server haben normalerweise eine hohe Hardwarekonfiguration, die für normale Arbeitslasten nicht benötigt wird. Daher werden ihre Ressourcen gemeinsam genutzt, indem mehrere kleine Maschinen in ihnen untergebracht werden, die wir als virtuelle Maschinen (VMs) bezeichnen. Ein weiterer Grund für VMs ist, dass wir die VMs einfach per Software verwalten können. So können wir zum Beispiel eine Windows-VM löschen und eine vollständige Linux-VM über eine Software zur Verwaltung virtueller Maschinen erstellen. Außerdem können wir den Arbeitsspeicher, die Festplatte usw. der virtuellen Maschine leicht anpassen.
In einem herkömmlichen internen Rechenzentrum müssen wir als Operations Engineering/Infra-Team dafür sorgen, dass genügend physische Server vorhanden sind, die den dynamischen Anforderungen der VMs verschiedener Anwendungen gerecht werden können. Zu einem bestimmten Zeitpunkt werden die meisten Maschinen nicht ausgelastet sein, wenn man ihre Kapazität berücksichtigt. Aus der Sicht der Softwareentwickler müssen sie dafür sorgen, dass auf diesen Rechnern die richtige Software installiert ist und dass sie je nach Nutzung hoch- oder runterskaliert werden. Die Cloud-Umgebung der alten Generation, d.h. IaaS, löst dieses Problem der Bereitstellung von Rechnern problemlos. Obwohl das Team für den Betrieb der Infrastruktur mit IaaS zufrieden war, war es das für die Anwendungssoftware nicht, da ihre Aufgaben nicht geringer wurden. Aus diesem Grund hat sich die Cloud zu immer abstrakteren Ebenen wie PaaS, SaaS usw. weiterentwickelt. Auf jeder höheren Ebene wird mehr Abstraktion hinzugefügt und die Entwickler konzentrieren sich langsam nicht mehr auf die Hardware, sondern auf den Softwareaspekt des Systems.
Die Anwendungssoftware war mit IaaS nicht zufrieden, weil ihre Aufgaben nicht reduziert wurden. Deshalb hat sich die Cloud zu abstrakteren Ebenen wie PaaS, SaaS usw. weiterentwickelt. Auf jeder höheren Ebene wird mehr Abstraktion hinzugefügt und die Entwickler entfernen sich von der Hardware und konzentrieren sich auf den Softwareaspekt des Systems.
Einführung von PaaS
Bei PaaS müssen sich die Entwickler nicht um die Plattform kümmern und die Skalierung ist weniger mühsam als bei IaaS. Mit einem Schieberegler oder Befehl können sie die Skalierung steuern. Einige Cloud-Anbieter bieten eine automatische Skalierung auf dieser Ebene an, aber die Entwickler müssen einen Code schreiben, um zu bestimmen, wann skaliert werden soll. Dies löst wirklich alle Probleme, die entstehen, wenn Software als Paket/Bündel bereitgestellt wird, das verwandte Aufgaben erfüllt, z.B. eine Website oder APIs, die über das Web zugänglich sind.
Da bei PaaS die Bereitstellungseinheit ein Paket ist, gilt die Skalierung für alle darin enthaltenen Aufgaben, unabhängig von der Nutzung der einzelnen Aufgaben. Beispiel: Wir haben 10 APIs in einer WebAPI-Bereitstellung und nur 5 werden stark genutzt. Aber wenn wir skalieren, wird die gesamte WebAPI-Bereitstellung skaliert.
Einführung von FaaS (Funktion-as-a-Service)
Wir haben gesehen, dass die Skalierung ein Problem bei PaaS ist. Eine Möglichkeit, jede Aufgabe individuell zu skalieren, besteht darin, das Bereitstellungspaket auf Aufgabenebene aufzuteilen, sodass jedes Bereitstellungspaket nur einen Job/eine Aufgabe hat. Das ist etwas, das Microservices zu erreichen versucht haben. Die App so weit wie möglich aufteilen.
Aber das erfordert immer noch eine Überwachung. Jemand muss die Skalierung überwachen und je nach Nutzung anpassen. Faule Entwickler wollen auch das loswerden und so kommt FaaS ins Spiel. Hier wird jede Funktion zu einer Bereitstellungseinheit. Mit FaaS waren die Cloud-Anbieter in der Lage, eine echte automatische Skalierung anzubieten. Die Entwickler müssen nichts mehr überwachen. Das macht der Anbieter.
Was ist Serverless?
Wenn wir uns PaaS ansehen, haben die Cloud-Anbieter damit begonnen, Server zu verwalten. Wir mussten lediglich ein Bereitstellungspaket bereitstellen und der Rest wurde vom Anbieter übernommen. Aber es gab einen Aufwand bei der Überwachung. Bei FaaS übernahmen die Cloud-Anbieter das gesamte Eigentum an den Servern. Aber das waren nicht die einzigen Faktoren für den Aufstieg von Serverless.
Kostenlose hochleistungsfähige serverseitige Ausführung
Viele Cloud-Anbieter nahmen den Entwicklern nicht nur die Hardware weg, sondern begannen auch, kostenlose Tiers anzubieten. Da die Kosten für die Gründung eines Cloud-basierten Unternehmens sehr niedrig sind – zu diesem Zeitpunkt fast 0 -, haben sich Startups natürlich dafür entschieden, ihre Ideen in diesem Modell ohne große Investitionen auszuprobieren. Sie konnten ihre Ideen sehr schnell auf den Markt bringen und selbst wenn es scheitert, konnten sie den finanziellen Verlust verkraften. Früher gab es nur sehr wenige Möglichkeiten, kostenlosen, industrietauglichen serverseitigen Code auszuführen.
Kostenloses HTML-Hosting in Industriequalität
Ein weiterer Fortschritt ist die Verfügbarkeit von kostenlosen HTML-Webhosting-Anbietern. Obwohl sie von Anfang an vorhanden waren, waren sie nicht in der Lage, Websites mit hohem Traffic zu hosten. Aber das war bei Git Pages und Amazon S3 Hosting nicht der Fall. Jetzt kann jeder mit 0 $ Hostingkosten ein Online-Geschäft starten. Das Einzige, was sie wissen müssen, ist, wie man grundlegende HTML+JS-Codierung und Integrationsfähigkeiten durchführt. Integrationsfähigkeiten sind nichts anderes als der Aufruf der oben genannten kostenlosen serverseitigen APIs über XmlHttpRequest oder einfach AJAX.
Fremium SaaS
Ein weiterer Vorteil ist die Verfügbarkeit zahlreicher Freemium-Dienste, um übergreifende Belange oder gemeinsame Funktionen zu realisieren. Wenn wir eine Login-Integration mit Google, Facebook usw. bereitstellen möchten, ist dies jetzt in wenigen Stunden möglich.
Erfolg des standardisierten Webs & Verfügbarkeit von mobilem und schnellem Internet
Dies sind einige weitere positive Ereignisse, die die Entwicklung von Serverless vorantreiben. Hätten sich die verschiedenen Browser unterschiedlich verhalten, wären jQuery und AngularJS nicht erfunden worden, hätte man das Wort Serverless vielleicht nie gehört. Die Startup-Gemeinschaft fand es kosteneffizient und da sie die treibende Kraft für Innovationen und Konferenzen sind, wurde Serverless zum nächsten Jargon. Offensichtlich mit der Unterstützung der echten Giganten oder der Cloud-Anbieter. Sehr bald werden auch Unternehmen diesen Weg einschlagen.
Die Startup-Gemeinschaft fand es kosteneffizient und da sie die treibende Kraft für Innovationen und Konferenzen sind, wurde Serverless zum nächsten Jargon. Offensichtlich mit der Unterstützung der echten Giganten oder der Cloud-Anbieter. Sehr bald werden auch Unternehmen diesen Weg einschlagen.
Gibt es wirklich keine Server?
Der Begriff ist ein wenig verwirrend. Es gibt zwar Server, aber sie werden vollständig vom Cloud-Anbieter oder dem SaaS-Anbieter verwaltet. Ohne Server, d.h. ohne Computer der oberen Leistungsklasse oder generell ohne Hardware, können wir unsere webbasierte Software nicht ausführen, außer bei Peer-to-Peer-Diensten wie Torrents.
Ich verwende FaaS. Bin ich in Serverless?
Zunächst müssen wir verstehen, dass Webanwendungen 2 Enden haben. Das eine ist das Front-End, das im Browser läuft und von einem Webserver bedient wird. Das andere ist das Back-End, in dem die Daten gespeichert sind und die Berechnungen stattfinden. Das Back-End können wir wiederum in eine Berechnungsschicht (Geschäftsschicht) und eine Datenschicht unterteilen. Die Verwendung von FaaS stellt sicher, dass unsere Berechnungen Serverless sind. Aber was ist mit der Datenschicht und dem Front-End? Wenn das Front-End aus dem eigenen Rechenzentrum oder von einer virtuellen IaaS-Maschine bedient wird, können wir nicht sagen, dass die Anwendung serverlos ist. Dies gilt auch für Datenbanken oder Dateien in der Datenschicht. Wenn wir uns also überhaupt keine Gedanken um einen Server machen müssen, können wir sagen, dass unsere Anwendung serverlos ist.
Wenn wir uns also überhaupt keine Gedanken über einen Server machen müssen, können wir sagen, dass unsere Anwendung serverlos ist.
Bedeutet serverlos kostenlos?
Serverless ist ein Architekturmuster und bedeutet nicht, dass es kostenlos ist. Aber wenn wir uns für diese Architektur entscheiden, können wir die Anwendung ohne Hosting-Gebühren zum Laufen bringen. Entwicklungskosten fallen immer an. Meistens fangen alle mit einer kostenlosen Version an und steigen auf eine kostenpflichtige Version um, sobald sie erfolgreich sind. Dieser Wechsel ist normalerweise nicht mit einer Codeänderung verbunden.
Erfordert Serverless ein starkes Bogen-Design im Vorfeld?
Serverless bietet eine große Flexibilität bei der Entwicklung, ähnlich wie Microservices. Wir können mehrere Sprachen wählen, die zu dem Dienst / der Funktion passen. Wir können technische Schulden leicht loswerden, indem wir heiße Funktionen neu schreiben. Die Architektur kann leicht geändert werden, da sie sich nur auf der Integrationsebene befindet.
Dies erfordert jedoch eine gute Architekturvision für die Integration. Andernfalls werden die Funktionen nicht zusammenarbeiten, um das gewünschte Verhalten zu erzeugen.
Wird es eine Funktionshölle geben?
Ja, wenn die Verwaltung und Überwachung der Funktionen nicht richtig erfolgt. Wenn wir jedem Tim und Harry erlauben, Funktionen ohne Überwachungsmechanismus zu schreiben, werden wir bald so viele Funktionen in der Produktionsumgebung haben, dass niemand mehr weiß, warum sie existieren.
Sollte ich morgen zu Serverless wechseln?
Als die Cloud angekündigt wurde, waren viele Branchen nicht bereit, sie zu akzeptieren, und die Sorge galt der Sicherheit. Aber jetzt sehen wir, wie sich die Meinungen ändern. Selbst Banken versuchen, die Cloud so weit wie möglich zu nutzen. Es steht außer Frage, dass Serverless die Zukunft sein wird, ähnlich wie es bei Microservices der Fall ist. Aber wie immer, bevor wir unsere bestehende App umstellen oder die nächste App mit Serverless starten, müssen wir die Vor- und Nachteile vergleichen.
Sollte ich morgen zu Serverless wechseln?
Als die Cloud angekündigt wurde, waren viele Branchen nicht bereit, sie zu akzeptieren, und die Sorge galt der Sicherheit. Aber jetzt sehen wir, wie sich die Meinungen ändern. Selbst Banken versuchen, die Cloud so weit wie möglich zu nutzen. Es steht außer Frage, dass Serverless die Zukunft sein wird, ähnlich wie es bei Microservices der Fall ist. Aber wie immer, bevor wir unsere bestehende App umstellen oder die nächste App mit Serverless starten, müssen wir die Vor- und Nachteile vergleichen.
Der folgende Vergleich geht davon aus, dass Serverless neben SaaS auch FaaS verwendet. Daher können einige Faktoren für FaaS oder SaaS geeignet erscheinen.
Im folgenden Vergleich wird davon ausgegangen, dass Serverless FaaS zusammen mit SaaS verwendet. Einige Faktoren könnten also für FaaS oder SaaS geeignet erscheinen.
Pros
- Eine einzige Verantwortung auf Funktionsebene – Das ist etwas, das wir von Anfang an bei der Softwareentwicklung anstrebten, aber da es von der Gnade der Entwickler abhing, war es sehr schwierig, es zu erreichen. Bei Serverless wird die Verantwortung durch die Architektur erzwungen.
- Kosten – Theoretisch sollten sie geringer sein, da wir nur für das bezahlen, was wir nutzen. Aber dieser Faktor wird sich mit mehr Echtzeit-Berichten über die Nutzung großer Mengen ändern.
- Skalierbare Kodierung – Die Kodierung kann effizient skaliert und sogar im Browser durchgeführt werden. Dies sollte idealerweise mit einem geeigneten Integrationsplan auf hoher Ebene einhergehen.
- Einfaches Code-Management – Wir können technische Schulden durch das Umschreiben von Funktionen leicht loswerden.
- Mehr Auswahl an Sprachen – Ähnlich wie bei Microservices können wir verschiedene Sprachen für verschiedene Funktionen auswählen. Aber das ist ein zweischneidiges Schwert.
- Einfacher Wechsel des Anbieters – Da die Bereitstellung auf Funktionsebene erfolgt, können wir den Anbieter schrittweise Funktion für Funktion wechseln.
Nachteile
- Viele Fehlerquellen – Da unsere App von vielen SaaS abhängen kann, kann der Ausfall einer dieser SaaS zu einem Zusammenbruch unserer gesamten App führen. Andernfalls müssen wir Ausweichmechanismen verwenden.
- Nicht alle SaaS sind auf der ganzen Welt gleichermaßen verfügbar – Wenn wir Facebook als einzigen Login-Anbieter verwenden, können Personen aus Ländern, in denen Facebook verboten ist, unsere Software nicht nutzen. Außerdem kann jedes Land oder jede Region alles blockieren. Sie müssen also die ganze Welt überwachen.
- Die Funktionshölle
- Leistung – Der Endbenutzer braucht sich keine Gedanken darüber zu machen, dass die App serverlos ist und die Leistungseinbußen auf X SaaS oder Y Cloud-Anbieter zurückzuführen sind. Für sie ist die Website/App eine einzige Einheit und die Sicherstellung der Leistung ist die Aufgabe des Entwicklers.
- Integrationskomplexität – Die gesamte geschäftliche Komplexität der App kann nicht geändert, aber verschoben werden. Bei Serverless wird sie lediglich von der Komponentenebene auf eine höhere Integrationsebene verschoben.
- Leistung von verketteten Aufrufen – Wenn das Geschäft eine komplexe Verarbeitungskette erfordert, kann dies die Leistung beeinträchtigen. Es wäre besser, diese in eine Warteschlange zu stellen.
- Leistung der Service-Instanz-Aktivierung – Bei einem Auslöser wird erwartet, dass die Cloud-Laufzeitumgebung vor der Ausführung eine aus der vorhandenen auswählt oder eine neue Laufzeitumgebung für die Funktion startet. Die Zeit für die Einrichtung dieser Umgebung wirkt sich auf die Leistung aus. Dies hängt von der anbieterspezifischen FaaS-Laufzeitimplementierung ab.
- Weniger Kontrolle – Wenn wir ein unvermeidliches Szenario eines lang laufenden Dienstes haben, kann der Anbieter unsere Dienstinstanz aufgrund von Zeitüberschreitungen herauswerfen. Dies ist zwar kein gravierender Nachteil, hängt aber vom Anbieter ab.
- Fehlende Werkzeuge – Dies ist ein vorübergehender Nachteil. Mit der Zeit werden weitere Tools, IDEs und Offline-Testlösungen entwickelt.
- Der Entwickler vergisst die Hardware – Dies kann sowohl als Vorteil als auch als Nachteil angesehen werden.
Serverless bringt Entwickler dazu, sich von der Hardware zu entfernen
Darüber lässt sich streiten. Aber unabhängig von der Debatte, die wir führen, entfernt sich ein großer Teil der Entwickler von der Hardware. Aber hat das mit Serverless angefangen? Nein.
Die Entwicklung begann, als die Assembler-Sprache erfunden wurde. Anstelle von 1en und 0en verwendeten die Leute Mov A,B oder PUSH B, usw. Mit den Compilern ging es dann weiter bergab. Später kamen verwaltete Plattformen zusammen mit virtuellen Maschinen auf den Markt. Das alles hat die Entwickler von den Bare-Metal-Maschinen weggeführt.
Die große Kluft zwischen den Entwicklern
Dies ist eher eine natürliche Entwicklung. Es wird einige Zeit dauern, bis sich 2 Arten von Entwicklern herausbilden. Das ist wiederum ein eigenes Thema, das in einem separaten Beitrag diskutiert werden sollte. Ich bin mir nicht sicher, ob der Begriff „The great developer divide“ (die große Kluft zwischen den Entwicklern) dem Phänomen gerecht wird.
Referenzen
https://read.acloud.guru/serverless-the-future-of-software-architecture-d4473ffed864
http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html
Dieser Artikel wurde aus dem persönlichen Blog des Autors wiederveröffentlicht. Für eine Referenz, klicken Sie hier.
