Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 12 Min.

Wie Cloud Native möglich wurde und was Container damit zu tun haben Die bessere Cloud?


Linux Magazin Sonderheft - epaper ⋅ Ausgabe 1/2019 vom 21.02.2019

Gerade sprach die Welt noch von Clouds und Open Stack – plötzlich stehen stattdessen Container im Fokus. Das Linux-Magazin zeigt, wie Container und das Cloud-Native-Paradigma zusammenhängen.


Artikelbild für den Artikel "Wie Cloud Native möglich wurde und was Container damit zu tun haben Die bessere Cloud?" aus der Ausgabe 1/2019 von Linux Magazin Sonderheft. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin Sonderheft, Ausgabe 1/2019

Grund zur Freude haben jetzt jene, denen das Buzzword „Cloud“ schon immer zu wolkig war. Denn mittlerweile kommt der Begriff merklich seltener vor als noch vor ein paar Jahren. Heute sind Cloud-Native-Anwendungen der neue „heiße Scheiß“. Sie selbst rangieren im Fahrwasser der Containervirtualisierung. Container verändern die IT-Industrie mindestens so stark wie zuvor Cloud Computing – nur weniger offensichtlich. ...

Weiterlesen
epaper-Einzelheft 11,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin Sonderheft. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 1/2019 von Alles zu seiner Zeit. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Alles zu seiner Zeit
Titelbild der Ausgabe 1/2019 von Container unter oder über Open Stack Zusammenspiel. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Container unter oder über Open Stack Zusammenspiel
Titelbild der Ausgabe 1/2019 von Container-Management:Schlau verwaltet. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Container-Management:Schlau verwaltet
Titelbild der Ausgabe 1/2019 von Rumpf-Betriebssysteme: Nachwuchshelden. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Rumpf-Betriebssysteme: Nachwuchshelden
Titelbild der Ausgabe 1/2019 von Containersicherheit: Die Krux mit den Lecks. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Containersicherheit: Die Krux mit den Lecks
Titelbild der Ausgabe 1/2019 von Istio: Bombensicher. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Istio: Bombensicher
Vorheriger Artikel
Alles zu seiner Zeit
aus dieser Ausgabe
Nächster Artikel Container unter oder über Open Stack Zusammenspiel
aus dieser Ausgabe

Grund zur Freude haben jetzt jene, denen das Buzzword „Cloud“ schon immer zu wolkig war. Denn mittlerweile kommt der Begriff merklich seltener vor als noch vor ein paar Jahren. Heute sind Cloud-Native-Anwendungen der neue „heiße Scheiß“. Sie selbst rangieren im Fahrwasser der Containervirtualisierung. Container verändern die IT-Industrie mindestens so stark wie zuvor Cloud Computing – nur weniger offensichtlich.

Fakt ist: Was viele heute unter Cloud Native verstehen, hätte ohne Containervirtualisierung gar keine Chance. Beide Konzepte gehören untrennbar zusammen. Aber im Hintergrund spielt sie dann doch auch wieder mit, die Cloud. Denn ohne die fundamentalen Design-Prinzipien der Cloud wären Kubernetes & Co. nicht möglich.

Dieser Artikel stellt die wichtigsten Fragen aus dem Blickwinkel der Infrastruktur. Warum reden jetzt alle von Containern? Worauf müssen Anbieter achten, wenn sie Umgebungen für Container und Cloud-Native-Apps gut betreiben wollen? Antworten liefert dieser Text.

Vom Ursprung der Cloud

Eingangs schadet es nicht, sich mit dem historischen Werdegang der Idee des Cloud Computing etwas genauer zu beschäftigen. Vor dem Aufkommen der Cloud-Idee hatte es seit Jahrzehnten keine radikalen Umwälzungen mehr gegeben. Man begnügte sich mit den Konzepten, die seinerzeit bereits wirkten, als seien sie immer da gewesen.

Entsprechend war IT eher statisch: Große Setups entwickelte man am grünen Tisch und baute sie anschließend genau so auf, wie es der Plan vorsah. Weil das Setup sich in den meisten Fällen nicht mehr großartig änderte, waren Faktoren wie etwa die Automation der Installation keine großen Themen. Einmal ganz abgesehen davon, dass es damals auch nicht viele gut funktionierende Automatisierungslösungen gab.

Die Idee des Cloud Computing ist tief im akademischen Umfeld verwurzelt. Open Stack[1] , bis heute die Cloudlösung par excellence, entstammt etwa den Bedürfnissen der NASA. Wissenschaftler orderten für ihre Experimente wieder und wieder Hardware, die nach Abschluss der Versuche ungenutzt herumstand.

