Betrieb moderner Anwendungsumgebungen

Container as a Service

12. Mai 2020, 07:00 Uhr   |  Henrik Hasenkamp

Container as a Service

Cloud-Infrastrukturen und Micro-Service-orientierte Entwicklungsparadigmen haben das Software-Development in den letzten Jahren grundlegend verändert. Statt umfangreichen monolithischen Releases legt man heute viel mehr Wert auf schnelle Ausführbarkeit und einfache Distribution. Containertechnologien als Service bieten hier die Vorteile des Cloud Computings. die Angebote der Cloud-Provider sind vielfältig. Es stellt sich die Frage: Sind gemanagte Komplettangebote sinnvoll oder genügen kleine Tools, um containerbasierte Anwendungen zu betreiben?

Jede Anwendung benötigt eine Laufzeitumgebung, Systembibliotheken und Ähnliches. Durch die Virtualisierung hat sich das Deployment bereits deutlich vereinfacht: Eine virtuelle Maschine (VM) emuliert die benötigte physische IT-Umgebung, die Virtualisierungsebene (Hypervisor) leitet die Bedarfsanfragen nach CPU-Leistung, Storage, Netzwerk-Ressourcen etc. an die darunterliegende Hardware weiter. Der Vorteil: Eine Applikation lässt sich direkt innerhalb der VM starten, ohne dass der eigene Host die benötigten Voraussetzungen erfüllen muss. Der Nachteil: Die VM beinhaltet das Gesamtsystem, meist mehrere GByte groß. Jede Applikation, die unter anderen Bedingungen arbeitet, benötigt zudem ihre eigene VM. Weil jedes Mal das Betriebssystem zu starten ist, beansprucht dieser Ansatz vergleichsweise viele Hardware-Ressourcen.

Hier setzt die Containertechnik an. Die Anwendungen werden mit ihren Konfigurationen und Abhängigkeiten in ein Standardformat - das Container-Image - verpackt. Im Unterschied zur VM enthält der Container nur Teile eines Betriebssystems und nutzt wesentlich das Betriebssystem des Hosts. Deshalb sind Container gewöhnlich deutlich schlanker als VMs. Trotzdem brauchen auch Container-Images eine Abstraktionsebene, ähnlich dem Hypervisor einer VM, um auf das Host-Betriebssystem zuzugreifen. Bei der bekanntesten und wohl am weitesten verbreiteten Containertechnik Docker übernimmt die Docker Engine diesen Part. Sie muss auf dem Rechner, auf dem die containerisierte Anwendung laufen soll, installiert sein, steuert sie doch das Starten und Stoppen der Container. Durch diese Abkapselung der Anwendung von der zugrunde liegenden Infrastruktur ist der Betrieb auf jeder Plattform möglich, die die Containertechnik unterstützt. Weil nicht erst ein Betriebssystem hochfahren muss, starten Container zudem deutlich schneller als VM-Anwendungen.

Die Docker Engine ist, zumindest als Community Edition, einfach über die Docker-Homepage zu bekommen und in wenigen Schritten installiert - ein guter Start, um erste Erfahrungen zu sammeln. In der Praxis aber entwickelt sich das Container-Ökosystem meistens schnell. Abhängigkeiten zwischen Containern entstehen und die Ansprüche an die Infrastruktur wachsen. Die Orchestrierung der Container - also das automatische Einrichten, Betreiben und Skalieren containerbasierter Anwendungen - gewinnt hier an Bedeutung, insbesondere wenn die Anwendungen aus mehreren Containern bestehen und auf unterschiedlichen Hosts oder Clustern laufen, sprich: wenn eine große Anwendung in Micro-Services zerlegt worden ist.

Inzwischen haben sich mehrere Orchestrierungs-Tools mit teils sehr unterschiedlichen Ansätzen etabliert. Während sich beispielsweise Docker Swarm und Hashicorps Nomad vor allem für die Orchestrierung kleinerer und mittlerer Workloads auf einer überschaubaren Anzahl an Servern eigenen, haben sich Apache Mesos und Kubernetes auch im Umfeld größerer Work-loads bewährt. Vor allem Kubernetes sehen derzeit viele Experten als den De-facto-Standard an. Das Open-Source-Tool unterstützt mehrere containerbasierte Virtualisierungssysteme - ein Vorteil gegenüber den meisten spezialisierten Werkzeugen. Eine große aktive Kubernetes-Entwickler-Community verbessert das Tool ständig.

502 LANline2020-05 Gridscale Bild 2.png
©

Eine benutzerfreundliche GUI erleichtert es dem Anwender, eine Containerumgebung wie zum Beispiel ein Kubernetes-Cluster aufzusetzen. Bild: Gridscale

CaaS-Angebote (Container as a Service) kombinieren dies. Dahinter verbergen sich Angebote von Cloud-Providern, die containerbasierte Virtualisierung als Service über ihre Plattform und somit skalierbar aus der Cloud anbieten. Wie im Cloud Computing üblich, ermöglichen diese Services den Anwendern, Containertechnik zu nutzen, ohne selbst Infrastruktur dafür bereitstellen zu müssen. Konkret heißt das. Der Provider stellt die Laufzeitumgebung inklusive Bibliotheken und Konfigurationen ebenso bereit wie die zugrunde liegenden Infrastrukturressourcen und häufig auch das Orchestrierungs-Tool. Die Kommunikation zwischen Nutzer und Provider erfolgt über eine API oder über ein grafisches Interface (GUI).

