IT-Prioritäten verschieben sich: Waren es früher Konsolidierung und Kostenreduktion, stehen heute Agilität und Geschwindigkeit ganz oben auf der Agenda. Neue IT-Modelle, Entwicklungs- und Betriebsprozesse wie Container, DevOps und Microservices gewinnen daher zunehmend an Bedeutung.
Die Vorteile von Containern liegen auf der Hand: Erstens definieren sie ein einheitliches Format für Applikationen, die deshalb erheblich schneller produktiv eingesetzt werden können (Time-to-Market), zweitens kapseln Container Anwendungen von der darunterliegenden Hardware und machen sie deshalb wesentlich portabler. Die Gleichartigkeit von Container-basierten Anwendungen beim Starten, Stoppen und dem Auslesen von Metriken und Logs bildet die Basis effizienter Betriebsprozesse. Außerdem benötigen Container keinen Hypervisor, sondern nutzen Betriebssystemfunktionen, sodass sie sehr ressourcenschonend und schneller im Vergleich zu virtuellen Maschinen
arbeiten (Abb. 1). Trotz all dieser Vorteile fällt es Unternehmen nach wie vor schwer, Container-Technologien einzuführen und sie in die vorhandene IT-Systemlandschaft zu integrieren.
Einer der Gründe dafür: Die Container-Technologie erfordert einen grundlegenden Wandel, denn das Silodenken zwischen der Software-Entwicklung, der Storage- und Netzwerk-Administration und dem Server-Betrieb muss überwunden werden. Wenn neue Software-Releases nach dem DevOps-Modell schneller und häufiger bereitgestellt werden sollen, müssen bei der Integration von Container-Technologien in die Unternehmens-IT vorhandene Prozesse angepasst und neue etabliert werden. Neun Best-Practices unterstützen Unternehmen bei der Einführung der Container-Technologie.
1. Transparenz herstellen und Wertschöpfung definieren
Ein wichtiger Startpunkt besteht darin, dass alle Beteiligten aus der Software-Entwicklung und dem IT-Betrieb ein gemeinsames Verständnis schaffen, was es heißt, Software in den IT-Betrieb zu überführen. Entscheidend ist dabei der Unterschied zwischen Lead-Time und Processing-Time. Die Lead-Time beginnt mit der Spezifikation einer Anforderung und endet, wenn der Auftrag erledigt ist. Die Processing-Time läuft erst dann, wenn die eigentliche Arbeit anfängt; Liegezeiten zählen nicht dazu. Je kürzer die Durchlaufzeit, desto besser.
Dazu gehört eine Klärung folgender Fragen: Welcher Schritt im Prozess dauert wie lange? Wie viel Zeit vergeht, bis eine bestimmte Funktion in den produktiven Betrieb eingeführt wird? In der traditionellen Software-Entwicklung kann das einige Wochen oder gar Monate dauern. Relevant ist die Zeit, bis die Software produktiv läuft und einen Nutzen erzielt. In vielen Fällen ist bislang der Prozess der Software-Entwicklung eine Black-Box. Durch eine Visualisierung wird der Prozess transparent: Welche Schritte gibt es? Welches Team ist wofür zuständig? Wo gibt es Liegezeiten? Eines der Werkzeuge dafür ist Value-Stream-Mapping (VSM), bei der die Wertschöpfungskette dargestellt wird.
2. Grundprinzipien effizienter Prozesse berücksichtigen
Value-Stream-Mapping ist eine Methode, die ihren Weg aus der Fertigung in die Software-Entwicklung gefunden hat und kommt nun auch immer häufiger bei der Software-Entwicklung zum Einsatz. Die entsprechenden Tools zeichnen den Materialund Datenfluss vom Lieferanten bis zu den Kunden nach. Damit sind auf einen Blick Ursachen für Verzögerungen im Workflow erkennbar, aber auch Engpässe, die sich auf den Produktionsprozess auswirken. Entstanden ist VSM in engem Zusammenhang mit dem Toyota-Production-System, bei dem es unter anderem darum geht, wie Prozesse im Allgemeinen optimiert werden können.
Eine der Aktivitäten besteht darin, Arbeitsschritte sichtbar zu machen. In der agilen Software-Entwicklung gibt es dazu Techniken wie das Kanban-Board, mit dem sich die Arbeitseinheiten visualisieren lassen. Das gibt es beispielsweise auch in digitaler Form mit der Projektmanagement-Software Trello. Eine wichtige Kenngröße ist Work-in-Progress und die Ermittlung, wie viele und welche Arbeitsschritte parallel stattfinden. Idealerweise sollten so wenig Schritte wie möglich parallel durchgeführt werden. Ein weiterer Aspekt ist, die Größe der
Software-Pakete zu begrenzen. Je größer die Pakete, desto größer auch das Risiko, dass sich Fehler einschleichen, die erst im produktiven Einsatz bemerkt werden – und nur aufwendig zu beheben sind. Werden kleinere Pakete in die Produktion gebracht, sinkt das Fehlerrisiko.
3. Geeignetes Pilotprojekt auswählen
Bei einem Greenfield-Projekt gestaltet sich aus organisatorischer Sicht die Einführung von Container-Technologien einfacher als bei einem Brownfield-Projekt, bei dem manchmal mit allen Mitteln versucht wird, vorhandene Applikationen in die Container-Welt zu migrieren. Vor allem aber sind bei neuen Projekten die Komplexität und die Abhängigkeiten geringer und damit auch die Risiken des Scheiterns. Zudem hat es sich in der Praxis bewährt, dass in der Anfangsphase der Container-Einführung eher Entwickler beteiligt sein sollten, die als innovativ gelten und neuen Technologien gegenüber aufgeschlossen sind.
Von der technischen Seite gesehen, eignen sich für ein Pilotprojekt häufig Web-basierte Applikationen. Diese sind in der Regel einfacher strukturiert und lassen sich in Programmiersprachen wie Java, PHP oder Perl erstellen. Zudem sollte die Anwendung nicht zu viele Komponenten haben und außerdem sollte diese möglichst wenig zustandsbehaftet sein (Stateless vs. Stateful). Ideale Voraussetzungen liegen vor, wenn die IT-Abteilung mit Microservices experimentiert. Microservices und Container passen perfekt zusammen. Aber auch für Brownfield-Anwendungen werden Container immer interessanter: Selbst die Anbieter von Standard-Software orientieren sich immer stärker
in Richtung Container.
4. DevOps-Kultur etablieren
Grundsätzlich gilt: Es existiert keine universell gültige DevOps-Definition. Allerdings gibt es eine Reihe von wichtigen Rahmenbedingungen.
Dazu gehören die offene Kommunikation zwischen den Team-Mitgliedern, ein gutes Vertrauensverhältnis und die offene Aussprache über Fehler. In der DevOps-Kultur gelten Fehler als Möglichkeiten zur Verbesserung. Es wird versucht, Fehler mit Swarming-Technologien zu beheben. Wenn etwa ein Software-Release in der Produktion nicht funktioniert, wird die Weiterentwicklung gestoppt bis das Problem durch das gesamte Team, bestehend aus Entwicklung und Betrieb, gelöst wird. Vor allem aber soll aus dem Vorfall gelernt werden, um in künftigen Situationen schneller reagieren zu können. Dazu gehört auch, schnell und regelmäßig Feedback zwischen allen Beteiligten auszutauschen.
Dieser Lösungsweg stammt ebenfalls aus dem Toyota-Production-System, bei dem es eine sogenannte Andon-Cord gibt. Kommt es im Produktionsprozess zu Problemen, zieht ein Mitarbeiter diese Reißleine. Das Grundprinzip dahinter: Es wird sofort auf Fehler reagiert. Jeder Mitarbeiter hat in diesem Prozess die gesamte Wertschöpfung und nicht nur seine „kleine Insel“ im Blick. Das unterscheidet sich stark davon, wie heute noch in siloartigen Organisationsformen in der IT gearbeitet wird. Hier wird bestenfalls das eigene Silo, nicht aber das große Ganze optimiert. Gerade die Einführung der Container-Technologie bietet die Möglichkeit, das Silodenken zu überwinden. Denn bei der Nutzung von Containern müssen Mitarbeiter aus der Entwicklung, dem Storage- und dem Networking-Bereich zusammenarbeiten.
5. Schrittweise Automatisierung einführen
Dadurch, dass Container, bedingt durch die zugrundeliegende Technologie und das einheitliche Format, Anwendungen gleichartig aussehen lassen, bieten sie die ideale Grundlage für die Automatisierung. Es muss beispielsweise nur einmal ein Prozess implementiert werden, um Daten zu verschieben oder Artefakte zu deployen. Vor allem aber lässt sich die Automatisierung auch schrittweise einführen.
Die IT-Abteilung kann beispielsweise mit Continuous-Integration (CI) – also mit dem täglichen Erstellen von lauffähigen Software-Paketen – anfangen. Der nächste Schritt ist der Aufbau von Continuous-Deployment (CD)-Pipelines, um Container von einer Betriebsumgebung in die nächste zu bringen (Abb. 2). Dazu kommt schließlich das automatisierte Testen. Hier wird mit Unit-Tests gearbeitet, um die Qualität, Wiederholbarkeit und Verlässlichkeit beim Testen zu optimieren. CI und CD funktionieren mit Containern deutlich einfacher als mit traditionellen Mitteln; hier nutzt jede Umgebung ihre eigenen Verfahren. Container ermöglichen es, CI und CD für sehr viele Applikationen auf eine einheitliche und einfache Art und Weise zu betreiben.
Bereitstellung weiterentwickelt. Das Herzstück dabei sind Linux-Container auf Basis des OCI-Formatd (Open Container Initiative), das von vielen führenden IT-Unternehmen, darunter Amazon, Google, Hewlett Packard Enterprise, IBM, Microsoft und Red Hat unterstützt wird. Das OCI-Container-Format ist aus dem Docker-Format hervorgegangen und gilt in der Zwischenzeit als Industriestandard unter Schirmherrschaft der Linux-Foundation. Nicht nur Software-Hersteller, sondern auch Unternehmen, die mit Linux-Containern Anwendungen entwickeln und betreiben, beteiligen sich aktiv in der Linux-Foundation.
Dazu kommt zweitens die sogenannte Runtime-Specification, die das Laufzeit-Management von Containern definiert.
Sebastian Faulhaber ist Senior Solution Architect, Technical Teamlead Middleware D/A bei Red Hat.
Sebastian Faulhaber hat über acht Jahre als technischer Berater mit den Schwerpunkten Business Integration und Business Process Management (BPM) bei IBM gearbeitet. 2013 kam er als Solution Architect zu Red Hat. In dieser Funktion setzt Faulhaber seine umfassende Praxiserfahrung ein, um Kunden bei der erfolgreichen Implementierung der Open-Source -Technologien von Red Hat zu unterstützen.
Weitere Links:
https://bit.ly/2BH9YQS
https://www.openshift-anwender.de/