Das war nicht effizient, und so suchten sie nach Möglichkeiten, Hardware zentral verwaltbar zu machen. Nebula, das später das Fundament für Open Stack Nova wurde, bot aus der Sicht des Anbieters erstmals einen Weg, Hardware zentral zu verwalten und die verfügbaren Ressourcen bei Bedarf dynamisch zuzuweisen – gestückelt oder auch komplett.

Als dieser Stein erst mal im Rollen war, gab es praktisch kein Zurück mehr auf dem Weg in die Cloud. Klar, zentrale Ressourcenverwaltung ist toll. Aber aus Sicht des Anbieters wäre es noch viel besser, könnten die Kunden sich die benötigten Ressourcen gleich selbst zusammenklicken. Schnell wurde klar: Das Cloudkonzept funktioniert nur, wenn die Anbieter diese umfassenden Möglichkeiten zur Selbstbedienung verwirklichen.

Bis die vorhandene Technik so angepasst war, dass sie diese Anforderung bedienen konnte, vergingen jedoch mehrere Jahre. Die feilgebotenen Lösungen der verschiedenen Anbieter konnten sich dann allerdings sehen lassen – bei allen gängigen Clouds lassen sich heute alle Funktionen über APIs steuern. Falls es, wie bei Open Stack in Form von Horizon, ein GUI gibt, spricht dies ebenfalls mit den APIs.

Komplexe Probleme

Als besonders steinig erwies sich der Weg in die Cloud bei bestimmten physischen Ressourcen – namentlich Netzwerk und Storage. Mit den Konzepten des Software Defined Networking (SDN) und Software Defined Storage (SDS) existieren mittlerweile gut funktionierende Ansätze, die eben jene physischen Ressourcen aus der Cloud heraus verwaltbar machen.

Sie brechen, das sorgte für einiges Aufsehen, radikal mit klassischen IT-Konventionen: Netzwerke müssen plötzlich nicht mehr der Stern-oder Baum-Topologie folgen, und die klassischen Storage-Geräte in Kühlschrankgröße wichen COTSLösungen (Components off the Shelf) wie Ceph, was deutlich günstiger war und im Cloudkontext meistens auch noch besser funktionierte.

Den vorläufigen Höhepunkt in Sachen Cloud bilden die Orchestrierer, die die Automatisierer innerhalb der Cloud ergänzen. Ist ein Server erst mal eine rein virtuelle Ressource und keine Blechkiste mehr, lässt sich seine Bereitstellung umfassend automatisieren. Ein Kernkonzept von Cloudumgebungen ist schließlich die Idee, dass alles, was sich automatisieren lässt, auch zuverlässig automatisiert wird und dem Admin oder dem Kunden keine Mühe mehr bereitet.

Die APIs, die fixer Bestandteil jeder Cloudlösung sind, helfen dabei ungemein: Sie nehmen auf der einen Seite Befehle anhand eines definierten Protokolls entgegen. Dann führen sie die vom Nutzer beauftragte Arbeiten durch. Und schließlich liefern sie die Ressourcen aus, die der Nutzer bestellt hat. Das alles passiert automatisch und ohne dass irgendein Mensch etwas tun müsste.

Worin die wirkliche technische Errungenschaft der Cloud denn nun eigentlich besteht, darüber werden die Gelehrten noch lange streiten. Klar ist aber, dass die Cloud in den Köpfen vieler Admins und IT-Manager zum Umdenken geführt hat. Indem sie die Möglichkeit zur Selbstbedienung mit einer zentralisierten Ressourcenverwaltung und umfassender Orchestrierung kombiniert, ebnet sie einer neuen Herangehensweise den Weg.

Unzulänglichkeiten

Wer das Cloudprinzip weniger als technische Umsetzung und mehr als Etablierung eines völlig neuen Betriebskonzepts betrachtet, erkennt auch schnell, warum Hype-Lösungen wie Open Stack ihren auf Containern basierten Konkurrenten nach relativ kurzer Zeit schon wieder weichen mussten.

Denn so schön die Orchestrierung und zentrale Ressourcenverwaltung auch sein mögen, in den ersten konkreten Implementierungen von Clouds sahen Admins sich auch handfesten Problemen gegenüber. Eine dieser Widrigkeiten war der gewaltige Overhead, den klassische Clouds in aller Regel mit sich bringen.

