Sowohl Container als auch serverlose Bereitstellungs- und Entwicklungsmodelle sind Teil der Kultur einer skalierbaren Architektur, die je nach Verwendung der Anwendung verfügbar ist. Dies macht es schwierig, sich zwischen den beiden zu entscheiden, und genau das werden wir in diesem Beitrag besprechen.
What are containers?
Container bieten nicht nur die Möglichkeit, einige Einschränkungen der traditionellen Virtualisierung zu überwinden, sondern legen den Grundstein für einen radikalen Wandel im Verständnis der Entwicklung und des Lebenszyklus von Diensten.
Die Idee hinter Containern wurde nicht in der Linux-Welt geboren, sondern hat ihre Wurzeln in einer im Jahr 2000 erschienenen Technologie namens FreeBSD Jail, die es ermöglicht, ein FreeBSD-System in Untersysteme (Jail) zu unterteilen, die sowohl voneinander als auch voneinander isoliert sind das zugrunde liegende System, indem das Konzept von chroot erweitert wird.
Dies wurde mit dem Linux Vserver-Projekt in die Linux-Welt gebracht und in den folgenden Jahren mit neuen Technologien, darunter cgroup, systemd und Linux Kernel Namespace, integriert, wodurch das Projekt Linux Container (LXC) skizziert wurde.
Im Jahr 2008, mit der Ankunft von Docker, neue Tools und neue Ideen wurden hinzugefügt, wie die Möglichkeit, Bilder mit Ebenen zu erstellen (dh aus der Zusammenführung mehrerer Bilder zu resultieren) und die Einführung der Bildregistrierung. Container-Projekte in der Linux-Welt haben daher einen neuen Schub erhalten, der zur Geburt der Open Container Initiative geführt hat, deren Mitglieder, darunter Docker und Red Hat, zusammenarbeiten, um offene und gemeinsame Standards für Container-Technologien zu definieren.
Angesichts dieser Prämissen und dieser verfügbaren Tools ist es natürlich, sich zu fragen, ob es Alternativen zur traditionellen Virtualisierung gibt.
Abgesehen von den eher technischen Aspekten ist ein Linux-Container die Gruppe von einem oder mehreren Prozessen, die vom Rest des Systems isoliert sind, die:
- Haben Sie eine Standard-Verwaltungsschnittstelle (zum Starten, Stoppen, Umgebungsvariablen)
- Optimieren Sie die Nutzung von Ressourcen in Bezug auf virtuelle Maschinen
- Vereinfachen Sie die Verwaltung größerer Anwendungen (verteilt auf mehrere Container)
Das Vorhandensein der von Standardisierungsgremien vorgeschlagenen Standards garantiert auch die Interoperabilität und die Möglichkeit, Container sogar zwischen verschiedenen Clouds zu orchestrieren.
Das Konzept der Bilder und die Art und Weise, sie zu konstruieren und zu aggregieren, stellt den bedeutendsten und innovativsten Aspekt dar, nicht so sehr aus technologischer Sicht, sondern in Bezug auf die Auswirkungen auf die Entwicklung und das Betriebsmanagement, mit Konsequenzen, die sich auch auf die Art und Weise von auswirken Geschäft verstehen.
Die Images sind unveränderlich, d. h. jeder Container, der von demselben Image ausgeführt wird, ist identisch mit den anderen, er enthält keine Statusinformationen oder persistente Daten. Persistenz wird anderen Werkzeugen anvertraut, wie z externe Datenbanken und Dateisysteme. Dies bestimmt zunächst eine klare Unterscheidung zwischen der Laufzeitumgebung der Anwendung und den Daten, auf denen sie operiert, und führt funktionale Trennungslogiken ein, die Vorteile in Bezug auf Reinigung, Prozessmanagement und Sicherheit bringen.
Die wirkliche Innovation im Entwicklungsprozess und im Lebenszyklus der Anwendung liegt in der Tatsache, dass, sobald eine vollständige und konsistente Betriebsumgebung auf einem oder mehreren Bildern erstellt wurde, getrennt von den Daten, auf denen sie operiert, dies möglich ist durchlaufen alle Phasen von der Entwicklung bis zur Produktion unverändert.
What is Serverless?
Obwohl Container im Vergleich zu virtuellen Maschinen eine verbesserte Ressourcenzuweisung ermöglichen, ermöglichen sie Ihnen nicht wirklich, auf Null zu skalieren und linear zu wachsen: Wenn ein Container keine Dienste bereitstellt, bleibt er dennoch als Prozess aktiv. Eine Antwort auf dieses Bedürfnis kann kommen serverlose Ansätze.
Eine wirklich effiziente Ressourcenzuweisung erfordert, dass die gesamte Rechenleistung tatsächlich nur bei Bedarf instanziiert und unmittelbar nach der Verwendung freigegeben wird.
Die ersten Schritte in diese Richtung wurden von Google mit der Einführung der Google App Engine im Jahr 2008 unternommen, aber der eigentliche Schub kam mit der Einführung von Amazon im Jahr 2014 AWS Lambda, das erste echte FaaS-Modell. Anschließend kamen Alternativlösungen anderer Anbieter hinzu: Microsoft mit Azure Functions, IBM und Google mit eigenen Cloud Functions. Auch die Open-Source-Welt hat sich mit der Veröffentlichung von Produkten wie Apache OpenWhisk, OpenLambda und IronFunctions in diese Richtung bewegt.
- Quelle: epsagon.com
Serverloses Rechnen ist eine der Möglichkeiten, Dienste in einem Cloud-Kontext zu verteilen, der die Ausführung von Anwendungen oder, genauer gesagt, Funktionen beinhaltet, ohne dass eine Sichtbarkeit der zugrunde liegenden Infrastruktur erforderlich ist: Bereitstellung, Skalierung und Verwaltung erfolgen automatisch und linear nur angesichts realer Wünsche und Bedürfnisse. Der Begriff Serverless ist also nicht als „Abwesenheit“ von Servern zu verstehen, sondern als Transparenz der beteiligten Systeme aus Sicht von Entwicklern und Anwendern.
Diese Funktion bedeutet, dass die DevOps-Paradigma, typisch für den Einsatz containerisierter Technologien, wird aufgegeben, um zu einer neuen, klareren Unterscheidung zwischen der Infrastruktur- und der Anwendungskomponente zurückzukehren, wodurch zwei neue Konzepte in die Cloud-Welt eingeführt werden:
- FaaS (Function as a Service) ermöglicht Entwicklern eine Ausführungsumgebung für ihre Anwendungen (sei es C#, Java, Node.js, Python usw.), die nur als Reaktion auf bestimmte Ereignisse instanziiert wird.
- BaaS (Backend as a Service) ermöglicht es, die typischen Funktionen der Anwendungen an Dritte zu delegieren, ohne sie selbst implementieren zu müssen (z. B. bei Diensten wie Auth0, das Identitätsmanagement- und Authentifizierungsfunktionen bietet).
Da sind viele Serverlose Frameworks auf dem Markt erhältlich.
The main difference between serverless and containers
Container sind sehr wichtig für den Aufschwung, den die Serverless-Architektur genommen hat, hauptsächlich um Konzepte und die Kultur einzubeziehen, die alten virtuellen Maschinen und klassischen Server nicht mehr zu verwenden. Alles kann ohne Komplikationen oder Komplexität lokal oder in der Cloud gehostet werden.
Der große Unterschied zwischen einer serverlosen Architektur mit FaaS und Containern besteht darin, dass man sich nicht um die Prozesse kümmert, die auf Betriebssystemebene ausgeführt werden. Selbst mit Diensten wie Docker, die ähnliche Abstraktionsfähigkeiten wie die Container-Technologie bieten, insbesondere wenn sie in Verbindung mit Kubernetes verwendet werden, ermöglichen serverlose Architektur und FaaS einen noch höheren Grad dieser Art von Abstraktion in der Anwendungsentwicklung.
In einer serverlosen Architektur, die FaaS verwendet, wird die Skalierbarkeit der Anwendung automatisch und transparent verwaltet, und sie hat auch die Kapazität einer hohen Granularität des Dienstes für die beste Leistung. Plattformen, die Container verwenden, müssen diese Bereitstellung manuell verwalten, selbst mit automatisierten Tools.
Letztendlich entscheiden der Stil der Anwendung und die verfügbare Infrastruktur darüber, welche der beiden Bereitstellungsformen die beste ist. Die serverlose Architektur weist ein hohes Maß an Abstraktion der Betriebssystemverarbeitung auf, während sich Container weiterentwickeln und Wege zur Automatisierung von Skalierbarkeit und Verfügbarkeit entwickeln.
How to choose between serverless and containers?
In dieser Übersicht haben wir versucht aufzuzeigen, wie radikal der Wandel ist, der die Welt der IT-Services in den letzten Jahren erschüttert und Infrastrukturen, Entwicklungsmodelle und sogar Geschäftsmodelle neu definiert hat.
Was jedoch wie ein evolutionärer Prozess erscheinen mag, in dem neue Technologien dazu bestimmt sind, die vorherigen zu ersetzen, ist in Wirklichkeit ein viel weniger linearer Weg: Es gibt und wird wahrscheinlich noch lange Szenarien geben, in denen jede der drei Technologien das sein wird nur eine anwendbar, andere, in die sie sich integrieren müssen, und jede wird ihren eigenen Raum finden.
Nicht alle Workloads sind in Containern portierbar: In einigen Fällen wäre es erforderlich, die Anwendung neu zu entwerfen und neu zu schreiben. Es ist nicht sicher, ob dies immer möglich ist, daher gibt es immer noch Situationen, in denen virtuelle Maschinen eine Systemsteuerung oder Flexibilität ermöglichen, die sie unverzichtbar machen.
Containers and Serverless Use Cases
Behälter finden ihren idealen Einsatz in komplexen Anwendungen, die ein hohes Maß an Kontrolle über die Betriebsumgebung erfordern, möglicherweise mit langen Verarbeitungszeiten, und die sich gleichzeitig für die Implementierung in einer containerisierten Umgebung anbieten.
Auch wenn die Ressourcennutzung weniger effizient ist als bei einem serverlosen Ansatz, sind die Performances im Durchschnitt besser, da zumindest der erste Container immer aktiv ist und nicht neu instanziiert werden muss.
Design, Entwicklung und Verwaltung können einfacher sein, da das Vorhandensein gemeinsamer Frameworks und Standards eine Orchestrierung zwischen Clouds verschiedener Anbieter mit viel einfacherer Skalierung als bei virtuellen Servern ermöglicht.
Umgekehrt erfordern Änderungen an einzelnen Funktionen in Containern die Erstellung und Bereitstellung eines neuen Images, mit Verlängerung der Release-Zeiten und der Möglichkeit von Fehlern. Das Wachstum der Anzahl der Instanzen als Reaktion auf die Lasterhöhung führt zu Schwierigkeiten bei der Überwachung und möglicherweise zu Performance-Problemen, da die Wachstumskapazität immer durch die Geschwindigkeit der Komponenten begrenzt ist, die die Datenpersistenz gewährleisten.
Ein typisches Anwendungsbeispiel kann eine große E-Commerce-Site sein, die aus zahlreichen Teilen wie der Preisliste, Lagerverwaltung, und Zahlungen, die jeweils in einen Container gepackt werden können, für den Ausführungszeit und Speicherbeschränkungen kein Problem darstellen.
Der serverlose Ansatz kann in einem Microservices-Kontext und in Szenarien wie dem ideal sein IoT, wobei bestimmte Funktionen nur aufgerufen werden müssen, wenn bestimmte Ereignisse eintreten, und nicht Teil eines Always-on-Dienstes sein müssen.
Da es sich um ein reines Pay-per-Use-Modell handelt, ermöglicht es eine Kostenoptimierung, insbesondere in Fällen, in denen es schwierig ist, mit einer a priori-Dimensionierung fortzufahren oder die zu bewältigende Last vorherzusagen.
Die Designschwierigkeiten und das Fehlen von Standards, die in vielen Fällen das Problem des Vendor Lock-in bestimmen, stellen immer noch eine starke Einschränkung des Einsatzbereichs dar.
Zusammenfassung
Zusammenfassend lässt sich sagen, dass keine Technologie im absoluten Sinne besser ist als die andere: Jede entspricht spezifischen Anforderungen. Sie können nebeneinander bestehen und bei Bedarf in einem einzigen Projekt integriert werden. Entscheiden Sie sich daher am besten nicht für einen vorweg festgelegten Weg für die Entwicklung Ihrer Anwendungen, sondern beginnen Sie mit einer sorgfältigen Analyse der Eigenschaften und Anforderungen, um die am besten geeignete Architektur auszuwählen.
