Die IT-Abteilungen müssten sich jetzt darauf vorbereiten, den Schritt zu Container-Umgebungen in den nächsten Jahren zu vollziehen. So lautet die deutliche Ansage von Marc Kleff, Director Solutions Engineering beim Datenspeicher-Spezialisten NetApp. Langfristig rechnet er damit, dass Container den Grossteil der
Anwendungen abdecken werden.

Die sogenannte Containerisierung gilt als einer der bedeutendsten Umbrüche in der IT-Welt: gekapselte Anwendungen, die unabhängig voneinander ausgeführt werden – ganz egal, wo sie sich gerade befinden. Das erleichtert vor allem den IT-Abteilungen die Arbeit ungemein. So stehen Unternehmen in Sachen Digitalisierung momentan unter einem enormen Erfolgsdruck, der vor allem die Anforderungen an die IT-Abteilungen hochschraubt. Mit Containern lassen sich neue Anwendungen und Dienste schnell und flexibel zur Verfügung stellen.

Doch trotz aller Vorteile der Container-Technologie, zum Standard gehören sie in den meisten Unternehmen bislang nicht. Stephan Michard, Senior Systems Engineer bei Dell Technologies, bestätigt dies: «Unsere Gespräche mit Unternehmen zeigen, dass viele noch nicht in der Lage sind, Container-Applikationen zu betreiben.»

Die Containerisierung spielt derzeit vor allem in der Planung neuer Software-Systeme eine grosse Rolle, so die Erfahrung von Simon Fleischer, Teamleiter Software Engineering bei der IT-Beratung Consol. Architekten und DevOps-Ingenieure würden ihren Einsatz häufig in der Konzeptionsphase erwägen. Allerdings müssten Container nicht in jeder Umgebung die beste Wahl sein und oft sei es wirtschaftlich nicht sinnvoll, jedes Altsystem in Container umzuziehen. «Man kann also sagen, dass Container längst ‹angekommen› und reif für den Produktiveinsatz sind. Von einer flächendeckenden Durchdringung zu sprechen, wäre jedoch übertrieben.» Aber: «Viele Unternehmen nutzen bereits Container und wissen es gar nicht, denn viele Produkte aus dem Bereich Software as a Service setzen im Hintergrund auf Containern auf.»

Zu einem ähnlichen Ergebnis kommt die aktuelle Studie «Container in der IT und ihr Potenzial in deutschen Unternehmen» des IT-Dienstleisters Cronon und der Analysten von Techconsult: Für 38 Prozent der Unternehmen, die Container im Einsatz haben oder dies planen, stellt das mangelnde Know-how über die Technologie ein Hemmnis dar und erschwert die Implementierung, «weshalb in solchen Fällen eher auf altbewährte und sogar veraltete Konzepte zurückgegriffen wird». Die Vorteile von Containern haben die Unternehmen aber erkannt: 78 Prozent halten es für wahrscheinlich, dass Container-Technologie künftig ein fester Bestandteil ihrer IT-Landschaft sein wird.

«Technisch gesehen sind Container eine logische Weiter­entwicklung diverser Innovationen im Linux-Kernel wie Cgroups oder Namespaces über das letzte Jahrzehnt. Dazu kommt die Etablierung von Kubernetes (vgl. Kasten S. 16) und einem ganzen Ökosystem von Projekten», sagt Björn Brundert, Principal Solution Engineer Application Platforms beim Cloud- und Virtualisierungs-Spezialisten VMware. Bei Kubernetes handelt es sich um ein ursprünglich von Google entwickeltes und inzwischen als Open Source zur Verfügung stehendes Tool zur Automatisierung der Bereitstellung, Skalierung und Ver­waltung von Container-Anwendungen. Kubernetes hat sich mittlerweile als Standard für die Verwaltung von Containern etabliert.