Spricht man etwa in einer Open-StackUmgebung von Virtualisierung, meint der Begriff in den meisten Fällen die klassische Vollvirtualisierung, unter Umständen garniert mit paravirtualisierten Treibern. Im Klartext wird also ein virtuelles System als Prozess auf einem physischen System betrieben. Dabei bildet der Emulator einen kompletten Computer ab, Bios und andere relevante Funktionen inklusive.

Das hat in der Praxis vielerlei Nachteile: Schon für die Emulation von Bios & Co. braucht der Emulator Ressourcen, die dann weder dem physischen noch dem Gastsystem für Payload-Aufgaben zur Verfügung stehen. Zudem ist jeder virtuelle Server ein komplettes System, das wie ein echter Server auch regelmäßig gewartet werden muss. Sicherheitsupdates und viele andere Aufgaben stehen also häufig an.

So fortschrittlich die Idee mit der Cloud mit Blick auf die grundlegende Infrastruktur auch ist – in der virtuellen Schicht der Cloud, wo Kunden ihre Dienste buchen, hatte sich auch nach der Cloudrevolution erst mal sehr wenig geändert.

Nicht länger in VMs denken

Teilweise im Fahrwasser der Cloud und teilweise als Kampf für eine sehr nützliche Technik tauchten vor ein paar Jahren Container plötzlich wieder auf. Das ist auch und maßgeblich Docker zu verdanken. Das Problem des massiven Overhead, der durch Vollvirtualisierung entsteht, ist nämlich auch den Docker-Entwicklern früh aufgefallen. Als man bei Docker gerade in die Gänge kam, fristeten Container unter Linux ein eher trauriges Dasein: LXC war nach einer kurzen Hochphase wieder in der Versenkung verschwunden, und kommerzielle Alternativen wie Open VZ hatten sich in Masse nie durchgesetzt.

Abbildung 1: KVM hat als De-facto-Ablösung von Xen den Grundstein dafür gelegt, dass Virtualisierung in Linux zur ubiquitären Technik wurde.


Als Docker auf den Markt drängte, hatten sich die Voraussetzungen für den Erfolg von Containern fundamental verbessert. Denn zusätzlich zur eigentlichen Virtualisierungslösung gab es nun Komponenten, die Container effektiv nutzbar machten. Plattformen wie Open Stack können schließlich jede Art von Virtualisierung für ihre Zwecke nutzen. Keinesfalls ist es unbedingt notwendig, Virtualisierung nur in Form von KVM-(Abbildung 1) oder Xen-VMs zu verwenden. Und so schickten sich die gerade von den Toten wiederaufstandenen Container an, VMs einfach den Garaus zu machen.

Weniger Overhead, mehr Effizienz

Das hat nichts damit zu tun, dass Admins Container lieber mögen als vollvirtualisierte Systeme. Stattdessen ist mit einem Container eine Reihe von Vorteilen verbunden, die gerade bei großen Umgebungen der Masse wegen merklich ins Gewicht fallen. Zunächst ist es bei Containern so, dass der Overhead entfällt, der für das Emulieren etwa des Bios notwendig ist. Der Ressourcenverbrauch eines Containers ist also deutlich kleiner als der einer kompletten VM.

Abbildung 2: Als Bestandteil einer CI/ CD-Implementierung spielen Lösungen wie Jenkins eine große Rolle. Sie erlauben es, Container-Images automatisiert zu bauen. Ein manueller Eingriff des Nutzers ist nicht nötig.


Zudem ist es leichter, Container zu warten. Heute gibt es viele Continuos-Integration-/ Continuos-Delivery-Umgebungen (CI/CD) wie Jenkins ([2] , Abbildung 2), die Container für Docker sowie andere Systeme auf Knopfdruck ausgeben. Möchte ein Entwickler eine Applikation vertreiben, integriert er sie in die jeweilige CI/ CD-Lösung, setzt den Bauprozess in Gang – fertig ist der Lack.

Hinzu kommt, dass Container-Images meist viel kleiner sind als ihre vollvirtualisierten Gegenstücke. Kein Wunder: Der Linux-Kernel etwa, auf den ein Container anders als eine VM verzichten kann, bringt schon einige Megabyte mit. Hinzu kommen Komponenten wie ein Bootloader, die in einem Container nutzlos sind, bei einer vollvirtualisierten VM aber nicht fehlen dürfen.

Leichtere Wartung

