Umzugscontainer
Von Roland Freist
Die Release-Zyklen moderner Software ziehen immer engere Schleifen. Steigender wirtschaftlicher Druck erfordert von den Herstellern eine schnelle Reaktion auf Neuentwicklungen am Markt, gleichzeitig müssen sie verschärfte Anforderungen an die Security und weitere Compliance-Richtlinien erfüllen. Die Hersteller geben diesen Druck an ihre DevOps-Teams weiter, die ohnehin unter Zeitdruck stehen und nun gezwungen sind, Wege zu finden, noch effizienter zu arbeiten.
Die Entwicklungsarbeit ist daher in den vergangenen Jahren zunehmend in die Cloud gewandert. Dort ist einerseits eine einfachere Zusammenarbeit möglich, zum anderen stehen die benötigten Ressourcen in nahezu unbegrenztem Ausmaß zur Verfügung. Eine Platform as a Service (PaaS) als Grundlage der Software-Entwicklung ist bei jedem größeren Cloud-Anbieter in verschiedenen Ausstattungsvarianten erhältlich.
Container und Microservices
Hinzu kommt die moderne Container-Technik. Zehn Jahre nachdem Docker seine gleichnamige Software zur Container-Virtualisierung erstmals vorgestellt hat, kann die Technik als ausgereift gelten. Rund um Docker ist eine Infrastruktur mit weiteren Tools wie z.B. der von Google beigesteuerten Container-Verwaltung Kubernetes entstanden. Mittlerweile gibt es auch etliche Alternativen zu Docker, das jedoch immer noch den De-facto-Standard darstellt. Zu nennen sind vor allem LXD und Podman.
Der grundlegende Gedanke ist allerdings derselbe geblieben: In Software-Containern verpackte Microservices lassen sich zu Anwendungen zusammenfügen; fertige, in Containern virtualisierte Anwendungen können in Form von Dateien mit allen ihren Paketen schnell von einer Betriebssystemumgebung in eine andere verschoben werden. Ebenso wie virtuelle Maschinen greifen zwar auch Container auf Virtualisierungstechnik zurück, sie sind jedoch erheblich leichtgewichtiger und damit schneller und flexibler einsetzbar.
Diese Vorteile machen Container zum Arbeitsmittel der Wahl, wenn sich ein Unternehmen für eine Multi-Cloud-Umgebung entschieden hat. Der Grund ist meist ein Best-of-breed-Ansatz, bei dem eine Private Cloud und mehrere Public Clouds miteinander kombiniert werden, weil das Unternehmen durch die Kombination mehrerer Anbieter Kosten und Performance für die verschiedenen Einsatzzwecke optimieren möchte. Gleichzeitig gewinnt es zusätzliche Flexibilität. Wer einmal entsprechende Angebote ausgewählt hat, ist in der Lage, einen Cloud-Anbieter innerhalb weniger Tage oder Wochen gegen einen anderen auszutauschen.
Schwarz auf Weiß
Dieser Beitrag ist zuerst in unserer Themenstrecke „Storage und Server“ erschienen. Einen Überblick mit freien Download-Links zu sämtlichen Einzel- und Sonderpublikationen bekommen Sie online im Pressezentrum des MittelstandsWiki.
Die möglichen Gründe sind vielfältig. Vielleicht bietet ein konkurrierender Provider ein besseres Preis-Leistungs-Verhältnis. Oft sind es aber auch Sicherheitserwägungen oder regulatorische Gründe: Wenn ein Anbieter seine europäischen DSGVO-konformen Rechenzentren aufgibt und sich wieder in die USA zurückzieht, können oder wollen viele Unternehmen die Geschäftsbeziehung nicht aufrechterhalten. Zudem geschieht es immer wieder, dass ein Dienstleister sein Cloud-Geschäft komplett einstellt.
Eine Migration zu einer anderen Cloud sollte für die DevOps-Teams dank Container-Technik an und für sich kaum Auswirkungen haben. Services und Anwendungen lassen sich schnell und umstandslos übernehmen – das sagt zumindest die Theorie. Doch in der Praxis hat sich gezeigt, dass Unternehmen bei einem solchen Umzug oft auf weit mehr Schwierigkeiten stoßen, als sie erwartet hatten.
Komplexe Cloud-Migrationen
Eine der ersten Hürden ist oft, dass in der IT-Abteilung weder die technischen Möglichkeiten noch das Know-how zu den Prozessen einer Migration vorhanden ist. Denn es geht nicht darum, einfach nur einen Kopierbefehl auszuführen. Die Aufgabe ist wesentlich komplexer.
Jeder Cloud-Anbieter unterstützt unterschiedliche Data-Exchange-Standards. Die Dokumentation dazu ist oft lückenhaft oder fehlt gänzlich. Die Voraussetzungen einer Portierung von Daten und Anwendungen sind damit bereits denkbar schlecht. Unternehmen sollten für diesen Fall einen Plan entwickeln, wie sie diese Lücke überbrücken können, etwa durch den Einsatz von Open-Source-Technik, eigenen Software-Entwicklungen und/oder der Etablierung einer zusätzlichen Abstraktionsschicht.
Teil 1 beginnt dort, wo der Datenschutz am wichtigsten ist: bei den Auftragsdatenverarbeitern für Kommunen. Dabei geht es auch gleich um die zentralen Vorgaben der Privacy Compliance. Teil 2 nimmt sich dann den deutschen Norden und Osten vor, um zu prüfen, welche Rechenzentren sich dort anbieten. Teil 3 berichtet mitten aus dem Digitalisierungskessel an Rhein und Ruhr, Teil 4 sichtet die Lage im deutschen Südwesten, bevor Teil 5 sich in Bayern umsieht. Auch ein Seitenblick nach Österreich und eine Übersicht über die dortigen Cloud-Anbieter sind bereits online, ebenso eine Vorschau auf das Projekt Gaia-X, das namentlich für den Mittelstand interessant sein könnte. Zur Frage der Datenhoheit könnten Zertifizierungen und nicht zuletzt Open Source gute Cloud-Antworten geben. Ein Extra-Beitrag widmet sich außerdem den Fragen der App-Portabilität.
Auch der verwendete Hypervisor ist bei den Cloud-Plattformen unterschiedlich. Das betrifft sogar die drei Hyperscaler Amazon Web Services (AWS), Google Cloud Platform (GCP) und Microsoft Azure. Jeder dieser Dienste verwendet darüber hinaus andere Runtimes auf der Chipsatz- und Befehlssatz-Ebene. Um diese Unterschiede auszugleichen, empfehlen Fachleute einen Cloud-unabhängigen PaaS-Dienst. Doch dafür ist abermals spezielles Know-how erforderlich.
Anpassung der Umgebungsvariablen
Probleme treten regelmäßig auch beim Start einer Container-Anwendung auf. Administratoren sollten sich darauf gefasst machen, dass vor einem erfolgreichen Start zunächst die Umgebungsvariablen angepasst werden müssen. In anderen Fällen stehen Sicherheitsmechanismen der Cloud der Ausführung einer Anwendung entgegen und verhindern z.B., dass eine Datenbankbibliothek Verbindung zu einer Datenbank aufnehmen kann.
Eine weitere Hürde bilden die oft proprietären CLI-Tools (Command-Line Interface), die die Provider ihren Kunden für die Container Bereitstellung zur Verfügung stellen. Sie folgen in der Regel keinem allgemein anerkannten Standard, was zur Folge hat, dass die User sich in jedes dieser Tools zunächst einmal einarbeiten müssen. Darüber hinaus müssen die Mechanismen der Automatisierung der Container-Bereitstellung jedes Mal neu angepasst werden. Eine übergreifende Plattform wie OpenShift von Red Hat kann zwar viele dieser Probleme lösen, erfordert auf der anderen Seite aber in der Regel eine umfangreiche Konfiguration des Code-Repositorys.
Proprietäre Entwicklungen können auch an anderen Stellen die Funktionsfähigkeit einer portierten Container-Anwendung gefährden. Wenn sie z.B. auf proprietären APIs aufsetzt, die in der neuen Umgebung nicht verfügbar sind, ist sie in ihrer Funktionalität mindestens eingeschränkt bzw. unter Umständen gar nicht ausführbar; es empfiehlt sich daher allgemein der Einsatz von offenen Schnittstellen. Ähnliche Probleme sind zu erwarten, wenn Teile des Codes von speziellen Systembibliotheken abhängig sind, die nicht in jeder PaaS-Umgebung vorhanden sind und sich oft auch nicht nachinstallieren lassen. Als Lösung bietet sich die Zusammenstellung von Buildpacks an, die alle benötigten Komponenten enthalten und auf die jeweiligen Cloud-Plattformen hochgeladen werden.
Schließlich muss die IT-Abteilung auch auf eventuelle Versionskonflikte gefasst sein. Wenn der Cloud-Anbieter eine andere Version der Programmiersprache verwendet, in welcher die Container-Anwendung geschrieben ist, kann es zu Konflikten bei den Abhängigkeiten kommen.
Erfahrungsberichten zum Einsatz von Container-Technik in Multi-Cloud-Umgebungen lässt sich entnehmen, dass sich letzten Endes fast immer eine Möglichkeit findet, die containerisierte Applikation von einer Cloud zur anderen zu portieren. Der manuelle Aufwand ist jedoch oft beträchtlich. Je nach Cloud-Umgebung ist ein anderes Setup erforderlich, was eingehende Kenntnisse der PaaS-Umgebung des Anbieters und nicht zuletzt auch der Anwendung selbst erfordert.
Die einfache Portabilität von Cloud-Containern ist ein Wunschtraum von Unternehmen und Entwicklern, der sich derzeit noch nicht realisieren lässt. Denn jede Cloud hat ihre Besonderheiten, was dazu führt, dass die verpackten Anwendungen angepasst werden müssen, bevor sie in der neuen Umgebung funktionieren. Notwendig wäre die Definition einiger grundlegender Cloud-Standards. Das ist jedoch derzeit nicht in Sicht.
Roland Freist, Jahrgang 1962, begann nach einem Studium der Kommunikationswissenschaft ein Volontariat beim IWT Verlag in Vaterstetten bei München. Anschließend wechselte er zur Zeitschrift WIN aus dem Vogel Verlag, wo er zum stellvertretenden Chefredakteur aufstieg. Seit 1999 arbeitet er als freier Autor für Computerzeitschriften und PR-Agenturen. Seine Spezialgebiete sind Security, Mobile, Internet-Technologien und Netzwerke, mit Fokus auf Endanwender und KMU.
Redaktionsbüro Roland Freist, Fritz-Winter-Str. 3, 80807 München, Tel.: (089) 62 14 65 84, roland@freist.de