Während Kubernetes und Containerisierung grosse Vorteile mit sich bringen können, braucht deren Realisierung, wie es bei jeder neuen Technologie der Fall ist, jedoch ihre Zeit. Der technische Reifegrad, das Ökosystem an Tools und nicht zuletzt auch das vorhandene Wissen, zum Beispiel bei den Entwicklern, sind hier nur einige Faktoren. Kubernetes ist zwar eine komplexe Software, die es Nutzern einfacher macht, verteilte Systeme zu bauen – «aber nicht jede Anwendung eignet sich hierfür beziehungsweise die Verwendung kommt erst in einem neueren Release von Kubernetes infrage», schränkt Brundert ein. Mit zentralen Updates alle drei Monate schaffe Kubernetes jedoch zunehmend neue Möglichkeiten und decke neue Anwendungsfälle ab.

Auch laut Kleff von NetApp hat sich Kubernetes als Quasi-Standard im Bereich der Container erfolgreich durchgesetzt: «Die Lösung ist komplex, bietet aber auch einen sehr grossen Mehrwert und eine hohe Entwicklungs­geschwindigkeit. Da viele Alternativen nicht mithalten konnten, wurden sie bereits von Kubernetes verdrängt.»

Dabei ist Kubernetes allerdings kein Allheilmittel und schon gar keine Eier legende Wollmilchsau: Zwar nimmt Kubernetes den DevOps-Teams die meiste Arbeit ab, wenn es um Orchestrierung und Management geht, aber einen kompletten Überblick erhält man erst durch ein vernünftiges Monitoring. Hierfür eignen sich etwa die Tools Prome­theus und Grafana. Letztlich erfordert ein erfolgreiches Container-Management aber ein ganzes Potpourri unterschied­licher Werkzeuge, zum Beispiel für den sicheren Zugriff auf Datenbanken oder andere Unternehmensservices.

Früher war vor allem das Container-Verwaltungs-Tool Docker beliebt. Auch wenn dessen Bedeutung schwindet, so ist es in den Unternehmen doch weiterhin vertreten: «Gerade beim Evaluieren neuer Software und solange es sich nicht um eine reine Microsoft-Umgebung handelt, gehört Docker für Entwickler zum Standard», berichtet Frank Haumann. Er ist Partner beim Cloud-Dienstleister Red Reply. Vermehrt sehe er Docker in produktiven Umgebungen und bei Kunden, die versierter im Umgang mit der CI/CD-Pipeline (Continuous Integration and Continuous Delivery) sind. Doch je grösser die Installationen seien, desto häufiger treffe man auf das Container-Management-Framework Kubernetes, «das sich verstärkt zum Standard entwickelt und ältere Frameworks wie Cloud Foundry, Apache Mesos oder Docker Swarm ablöst». Haumann unterstreicht: «Ohne Kubernetes sind Lösungen mit mehreren Hundert Containern nicht mehr wirtschaftlich und sicher zu betreiben.» Kubernetes bringe aber auch eine Komplexität mit sich, die Operations-Teams vor Herausforderungen stelle. Aus diesem Grund wanderten viele Kubernetes-Installationen als Managed Kubernetes in Private oder Public Clouds.

Häufig hört man, dass Container sogar virtuelle Maschinen (Virtual Machines, VMs) obsolet machen. Virtualisierung und Container zu vergleichen, ähnelt jedoch dem sprichwörtlichen Vergleich von Äpfeln und Birnen. VMs stellen (virtualisierte) Hardware bereit. «Das eröffnet Unternehmen ab ‹Oberkante Hardware› alle Freiheiten, zum Beispiel bei der Wahl des Betriebssystems», erklärt Thomas Franz. Er leitet den Technologiebeirat beim IT-Dienstleister Adesso. Container-Umgebungen hingegen arbeiteten auf einem Betriebssystem, das für eine bestimmte Hardware-Architektur konzipiert sei. Diese unterschiedlichen Freiheitsgrade hätten Folgen, positive wie negative. Deswegen, so Franz weiter, könne ein Container nicht automatisch auf jeder Hardware-Architektur oder jedem Betriebssystem betrieben werden. Dieser Nachteil spiele in der Praxis jedoch seltener eine Rolle, «da häufig einheitliche Betriebssysteme und Hardware-Architekturen genutzt werden». Für Projekte im IoT-Umfeld sei dies allerdings schon relevanter. So sei ein Container zum Beispiel für einen Intel-basierten Server nicht ohne Weiteres auf einem Raspberry Pi einsetzbar.