Außerdem gestaltet sich auch die Wartung im laufenden Betrieb eines Containers leichter als bei vollvirtualisierten VMs. Denn wer ohnehin auf eine CI/ CDLösung für das Erstellen seiner Container setzt, der muss sich gar keine Gedanken darüber machen, einzelne Container zu aktualisieren: Er baut den jeweiligen Container einfach neu und tauscht den laufenden Container aus.

Dass das Handling von Containern leichter ist als jenes von Abbildern für virtuelle Maschinen, liegt zudem auf der Hand: Letztere müssen etwa bootfähig sein, damit sie in einer Cloud überhaupt zum Einsatz kommen können. Container für Docker hingegen müssen lediglich die Formatvorgaben von Docker erfüllen, das war’s schon.

In Summe gibt es also viele gute Gründe dafür, sich weniger mit VMs und mehr mit Containern zu beschäftigen. Die sind am Ende ja auch bloß eine sehr spezielle Spielart der Virtualisierung, reichen für die meisten Zwecke aber völlig aus. Wenn es nur darum geht, eine spezifische Applikation sinnvoll zu virtualisieren, stehen Container ihren vollvirtualisierten Pendants in kaum einer Hinsicht nach.

Schnittpunkt der Innovationen

Die beiden Grundzutaten für den Cloud-Native-Ansatz sind damit vorhanden – ein Selbstläufer war er deshalb aber noch nicht. Dafür, dass das Prinzip zu fliegen begann und schnell eine große Fangemeinde um sich scharte, sorgten letztlich große Firmen wie Google. Was war passiert?

Zwei funktionierende Konzepte für Infrastructure as Code und die leichtfüßige Virtualisierung waren zusammengekommen. Aber die großen Cloudumgebungen wie Open Stack waren mit Containern nie richtig warm geworden. Bis heute existiert für Open Stack Nova beispielsweise kein Modul, das die effiziente Nutzung von Docker-Containern als VMs direkt in Open Stack ermöglicht (Abbildung 3). Meist behilft man sich und nutzt die Container in vollvirtualisierten VMs – über Sinn und Unsinn dieses Ansatzes lässt sich jedoch streiten.

Einen anderen Ansatz verfolgte Google. Die Entwickler dort stampften kurzerhand eine Lösung aus dem Boden, die auf Containern basiert, aber viele Vorteile von Clouds ebenfalls nutzbar macht – etwa APIs (Abbildung 4), um bestimmte Container gezielt zu starten oder zu stoppen. Kubernetes[3] trat einen Siegeszug an, der jenem von Open Stack frappierend ähnelt, was durchaus bemerkenswert ist. Denn auf der Feature-Seite bietet Kubernetes an vielen Stellen (ganz bewusst) viel weniger als Open Stack.

Während Open Stack etwa strikt darauf achtet, mandantenfähig zu sein, ist der empfohlene Ansatz bei Kubernetes eher, für die einzelnen Kunden einzelne Kubernetes-Setups zur Verfügung zu stellen. Auch in Sachen SDS und SDN hinkt Kubernetes Open Stack merklich hinterher. Der Freude an der Kubernetes-Nutzung tut das bei den meisten Nutzern keinen Abbruch – im Gegenteil: Viele Admins beschäftigen sich bevorzugt mit Kubernetes, eben weil es deutlich weniger komplex ist als Open Stack (Abbildung 5).

Kubernetes als Triebfeder für Cloud Native

Welchen Anteil Kubernetes und ähnliche Lösungen daran haben, dass sich das Cloud-Native-Konzept fortentwickelte und immer stärker durchsetzt, lässt sich schnell zusammenfassen. Die Lösung beschreibt sich selbst bekanntlich als Flottenmanager, verspricht also, Flotten von Containern in einer physischen Umgebung zu verwalten. Mit Kubernetes war es also zum ersten Mal möglich, nicht nur virtuelle Maschinen zu starten, sondern sie über die verschiedenen APIs der Cloudumgebung auch in einen logischen Zusammenhang zu stellen – der der Cloud ebenfalls bekannt ist.

Die Pods in Kubernetes sind so gesehen ein Segen: Sie erlauben es, zwischen einer beinahe beliebig großen Zahl von Containern Abhängigkeiten zu definieren, die die Containerumgebung garantiert. Die Container eines Pod etwa laufen stets auf demselben Rechner – der Nutzer bekommt diese Garantie, ohne etwas Besonderes dafür zu tun.

