So entwickeln Sie eine zukunftssichere Containerstrategie
Container entwickeln sich zu einer Standard-Infrastruktur für Unternehmensapplikationen. Einfache Hosting-Lösungen reichen heute meist für SMBs nicht mehr aus.
Es gibt wahrscheinlich mehr als hundert Softwarekombinationen, mit denen Organisationen ihre Anwendungscontainer bereitstellen und managen können. Schlecht an dieser Vielfalt ist, dass sie einen langen und komplexen Entscheidungsweg impliziert. Gut ist aber, dass der Kernbestand dieser wachsenden Werkzeugfamilie auf nur einer technischen Wahlmöglichkeit basiert, die mit unterschiedlichen Paketierungsoptionen aus verschiedenen Quellen umgesetzt wird.
Die Basis einer Strategie für das Containermanagement ist die Kombination von Container-Software und -Orchestrierung. Im Markt haben sich einige Software- und Orchestrierungslösungen durchgesetzt, die von den meisten Unternehmen für die Umsetzung ihrer Containerstrategie eingesetzt werden.
Spezielle Containeranforderungen und Begrenzungen der individuellen Anwendung können Unternehmen aber dazu bewegen, andere Optionen auf dem Markt auszuwählen.
Die Grafik (Abbildung 1) zeigt wichtige Anforderungen und skizziert die Herangehensweise an das Containermanagement, die wahrscheinlich diesem Bedarf am besten entspricht.
Einfaches Container-Hosting
Grundlegend für die Container-Bereitstellung ist die einfache Hosting-Fähigkeit der containerisierten Software. Einigen Organisationen reicht das bereits. Geht es um die private Bereitstellung in einem einzigen Rechenzentrum und betrifft die Containerstrategie nur etwa ein Dutzend Standard-Applikationen wie Docker, reicht ein grundlegendes Paket für das Container-Hosting, etwa Docker, aus. Doch das wird immer unwahrscheinlicher, je mehr sich Container verbreiten.
Einfaches Container-Hosting hat den Höhepunkt seiner Verbreitung wahrscheinlich schon erreicht. Nach Marktforschungsdaten der US-amerikanischen CIMI Corporation, einem strategischen IT-Beratungsunternehmen, setzten 2017 mehr als zwei Drittel aller Containeranwender nur „einfache Container-Tools“ ein.
Doch bis Anfang 2019 sehen sich nur noch ein Fünftel von ihnen als Kandidaten für einfaches Hosting – einfache Lösungen reichen dem Rest nicht mal mehr für einen Einstieg in die Containernutzung. Zu dieser großen Gruppe gehörten mehr als 80 Prozent SMBs. Nahezu jeder Containernutzer oder potentielle Anwender sollte deshalb heute eine echte Orchestrierungsstrategie in Erwägung ziehen.
Abbildung 1: Definieren Sie, welches Containermanagementsystem ihre Anforderungen bedient.
Aus strategischen Gründen ist Kubernetes vorzuziehen. Kubernetes ist für Container heute das, was Docker vor nur zwei Jahren war – die grundlegende Basis. Anwender müssen sich weniger darüber Gedanken machen, ob sie Kubernetes Containerorchestrierung als ihr Modell für die Containerbereitstellung wählen.
Vielmehr sollten sie darüber nachdenken, welches spezifische Funktionspaket sie hinzufügen sollten. Kubernetes lässt sich vielfältig durch Funktionen und Fähigkeiten erweitern, und jeder Kubernetes-Quelle integriert die aus seiner Perspektive zur Erweiterung bestgeeigneten Tools und Fähigkeiten.
Mehr Tools für eine Container-Management-Strategie nutzen
Die meisten Organisationen können also schon heute ihren Bedarf mit einer Basis-Containersoftware allein nicht mehr decken. Schon bald werden außer einigen SMBs kaum noch Unternehmen überhaupt diese Möglichkeit haben. Sogar ein einfaches Kubernetes-Paket befriedigt sehr wahrscheinlich die Anforderungen der meisten Anwender nicht mehr. Die nötigen Container-Tools und die organisatorischen Bedürfnisse hängen von drei Faktoren ab:
Von der Art des Hostings und den Hosting-Plänen des Unternehmens. Einige Unternehmen planen, alles in der Public Cloud zu hosten. Die meisten Unternehmen werden aber die wichtigsten Container-Applikationen in ihrem Datenzentrum bereitstellen und daneben einige Public-Cloud-Ressourcen verwenden.
Von der Wahrscheinlichkeit, dass ein Unternehmen mehrere Cloud-Provider nutzt oder sich zumindest Cloud-Provider-Optionen offen hält. Je größer das Unternehmen, desto wahrscheinlicher wird eine Multi-Cloud-Perspektive.
Von den Plänen des Unternehmens für die Bereitstellung tatsächlich elastischer Microservices auf Containerbasis. Diese Einsatzform von Containern muss unabhängig von der gewählten Hosting-Form und dem Hosting-Provider sein, bereit für den Einsatz im Rechenzentrum und bei beliebigen Cloud-Partnern sein, skalierbar und imstande sein, im Notfall auf jede der beteiligten Hosting-Optionen umgeschaltet zu werden. Wieder ist es wahrscheinlich, dass große Unternehmen mit der Zeit in diese Position hineinwachsen, doch manche Organisationen werden diese Veränderung schneller als andere vollziehen.
Der erste Pfad in Abbildung 1 bezieht sich auf Unternehmen, die hinsichtlich ihres Hostings vollständig auf die Public Cloud setzen. Diese betreiben PCs und spezialisierte kleine Server inhouse, aber kein Rechenzentrum. Diese Unternehmen sollten auf gemanagte Kubernetes-Services ihres Cloud-Providers setzen.
Die meisten Unternehmen werden wahrscheinlich dem zweiten Weg im Pfeildiagramm folgen. Hier bleibt das eigene Rechenzentrum der wichtigste Hosting-Standort für Applikationen. Das ist konsistent zur aktuellen Praxis und berücksichtigt die Governance- und Sicherheitsanliegen des höheren Managements.
Für einfache App-Bereitstellung im Rechenzentrum ohne Pläne, Public-Cloud-Funktionen oder Hosting einzubeziehen, reicht Basis-Containersoftware. In den meisten Unternehmen allerdings gibt es, so jedenfalls die aktuellen Trends, wenigstens einige Applikationen oder Applikationselemente, die in der Cloud liegen. Die Orchestrierung ist besonders für größere Rechenzentren, hybride oder Multi-Cloud-Deployments wichtig. Deshalb steht Kubernetes im Zentrum der Containerplanung.
Der Umfang und die Art des Hybrid- und Multi-Cloud-Deployments eines Unternehmens führt zur nächsten Entscheidung: Reicht ein Kubernetes-Basisangebot oder ist eine Lösung mit Funktionen für das Management des Cluster-Hostings über Cloud- und Rechenzentrumsgrenzen hinaus nötig? Fast jedes Kubernetes-Paket reicht für eine einfache hybride Cloud, aber Organisationen brauchen zusätzliche Föderationsfunktionen, um damit Cluster in multiplen Clouds durch gemeinsame Regeln für Multi-Cloud-Umgebungen zu unterstützen. Das gilt besonders, wenn die Komponenten einer Applikation sich zwischen den Providern aus Skalierungs- oder Resilienzgründen verschieben lassen.
Zu den komplexesten Container-Deployments gehören Applikationen, die aus gemeinsam genutzten, skalierbaren, resilienten Microservices bestehen. Diese Microservices werden bei Bedarf über eine Reihe von Rechenzentren und Public Clouds bereitgestellt.
Solche Applikationstypen lassen die Grenzen zwischen Container-Hosting und serverlosem Computing verschwimmen, und viele Anwender glauben bereits, dass containerbasierte Applikationen ein Schritt auf dem Weg zur serverlosen Bereitstellung sind. Es ist komplex, Workloads in einem vollständig dynamischen Set von Komponenten zu verschieben. Daher brauchen diese Applikationen typischerweise zusätzliche Software – man spricht von Service Mesh Technology, also einem vernetzten Set von Services. Diese Servicenetze überschreiten das Containermanagement, aber ihre Bedeutung im Kubernetes-Ökosystem hat zugenommen.
Eine Alternative zum Service Mesh für sehr große und dynamische Applikationen ist die Ressourcenabstraktion. Sie vereinfacht die wiederholte Bereitstellung von Applikationen, indem unterschiedliche Ressourcentypen aus der Außensicht aneinander angeglichen werden. Dazu wird bislang eine zusätzliche Tool-Schicht verwendet, beispielsweise Apache Mesos. Heute allerdings gehört diese Fähigkeit zum Orchestrierungstool Kubernetes und seinen Föderations- und Ökosystemelementen.
Container in der Public Cloud
Andere Optionen außerhalb der bestimmenden Containermanagementstrategie, die auf Docker/Kubernetes basiert, können am besten zu Organisationen passen, die containerisierte Applikationen in der Public Cloud nutzen. Die vier wichtigsten IaaS-Public-Cloud-Provider Amazon, Microsoft, Google und IBM bieten sämtlich Container-Tools an. Es ist klug, diese als erstes zu evaluieren.
Organisationen, die eine containierisierte Applikation auf der Public Cloud betreiben, sollten auch darüber nachdenken, ob sie ihre eigene Containersoftware auf VMs bereitstellen, die von einem öffentlichen IaaS-Provider gehostet werden. Der Vorteil einer Container-on-IaaS-Strategie besteht darin, dass es einfacher ist, dieses Applikationen neben den unternehmenseigenen Applikationen im Datenzentrum als Teil einer hybriden Cloud zu managen und zu betreiben. Tatsächlich können IT- und Entwicklungsteams dieselben Container-Tools beiderorts verwenden.
Organisationen, die eine containierisierte Applikation auf der Public Cloud betreiben, sollten auch darüber nachdenken, ob sie ihre eigene Container-Software auf VMs bereitstellen, die von einem öffentlichen IaaS-Provider gehostet werden.
Der Nachteil der Verwendung eines privaten Container-Toolkits in der Public Cloud liegt darin, dass es schwerer sein kann, Applikationen mit den Web-Services des Cloud-Providers zu integrieren. Wenn ein Unternehmen davon ausgeht, dass seine Applikationen von Cloud-Services abhängen, muss es den Zugriff zu diesen Funktionen koordinieren, falls es getrennte Container-Tools für Deployments und Re-Deployments in der Cloud verwendet.
Mindestens ist stets zu evaluieren, was ein aktueller oder zukünftiger Public-Cloud-Provider als Container-Tools anbietet und wie einfach sie in einem Unternehmensrechenzentrum Containerpläne realisieren können, falls dies nötig wird.
Im Allgemeinen konzentriert sich der Container-Support von Public Cloud Providern stärker auf Orchestrierung als auf grundlegende Software für das Container-Hosting.
Alle Public-Cloud-Provider unterstützten das Orchestrierungs-Tool Kubernetes und alle können Docker-Container hosten. Daher kann es für ein Unternehmen mit starkem Engagement in der Public Cloud klug sein, kompatible Tools für das Rechenzentrum zu wählen.
Organisationen müssen antizipieren, wie sich ihr Einsatz der Public Cloud entwickeln wird. Es ist möglich, Container-Deployments unterschiedlich inner- und außerhalb der Public Cloud zu hosten und zu orchestrieren, aber man braucht dazu größere technische Fähigkeiten.
Die Container-Orchestrierung kann komplex sein und erfordert fähige technische Spezialisten für den Betrieb. Unternehmen, denen die entsprechende technische Expertise in ihrer Gruppe für den IT-Betrieb fehlt, sollten entweder eine einfachere Containerstrategie wählen oder sich für eine Kubernetes-Strategie mit Management durch den Cloud-Provider entscheiden, konzentriert auf ein Produkt, das sich einfach und dauerhaft als Produktionsumgebung nutzen lässt.
Wenn die einfache Herangehensweise den Anforderungen der Applikation nicht entspricht, müssen die technischen Fähigkeiten im Hause erweitert werden, um sicherzustellen, dass Applikationen wie gewünscht laufen und den Anwendern die erwartete Nutzererfahrung bescheren. Viele Softwareanbieter haben auch kundenspezifische Integrationsdienste im Programm, wenn Bedarf danach besteht oder wenn ein Unternehmen unterschiedliche Container-Tools von mehreren Providern verwendet.
Die populärste Container- und Orchestrierungssoftware liefern Drittanbieter. Deren Produkte sind gebündelt und kundenspezifisch konfiguriert, Support ist inklusive.
Diese Software-Bundles reichen von einem neu gepackten einzelnen Tool bis zu kundenspezifischen Funktionen und kompletten Container-Tool-Kits, die alles umfassen, was ein Unternehmen gebrauchen kann.
Sogar wenn diese Pakete einige Extrakomponenten umfassen, die die Organisation aktuell nicht nutzt, können sie die beste Option sein, sich auf einen erweiterten Containereinsatz in Zukunft vorzubereiten. Unternehmen ohne signifikante interne Entwicklungsressourcen und ohne Erfahrung mit Open-Source-Software können Container als Kubernetes-Ökosystem betrachten, eine Sammlung von Tools, die von einem einzigen Provider unterstützt wird.