Viele Anwendungen, die früher in virtuellen Maschinen liefen, lassen sich grundsätzlich in einen Container verschieben. Wenn man aber irgendwelche existierenden Applika­tionen ohne eine Anpassung in Containern betreibt, dann fügt das diesen Applikationen erst einmal keine neuen Funk­tionen hinzu. Anders ausgedrückt: «Eine nicht skalierbare Single-Instance-Applikation ist auch nach der Containerisierung keine Cloud-native Scale-out-Applikation.»

Es gibt laut Brundert von VMware diverse Applikationen, die sich für eine einfache Umwandlung in einen Container eignen. Die technische Komplexität müsse aber teilweise sehr individuell betrachtet werden. Als Beispiel nennt er Anwendungen, die etwa über keine integrierten Backup-Mechanismen verfügen und daher von externen Backup-Tools abhängig sind. Weitere Fragen seien, ob eine Applikation überhaupt auf dem Betriebssystem unterstützt werde, das der Container-Runtime zugrunde liegt. Oder wie werden Updates an der Applikation gemacht, nachdem sie containerisiert wurde? All diese und noch etliche andere Themen müssten auf jeden Fall be­rücksichtigt werden, wenn eine Migration erfolgreich sein soll.

IT-Abteilungen sollten also die beiden Technologien – sprich virtuelle Maschinen auf der einen und Container auf der anderen Seite – nicht gegeneinander ausspielen: Es sei kein Oder, sondern ein Und, wie Stephan Michard von Dell betont. «Beide Technologien stellen verschiedene Möglichkeiten der Virtualisierung dar und haben ihre jeweilige Berechtigung und ihre Vorzüge – je nach den Anforderungen, die an eine Applikation gestellt werden.» Für virtuelle Maschinen existierten bewährte Management- und Orches­trierungs-Tools und so lange es keine extremen Anforderungen an eine hohe Skalierbarkeit oder sehr kurze Entwicklungszyklen gebe, liessen sich Applikationen auch gut über virtuelle Maschinen bereitstellen.

Felix Grundmann zufolge, Head of Product Management beim Provider Ionos, gibt es durchaus auch Gründe, vir­tuelle Maschinen gegenüber Containern vorzuziehen. Dies sei der Fall, wenn man beispielsweise einen Custom-Kernel ­betreiben, das Gast-Betriebssystem wählen oder eine ­bestimmte Hardware simulieren wolle. Hinzu komme die bessere Isolierung und Sicherheit von Containern, aber auch die Möglichkeit, Work­loads ohne Ausfallzeit «live» zu migrieren. «Vermutlich lassen sich nahezu alle Anwendungen umbauen, um in Containern zu laufen», ergänzt er. Aber: «Technisch gibt es noch Gründe, dass dies nicht immer sinnvoll sein muss.»

Doch wie sehen Anwendungen in Containern eigentlich aus? Im Zusammenhang mit Containern ist häufig von Micro­services die Rede. Darunter versteht man Dienste, die jeweils eine kleine Aufgabe erfüllen. Die Microservices lassen sich über Schnittstellen so miteinander verbinden, dass sich daraus eine beliebig komplexe Software ergibt. Darüber hinaus sind die einzelnen Funktionsblöcke je nach Nutzung und Auslastung unabhängig voneinander skalierbar. Die beiden Haupteigenschaften von Microservices sind dabei Spezialisierung und Eigenständigkeit. So beschränkt sich jeder Dienst auf die Lösung eines bestimmten Problems – und arbeitet eigenständig: Jeder dieser kleinen Dienste lässt sich bereitstellen, betreiben und skalieren, ohne die Funktionsfähigkeit anderer Services zu beeinträchtigen.