Die große Neuerung von Flottenverwaltern für Docker & Co. besteht exakt in der Möglichkeit, solche Abhängigkeiten logisch auszudrücken. Damit war der Weg für umfangreiche Cloud-Native-Konzepte frei. Doch warum braucht eine Cloud-Native-Applikation eben diese Möglichkeit? Hier hilft ein Blick in die Welt der agilen Entwicklung – denn letztlich sind Cloud-Native-Apps viel mehr als nur eine technische Neuerung.

Den Elefanten in Scheiben schneiden

Dass die Idee der agilen Entwicklung ihr Für und Wider hat, steht außer Frage – doch selbst die größten Kritiker des Ansatzes verbannen ihn heute nicht mehr pauschal. Ein Kernprinzip agilen Arbeitens lautet, die anstehende Arbeit in so viele kleinere Einheiten wie möglich zu zerteilen, die dann nacheinander abgearbeitet werden.

Die Idee ist klar: Ein auf diese Weise strukturierter Prozess ist flexibel und erlaubt es, an jeder Stelle im Fertigungsvorgang korrigierend einzugreifen. Finden die Entwickler in agil entwickelter Software etwa einen Bug, lässt der sich oft sehr einfach und ohne große Auswirkungen auf andere Teile reparieren.

Der konventionelle Entwickleransatz, der über viele Jahre hinweg als der Quasi-Standard galt, steht dazu diametral im Widerspruch. Wohl die meisten Admins haben bereits am eigenen Leib erfahren, was das konkret im Alltag bedeutet: Im stillen Kämmerlein programmieren Entwickler vor sich hin. Nach einiger Zeit werfen sie dem Betriebsteam dann eine neue Release vor die Füße, die es möglichst zeitnah ausrollen soll.

Weil die Zahl der Änderungen riesig ist, Tests aber nur innerhalb des Entwicklerteams stattgefunden haben, ist die Wahrscheinlichkeit groß, dass dann beim Rollout etwas schiefgeht. Schlimmer noch: Weil die Admins an der Entwicklung des Produkts kaum beteiligt waren, wissen sie auch nicht, was zu tun ist, wenn mal etwas schiefgeht. Kaum ein Admin, der an einem solchen Riesen-Rollout schon einmal beteiligt war, wünscht sich entsprechende Aktionen erneut.

Abbildung 3: Open Stack war eine der ersten Lösungen am Markt, die Automation, Orchestrierung und Selbstbedienung boten – aber es ist auch sehr komplex und damit nicht einfach zu verwalten.


Agil und Cloud Native

Der agile Ansatz, der im IT-Kontext stets auch mit Devops verbunden ist, hilft hier kolossal. Er sieht vor, das entwickelte Produkt so in logische Komponenten aufzuteilen, dass diese eigenständig voneinander existieren und entwickelt werden können. Bis zum Aufstieg von Containern in Kombination mit den Flottenmanagern hätte man Software so zwar grundsätzlich auch bauen und betreiben können, doch zumindest Letzteres wäre ein ausgesprochen mühsames Unterfangen gewesen.

Wer etwa eine Applikation in fünf Komponenten und mithin fünf virtuelle Systeme aufgeteilt hätte, hätte dann fünf komplette Server am Hals, die zu warten wären. Vielen Admins war da aus verständlichen Gründen eine monolithische App viel lieber, die dafür auch nur ein System benötigte.

Genau dieses Problem haben Container jedoch aus dem Weg geräumt: Die sind – wie bereits beschrieben – per CI/ CDUmgebung problemlos automatisch zu bauen, sie verbrauchen nicht annähernd so viel Platz wie eine komplette VM und kommen auch mit wesentlich weniger Ressourcenbedarf daher. Und weil Cloud-Native-Apps darauf ausgelegt sind, verteilt zu laufen, passen sie einerseits ganz hervorragend zur Idee der Containervirtualisierung, andererseits lassen sie sich, anders als ihre Vorgänger, problemlos in Flotten verwenden.

Somit: Cloud Native ergibt sich als Entwicklungskonzept automatisch, wenn man die Orchestrierung und Automatisierung aus Clouds mit der Flexibilität kombiniert, die Containervirtualisierung bietet – um das große Ziel zu erreichen, agile Prozesse zu ermöglichen und Devops überhaupt erst möglich zu machen. Dass sich Cloud-Native-Apps so rasant durchsetzen, liegt gerade daran, dass sie Devops-Workflows viel leichter ermöglichen, als es bei konventionellen Apps überhaupt denkbar ist.

