Container sind für DevOps nicht alles – aber viel

Container sind kein Wundermittel gegen Grabenkämpfe zwischen Dev und Ops. Wer seiner IT eine Kubernetes-Plattform vor die Nase setzt, seine alte Software lieblos in Container verpackt und dann auf der Plattform auf die Reise schickt, kann nicht erwarten, dass nun der DevOps-Segen magisch auf ihn herabregnet. Gute Technologie ist wichtig, keine Frage, aber am Ende ist sie doch maximal das Mittel zum Zweck. Und für den Zweck der besseren Zusammenarbeit der Abteilungen wird man in erster Linie die Mitarbeiter abholen müssen.

Projekte, die trotz „nicht optimaler“ technischer Rahmenbedingungen diesen Zweck fest im Blick haben und auch erreichen, beweisen das eindrucksvoll. Es gibt durchaus Teams, die seit Jahr und Tag DevOps auch ohne Container leben. Der Erfolg dieser Projekte hat erstmal mit Menschen zu tun: Die Grundvoraussetzung ist meist ein starkes, abteilungsübergreifendes Vertrauen, das im Zweifel erst einmal gewonnen werden will. Auch ein respektvoller Umgang miteinander sowie eine lösungsorientierte Fehlerkultur sind für erfolgreiches DevOps wichtig. Ein bereichsübergreifendes Fachwissen bei Entwicklern wie Admins und das daraus entstehende Verständnis runden das Grundlagenpaket ab. Solide Schutzmaßnahmen für die Produktionsumgebung, die Entwicklern trotzdem einen limitierten Zugang ermöglichen, gehören ebenfalls dazu: Nur so ist sichergestellt, dass sie alles sehen, was sie für ihren Job brauchen. Der Weg dahin ist nicht immer komfortabel. Es dreht sich alles ums Lernen, Verstehen und konstruktiv um die besten Lösungen ringen. Aber schließlich kommt das Team an einem Ort an, an dem es effektiver, effizienter und einfach besser arbeiten kann.

Container können bei der Reise helfen. Sie sind der gemeinsame Nenner in der Arbeit beider Abteilungen, sozusagen das gemeinsame Vokabular beider Parteien. Sie garantieren, dass sich die Test- und Betriebsumgebungen möglichst wenig unterscheiden – eine Grundvoraussetzung für effektives Testing. Für diese Umgebungen forcieren sie ein Code-getriebenes Arbeitsmodell plus Versionierung. Daher ist im Problemfall eine neue, erratische Umgebungsversion schnell wieder durch eine alte ersetzt. Das eröffnet einen gewissen Spielraum für den Zugriff durch Entwickler zwecks Problemanalyse. Gerade für dieses Vorhaben bieten Container-Plattformen wie Kubernetes und darauf aufbauende Observability-Systeme deutlich bessere Möglichkeiten. 

Das alles ist machbar, vorausgesetzt die Software ist für den Container-Betrieb geeignet, was wieder ein ganz anderes Kapitel aufschlägt. So manche Legacy-Anwendung muss dafür einige Refactorings durchlaufen. Das reflexhafte Umwandeln von Monolithen in Microservices greift an dieser Stelle leider meistens zu kurz. Der Ressourcenhunger einer Anwendung ist nur ein Kriterium unter vielen. Bisweilen sind es eher unscheinbare Verhaltensweisen, mit denen eine Containerisierung nicht gelingen kann, etwa Cluster-unfähige Prozesse. Manchmal sind Container auch toleranter als gedacht und der Monolith passt mit ein paar Anpassungen doch hinein. Für eine passende Entscheidung ist in jedem Fall Augenmaß gefordert.

Aber warum eigentlich DevOps? Das Ziel ist, den Software-Lifecycle sowohl zu beschleunigen als auch die Qualität der Software zu erhöhen. Dazu müssen sich aber in erster Linie die involvierten Abteilungen vertragen. Ihnen muss bewusst sein, dass sie in einem gemeinsamen Prozess arbeiten, den sie auch gemeinsam gestalten können. Das geht auch ohne Container, aber mit ihnen eben besser. So wie sich das IT-Business entwickelt, kommen Unternehmen auch aus anderen Gründen bald nicht mehr um sie herum. Warum also warten?