Aus technischer Sicht besteht aber zwischen Micro­services und Containern kein direkter Zusammenhang. So lassen sich auch komplette monolithische Applikationen mittels Container betreiben. Doch gerade in Anbetracht ­einer möglichen Skalierung bzw. einer effizienten Nutzung der IT-Infrastruktur ist das manchmal nicht unbedingt ­sinnvoll.

Ähnlich sieht es Wolfgang Kurz, CEO beim IT-Dienstleister Indevis: «Natürlich kann man auch grössere Blöcke in Container packen. Allerdings verfehlt man dann etwas den ursprünglichen Gedanken, für jeden Task einen Container zu haben, der dann im Idealfall ‹state­less› ist und im Bedarfsfall einfach häufiger gestartet wird.» Wolle man beispielsweise eine grosse SQL-Datenbank in einem Container betreiben, dann stelle sich die Frage, warum sie in

einem Container laufen sollte. «In klassischen Infrastrukturen hat man das Thema des persistenten hochverfüg­baren Storage mit hohem I/O, funktionierendem Cluster und Backup-Konzept seit vielen Jahren im Einsatz.» Wenn man so etwas in einem Container machen wolle, dann sei man schnell im experimentellen Bereich oder müsse sehr viel Know-how selbst aufbauen. Das sei nur für sehr grosse Firmen oder Cloud-Anbieter sinnvoll.

In einigen Fällen kann es dennoch ratsam sein, auch ganze Applikationen in Container zu packen. Laut Fleischer von Consol hat es sich insbesondere während der Entwicklungsphase bewährt, lokale Dienste wie etwa Datenbanken oder Queue-Server in Containern zu starten, «da auf diese Weise sehr einfach identische Umgebungen für alle Kollegen im Entwicklungsteam erstellt werden können».

Trotz aller Vorteile – Unternehmen treibt beim Einsatz von Containern vor allem das Thema Sicherheit um. Laut der eingangs erwähnten Studie gaben 38 Prozent der IT-Verantwortlichen an, dass Sicherheitsbedenken ein Grund dafür sind, keine Container im Unternehmen ein­zusetzen. Und die Bedenken haben auch ihre Berechtigung: Denn der sichere Betrieb von Container-Workloads ist alles andere als ­trivial.

In den Anfangszeiten der Containerisierung liefen diese oft mit Root-Rechten. Dadurch konnte ein Angreifer, der die Sicherheitsmechanismen des Host-Betriebssystems überwand und Zugriff auf die Hardware hatte, gegebenenfalls auch auf die Container zugreifen. Heutzutage liegen laut Kleff von NetApp die Hürden hingegen deutlich höher, da viele Lösungen auf den Root-Zugriff verzichten – «System und Container bleiben getrennt, obwohl diese Trennung nicht so weit wie bei einer Server-Virtualisierung reicht.» Im Allgemeinen gilt gemäss Kleff: «Wo aus Sicherheitsgründen eine dedizierte Hardware-Trennung ein­geführt wurde, wird man diese jetzt nicht durch einen Mischbetrieb mehrerer Container auf einem Host ersetzen.»

Dass die Sicherheit ein grosses Thema ist, das noch längst nicht gelöst ist, betont auch Wolfgang Kurz von Indevis. Ein gängiges Problem sei etwa der Übergriff in Speicherbereiche des Nachbarn. Das gelte auch für Teile des Betriebs­systems. «Durch den Einsatz von Containern wird es also keinesfalls sicherer, zumal viele Technologien zum Schutz von Containern noch in den Kinderschuhen stecken.»

Auch wenn alle etablierten Firmen Angebote zum Schutz von Container-Lösungen im Angebot hätten, so seien das oft aus der Virtual-Machine-Welt übertragene Ansätze, die nur teilweise funktionierten. Daher seine Warnung: «Viele Online-Repositories, von denen viele Anwender ihre Container beziehen, sind veraltet und haben eklatante bekannte Sicherheitslücken. Hier muss man im Grunde täglich die Container neu bauen. Solch eine Build Pipeline hat aber nicht jeder im Einsatz, auch wenn sie notwendig wäre.»