Wer seine Containerplattform nicht selbst betreiben will, sieht sich unzähligen Angeboten gegenüber, die nur schwer vergleichbar sind. Noch gibt es kaum Standards im Bereich der Containerorchestrierung und viele Anbieter halten mehrere Lösungen für das gleiche Problem bereit. So treten beispielsweise einige Provider, die aus dem Managed-Hosting-Umfeld kommen, als Reseller meist amerikanischer Hyperscaler auf. Hier erfolgt der Vertrieb der Containerplattformen der Hyperscaler also nicht nur durch diese selbst über deren eigene Cloudangebote, sondern auch durch weitere Provider. Das betrifft Google Container Engine (GKE), Amazon EC2 Container Services (ECS) und Microsoft Azure Container Service (ACS).

Gleichzeitig können Unternehmen sich bei solchen Resellern ihre eigene Plattform zusammenstellen oder auch bei den Tool-Herstellern selbst jeden Service einzeln als Clouddienst buchen. So ist zum Beispiel eine Umgebung bestehend aus Docker als Containertechnik, Kubernetes als Orchestrierungs-Tool und der Web-Oberfläche Kubermatic des Hamburger Unternehmens Loodse eine gute Basis für Entwicklung und Management containerbasierter Anwendungen. Sich einzelne Komponenten zusammenzustellen, statt ein gemanagtes Komplettangebot zu wählen, erfordert Know-how wie auch Erfahrung und will deshalb wohl überlegt sein.

Zwar kann ein Anwender so eigene Vorlieben beachten und die leistungsfähigsten Tools wählen, aber es kostet Zeit, diese auszuwählen, zu konfigurieren und zu integrieren. Außerdem haben spezialisierte Unternehmen dann meist doch etwas mehr Erfahrung aus der Praxis und können auf die eine oder andere Stolperfalle der Zukunft schon von Beginn an hinweisen. In der Praxis sind diese IT- und Entwicklungsspezialisten jedoch eher knapp. Wer jedes Tool als einzelnen Service bucht, sieht sich schnell einer unübersichtlichen Multi-Cloud-Umgebung gegenüber, die wachsenden Management-Aufwand erfordert. Die Vorteile der Containerisierung - schnelle, kostengünstige und unkomplizierte Bereitstellung von Applikationen - sind so bald zunichte gemacht.

Native-Cloud-Provider (also Anbieter speziell für die Public Cloud entwickelter, sogenannter "cloudnativer" Dienste) wie die erwähnten Anbieter Hyperscaler bieten ihre CaaS-Lösungen natürlich auch auf ihren eigenen Plattformen an. Mit ihren gemanagten Komplettlösungen stehen sie auf dem Markt keineswegs allein da. Auch auf die Anforderungen speziell mittlerer Unternehmen spezialisierte Clouddienstleister stellen leistungsfähige Managed Services für Container zur Verfügung. Hier erhält man bespielsweise kostenlose, betriebsfertig eingerichtete Kubernetes-Umgebungen - lediglich die für die Container-Workloads benötigten IaaS-Ressourcen werden minutengenau und nutzungsabhängig berechnet.

Allen Native-Cloud-Anbietern ist gemein, dass ihre Lösungen in ihre jeweiligen Service-Welten eingepasst und die einzelnen Tools gut integriert sind. Die Provider kümmern sich um die kontinuierliche Entwicklung und Aktualisierung des Angebots, den Betrieb, das Kapazitäts-Management, die Überwachung der Plattform und notwendige Sicherheits-Updates. Unterschiede bestehen lediglich darin, wie betriebsbereit eine Lösung ist. Zuweilen sind noch einige Entscheidungen zu treffen und weitere Services, etwa ein Authentifizierungs-Service, ein Load Balancer oder persistenter Speicher, einzubinden.

Ebenso deutliche Unterschiede zeigen sich in puncto Benutzeroberfläche. Die meisten Native-Cloud-Provider verzichten auf eine einfach zu handhabende GUI. Für die Konfiguration der Plattform und Steuerung der Workloads stehen dem Nutzer zahlreiche Einstellungsmöglichkeiten zur Verfügung. In der Praxis erweist es sich dann doch als schwierig, die optimale Konfiguration zu finden, zumal individueller Support bei den Hyperscalern naturgemäß keine Selbstverständlichkeit ist. Diese Lücke machen sich andere Provider zunutze: Sie stellen beispielsweise Kubernetes-Anwendern eine benutzerfreundliche, intuitive Oberfläche zur Verfügung. Dabei sind bereits wichtige Voreinstellungen so getroffen, dass die am häufigsten gewählten Module wie Load Balancer, persistenter Storage und Scheduler sinnvoll vorgewählt sind. Dem Nutzer ermöglicht dies, innerhalb weniger Minuten zu starten und die Vorteile einer gemanagten Lösung voll auszukosten.

Henrik Hasenkamp ist CEO von Gridscale, www.gridscale.io.

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

SentinelOne: Schutz für Cloud-native und containerisierte Umgebungen
Service Blocks: Rackspace erweitert cloudnative Services
NetApp: Entwicklung von Projekt Astra

Verwandte Artikel

Cloud

Container

Kubernetes