Was muss ein Anbieter also tun, um seinen Kunden die Möglichkeit zu bieten, Cloud-Native-Anwendungen zu betreiben? Offensichtlich empfiehlt sich der Einsatz von Flottensteuerern wie Kubernetes oder Docker Swarm. Denn die liefern den Kleber, um aus agil entwickelten App-Komponenten eine gut klingende App-Sinfonie zu komponieren.

Wer sich gerade erst mit dem System zu beschäftigen beginnt, sollte tunlichst auf eine bestehende Lösung setzen, statt ein Eigengebräu zu beginnen. In Kubernetes, Swarm und vielen anderen existierenden Lösungen steckt mittlerweile die Erfahrung von mehreren Jahren, und die meisten tatsächlichen Probleme haben jene Umgebungen bereits gelöst. Zumindest als Anhaltspunkte sind sie also in jedem Fall geeignet.

Abbildung 4: Open Stack ist über die Jahre zu einer Sammlung verschiedener Dienste herangewachsen, die Restful-APIs nutzen.


Wer seinen Kunden mehr liefern möchte als reines Flottenmanagement, für den steht dafür mittlerweile ein reiches Füllhorn verschiedener Angebote bereit. Da gibt es zum Beispiel Ansätze wie Open Shift, die die Container-Idee weiter perfektionieren und sie mit vielen Komponenten aus dem großen Cloud-Native-Baukasten kombinieren. So ermöglichen sie Software-as-a-Service-Lösungen oder auch Serverless Computing.

Bei vielen solchen As-a-Service-Angeboten und auch beim Serverless Computing spielt der Cloud-Native-Ansatz aktuell eine wichtige Rolle. Der Grund dafür ist einfach, dass sein Entwicklungsmodell den konventionellen Ansätzen so gnadenlos überlegen ist.

Abbildung 5: Kubernetes kombiniert die verschiedenen Konzepte der Cloud mit der sehr leichtfüßigen Containervirtualisierung.


Was die Zukunft bringt

Der Artikel hat gezeigt, dass Cloud Computing, Container-VMs sowie der Cloud-Native-Ansatz im Grunde drei Bausteine sind, um agile Ansätze wie Scrum oder das Devops-Prinzip im Alltag der IT zu verankern. Ohne die Cloud und ihre Kernelemente Orchestrierung und Selbstbedienung hätte der Ansporn gefehlt, Containervirtualisierung zum massentauglichen Produkt zu machen.

Docker, das erstmals ein einfaches Format für fertige Container definierte und um dieses Format herum ein gesamtes Ökosystem baute, hat viel mehr erreicht, als nur Container zu propagieren: Wegen Docker und der Alternativen, die sich – wie in der Open-Source-Welt üblich – bald etabliert haben, sind Container heute eine weithin anerkannte Virtualisierungstechnik und fristen nicht etwa ihr Dasein als unscheinbares Nischenprodukt.

Der Cloud-Native-Ansatz nutzt den technischen Unterbau und bettet ihn zugleich in ein größeres Gesamtkonzept ein, das eine zuverlässigere und deutlich wendigere IT verspricht. Und noch ist die Entwicklung in dieser Hinsicht nicht am Ende.

Gerade erst machte etwa Amazon auf sich aufmerksam, als es Firecracker vorstellte – eine leichtgewichtige Alternative zu KVM, also einen echten Vollvirtualisierer, der trotzdem nicht mit den Nachteilen von Qemu & Co. daherkommen soll. (Ausführlich auf Amazons Firecracker geht ein weiterer Artikel in diesem Linux-Magazin ein.)

Auch das ist so eine Eigenheit der Entwicklung im Dunstkreis des Cloud-Native-Prinzips: Nicht nur die Apps in der Cloud werden modularer und lassen sich einfacher warten, sondern auch der Stack im Unterbau ist selbst extrem flexibel. Findet sich für eine seiner vielen Komponenten eine bessere Alternative, dann kann sie der Admin meist einfach austauschen – oft sogar während des laufenden Betriebs.

Am Ende trägt die Cloud auf diese Weise sowohl direkt wie indirekt dazu bei, dass IT langfristig absehbar besser wird. Und das ist es, was aus Sicht von Unternehmen, die IT-Infrastruktur betreiben, letztlich zählt. Man darf also gespannt sein, was die Zukunft bringt.

Infos

[1] Open Stack: [https://www.openstack.org]

[2] Jenkins: [https://jenkins.io]

[3] Kubernetes: [https://kubernetes.io]


© van Kruk , 123RF