Vor allem im DevOps-Bereich ist die Sicherheit von Containern ein Thema: Das Operations-Teams hat die Aufgabe, Sicherheitslücken in Produktivumgebungen zu finden. In der Praxis ist es aber häufig schon schwierig, Komponenten und Abhängigkeiten in Container-Images zu überblicken.

«Der Überblick über Komponenten und Abhängigkeiten in Container-Images gelingt dort, wo die enge Verbindung von Dev und Ops in einer DevOps-Kultur gelebt wird», ­betont Kleff. Die Operations-Teams dürften nicht nur auf das Resultat blicken, «sondern müssen bereits im Code-­Repository und beim Quellcode ansetzen. Hier werden die Abhängigkeiten und Komponenten definiert. Dafür können Firmen auf fertige Lösungen zurückgreifen.» GitHub werde etwa automatisch auf Sicherheitslücken in solchen Abhängigkeiten gescannt und der Anwender benachrichtigt.

Von der Cloud Native Computing Foundation – einem ­Projekt der Linux Foundation, um Cloud Computing, Microservices und Containervirtualisierung zu fördern – gibt es ­eine Reihe von empfohlenen Vorgehensweisen, an denen sich Unternehmen orientieren können. Sinnvoll ist es zum Beispiel, jeweils aktuelle Software-Stände der Container-­Engine und des Orchestrierungssystems einzusetzen oder sensible Workloads voneinander zu separieren. Das lässt sich umsetzen, indem man etwa Applikationen in getrennten Clustern betreibt.

Bei der Verwendung von Container-Basis-Images sollte man darauf achten, aus welcher Quelle diese stammen. Hier ist es womöglich angebracht, entweder einen Anwendungskatalog mit signierten Basis-Images zu verwenden oder auch Container-Images in regelmässigen Abständen neu zu erstellen. Weitere wichtige Aspekte für einen sicheren Betrieb von Container-Workloads sind das Netzwerk-Design sowie der Einsatz von Monitoring- und Logging-Systemen.

Container haben auch Auswirkungen auf den Patch-Prozess. So sind Container typischerweise «immutable». Das bedeutet: Sie werden nicht kontinuierlich gepflegt, sondern einfach durch neue Container ersetzt. Das erfordert in vielen Fällen neue Software-Build- und -Release-Routinen. «Das bringt bei komplexen Systemen – insbesondere in monolithischen Strukturen – viel Aufwand mit sich, dessen Nutzen sich erst später einstellt und sich oft auch nicht vorweg quantifizieren lässt», berichtet Ionos-Produktmanager Grundmann. Bei Containern patcht man also keine Live-Container, sondern die Images in ihrer Container-Registry. «Auf diese Weise kann das vollständig gepatchte Container-Image als eine Einheit ­ausgerollt oder zurückgerollt werden, sodass der Patch-Rollout-Prozess mit seinem – offensichtlich sehr häufigen – Code-Rollout-Prozess identisch wird, komplett mit Überwachung, Canarying und Tests», erklärt Stefan Schäfer, Head of Global Product Marketing beim ­Hosting-Spezialisten OVHcloud.

So werde ein Patch unter Verwendung des normalen ­Prozesses auf vorhersehbare Weise ausgerollt. Eine Alternative  – wenn auch weniger vorteilhaft, da sie nach einem unvorhersehbaren Zeitplan eintritt – sei es, den Rollout ad hoc erfolgen zu lassen. «Wenn ein Container dann das nächste Mal stirbt, dreht Kubernetes einen weiteren Container auf, um dies auszugleichen, und alle Patches, die man angewendet hat, werden auf die Infrastruktur aus­gerollt.» Abhängig von der Lebensdauer der Container sollten diese innerhalb weniger Tage vollständig gepatcht sein.

Die Sache mit den Containern klingt also nicht nur kompliziert – sie ist es auch. Die Integration von Container-Technik stellt viele, vor allem kleinere Unternehmen vor He­rausforderungen. Die Implementierung und das Management von Containern erfordern entsprechend qualifiziertes IT-Personal, das sich vor allem bei dem einen oder anderen Mittelständler erst einmal einarbeiten muss. Hinzu kommt: Viele IT-Abteilungen sind durch die vielen Anforderungen im Zuge der Digitalisierung ausreichend ausgelastet.

Die Nutzung von Container-Diensten, Container as a ­Ser­vice (CaaS), ist daher eine gute Alternative zum ­Aufbau einer eigenen Container-Plattform. Die Cloud-Angebote stellen die notwendige Infrastruktur und Management-Tools wie Docker oder Kubernetes bereit. «Container-as-a-­Service-Angebote sind prä­destiniert für den schnellen Einstieg, weil Unternehmen damit innerhalb kurzer Zeit mit Container-Applika­tionen bei Public-Cloud-Providern starten können», meint Stephan Michard von Dell. Michael Armstrong, Projektleiter beim Hosting-Unternehmen Centron, bestätigt das: «Wir können aus Erfahrung sagen: Dieser Bereich wird immer wichtiger. Wir verzeichnen eine konstant steigende Nachfrage nach Container-as-a-­Service-Lösun-gen – und das ist nur logisch: Die Apps und Services des Kunden sind innerhalb weniger Sekunden verfügbar. Gleich­zeitig muss er weder Fachkräfte für Einrichtung und Betrieb vorhalten noch in eine neue IT-Infrastruktur investieren.»

Für NetApp-Engineer Kleff hat der Einsatz von Container as a Service vor allem praktische Gründe: «Wir erleben den Trend, dass Unternehmen in den Bereichen auf Services zurückgreifen, in denen sie durch einen eigenen Betrieb keinen unmittelbaren Mehrwert schaffen.» Den Mehrwert erbrächten meistens die Applikationen, während die Infrastruktur ein Mittel zum Zweck sei. «Container-Plattformen als Infrastruktur-Ebene zählen deshalb zu den Anwendungsfällen, die ‹as a Service› konsumiert werden können.»

Für Fleischer sind Container as a Service «sicherlich Teil der Zukunft», aktuell komme es aber noch stark auf den Anwendungsfall an. «Es ist sehr charmant, dass man einfach einen Container bereitstellt und dieser beliebig skaliert werden kann, doch fehlt hier in manchen Bereichen noch die Kontrolle.» Konkret bedeute dies, dass man sich etwa bei erhöhten Sicherheitsanforderungen zunächst besser selbst um das Container-Management kümmern sollte. Auch im Sinne der Multi-Cloud gebe es noch Verbesserungspotenzial, da sich die APIs der Anbieter stark unterschieden.

Eines steht fest: Container sind zwar alles andere als einfach zu betreiben, aber die Vorteile überwiegen und der Trend zur Containerisierung wird weiter anhalten. Doch was kommt als Nächstes? Gemäss Dell-Engineer Michard werden Container-Lösungen mittel- bis langfristig sicher eine bedeutendere Rolle als bisher einnehmen – einen genauen Anteil vorherzusagen, hält er jedoch für schwer möglich.

Für Adessos Franz werden sich Container als innovative Technik etablieren, die viele weitere Entwicklungen be­flügelt, «etwa Microservice-Architekturen, Automatisierung von Software-Delivery- und Betriebsprozessen oder ein Homogenisieren dieser Abläufe». Container sind ihm zufolge heute ein anerkanntes Werkzeug in der IT: «Unternehmen nutzen sie standardmässig, wenn es um den vereinheitlichten Transport, das Management oder den Betrieb von Software geht.» Dies zeige etwa das Angebot von Plattformen für das Orchestrieren und das Management von Containern.

Nach Einschätzung von Indevis-CEO Kurz ist auch für die klassische Virtual Machine noch lange kein Ende in Sicht. Im Gegenteil: Es würde noch immer eine Vielzahl physischer Server betrieben. «Gerade wenn es um sehr hohe Performance geht, ist die Hardware-Nähe immer noch entscheidend.» Der ­Kosten-Nutzen-Aufwand, um sämtliche Applikationen in Richtung Container zu entwickeln, stehe oft in keinem Verhältnis.