Eine etwas andere DevOps Transformation

Neuland

Es war einmal eine Software Schmiede. Sie hat immer alles selbst gemacht. Eines Tages stellte sich eine neue Herausforderung. Ein Projekt. Umfangreiche Funktionalität war gefordert. Der Rat der Weisen beschloss es dieses mal anders zu machen und sich im Internet nach einem Open Sauce Produkt umzuschauen. Das Gröbste sollte es doch fertig irgendwo zum Download im Internet geben.  Es dauerte nicht lang, da wurde man fündig. Die Würfel waren gefallen. Aber wer kennt sich damit aus? Man schaute sich weiter um. Dieses mal nach einem Dienstleister. Man wurde fündig. Der Plan war einfach. Der Dienstleister gibt Starthilfe, übergibt und verabschiedet sich dann. Dieses Vorgehen hatte sich in der Vergangenheit bewährt. Die Erben aus den Disziplinen Dev und Op wurden auserkoren.

Die Stimmung war sehr gut. Man freute sich auf ein neues Abenteuer. In der Startformation schien es als würde man die wichtigsten Werte Transparenz und Vertrauen teilen. Funktional schien alles überschaubar und klar. Die Herausforderung würde Skalierbarkeit und Verfügbarkeit werden. Das war auch klar. Zum Glück war da dieses Wundermittel am Horizont – Container. Alle machen das so. Die Funktionalität hatte der Dienstleister ruck zuck umgesetzt und man tütete den Code in diese Container ein. Proof of concept … ?.

Die Komponente des Dienstleister offerierte eine API welche auch von den ernannten Erben beim Kunden genutzt werden sollte. Bei der Abstimmung gab es Groll. Unter anderem weil man sich beim Format nicht so richtig entscheiden konnte zwischen XML und JSON. Da das Open Source Produkt und Tools wie Open API REST und JSON präferieren beugte man sich, bestand aber aus Legacy Gründen darauf XML zu nutzen. Wenn man XML Base64 kodiert bekommt man es schließlich auch in JSON verpackt. Eine Diskussion um die Relevanz von Zeichensätzen im Zusammenhang mit der API schließlich erzeugte eine merkliche Abkühlung der Stimmung zwischen Dienstleister und Dev Erben – vielleicht ein Schlüsselmoment.

Akzeptanz

Allen Bemühungen des Projekt Owner zum trotz distanzierten sie die Dev-Erben. Kommunikation war nur noch sehr schwer möglich. Die Anwendung reflektierte dies und belegte das Gesetz von Conway auf eindrucksvolle Art und Weise. State Management und Hochverfügbarkeit wurden in einer Facade Schicht über der vom Dienstleister implementierten Komponente noch einmal implementiert. Richtung Geschäftsführung wurde kommuniziert das es läuft und das die Arbeit des Dienstleisters sich an einem Wochenende erschließen werde. Java programmieren kann ja auch nicht anders sein wie C#, Linux ist wie Windows und dieses Produkt kann ja auch kein Hexenwerk sein. Von nun an betrachteten die Dev-Erben das Treiben des Dienstleisters aus sicherer Entfernung und forderten regelmäßig Dokumentation. Diese Forderung nach Dokumentation sollte zum Running Gag werden. Beim Dienstleister machte sich der Verdacht breit das die Erben nicht so ganz hinter den Grundsatzentscheidungen des Projektes standen…

Unbeirrt implementierte der Dienstleister wie abgestimmt “Standard nach Gebrauchsanweisung aus dem Internet”. Insofern schien es konsequent und angebracht auf die hervorragende Dokumentation der jeweiligen Projekt-Maintainer zu verweisen und im Detail nur auf das einzugehen was man selbst Implementierte. Weil zwischenzeitig von Formaten wie Word die Rede war, und weil das bis dato gelieferte Markdown offensichtlich nicht auf Gegenliebe stieß ergänzte man mit gedruckter Literatur – offensichtlich aber auch vergebens.

Noch eine Kleinigkeit

Funktional war alles im grünen Bereich. Da war nur noch diese Geschichte mit der Skalierbarkeit und der Verfügbarkeit. Der Hersteller des Fundamentes signalisierte volles Commitment zu diesem Kubernetes. Man konnte den Elefanten im Raum nicht ignorieren. Der eine oder andere witterte … Komplexität – und Mangel an Ressourcen dieser Komplexität Herr zu werden. Glücklicherweise signalisierte der Kunde, dass Kubernetes längst beschlossene Unternehmensstrategie ist und das man damit schon rund zehn Projekte am Start hat. Dem Ersuchen von Kooperation und der Gründung eine Selbsthilfegruppe wurde vom Management eine Absage erteilt. Dem Dienstleister stelle man ein paar mit kubeadm bestückte On Prem Linux VMs und den Rest solle er dann alleine machen und dokumentieren. Den Dienstleister beschlich das Gefühl er werde ein Weilchen aus dem Feuerwehrschlauch trinken müssen. Weil er durstig war willigte er ein, beschloss aber auch ein unmissverständliches Signal zu senden was Kubernetes aus seiner Sicht bedeutete: DevOps!

Der Cloud Markt ging durch die Decke. Kubernetes stand als “Fastest moving project in Open Source history” mit DevOps DNA im Epizentrum. Ein gewisses Mindset erschien sachdienlich.  Alle Beteiligten wurden zu einer Präsentation zusammengetrommelt ?. Auf der ersten Folie stand da nun eben dieses Wort: DevOps. Und dessen Essenz von Wikipedia. Eigentlich sollte es ja nicht der Rede wert gewesen sein. Machten ja auch alle – wie Agile. Vielleicht wäre es besser gewesen der Dienstleister hätte es anders illustriert.  Die Erben jedenfalls schienen unbeeindruckt und tiefenentspannt. Das Feedback unmittelbar nach dem Vortrag bestand im Wesentlichen aus Schweigen. Was am Tag drauf schriftlich kam erschien wie eine Lücke. Dem einen erschien sie als Spalt, dem anderen als Schlucht. Der Dienstleister begann sich Sorgen zu machen was an Kommunikation mit den Dev-Erben überhaupt möglich ist solange offensichtlich komplett unterschiedliches Verständnis bei grundlegenden Begriffen besteht.

Mit Projektleitung und Ops immerhin schien man zu einem gemeinsamen Verständnis zu kommen. Man orientierte sich an einschlägiger Literatur wie Projekt Phoenix, Accelerate oder Reinventing Organisations. Dev und Management sahen keine Notwendigkeit zu Begriffsklärung.

Alternative Fakten

Sobald das Wort DevOps in einem gewissen Personenkreis ausgesprochen war wurde versichert das es bereits implementiert ist. Werkzeuge waren ja gekauft. Und dieses Wort war ja auch in Namen eines Produktes! Alle Symptome jedoch deuteten auf das Gegenteil hin. Misstrauen war allgegenwärtig.

Im Bestreben Werte und Kultur des Kunden zu verstehen studierte er was das Unternehmen im Internet publizierte. “Mitarbeiter Zentrum des Erfolges … modernste Technik … stetig fördern … Innovation … Cloud … aktuelle Methoden … agile  … Scrum … familiär …” – das klang alles vernünftig, reflektierte aber in keinster Weise die Beobachtungen. Es fing schon bei Agile an:

Wir erschließen bessere Wege, Software zu entwickeln,indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Die Gestalt der Organisation erschien wie Modell Wolfsrudel mit Ambitionen auf Maschine. Was ging hier vor sich? Vor dem Hintergrund das man gewohnt war alles selbst zu machen hatte man vielleicht auch den Begriff DevOps selbst neu definiert, passend zum Unternehmen transformiert, und so alternative Fakten geschaffen? In jeden Fall entstand der Eindruck das die Leute zutiefst überzeugt von dem waren was sie sagten. Der Dienstleister malte sich Szenario Vorstellungsgespräch mit einem Bewerber aus der fragt ob im Unternehmen DevOps praktiziert wird …

Infrastruktur und Plattform

Was soll’s, das Ergebnis würde am Ende hoffentlich überzeugen. Abstimmung mit Op im Kontext Platform und Infrastruktur gestalteten sich glücklicherweise unkomplizierter. Es gab hier sehr viele Aufgaben die zwingend vor Launch angegangen werden mussten: Observability, Logging, Monitoring, Alerting, Storage, CI/CD, Lifecycle/Auditing of all things – und so. Man beschloss die Disziplinen Chaos Engineering und Sec zu vertagen. Es erschien sinnvoll diese Dinge selbst “from Scratch” bottom up zu durchleiden – zumindest wenn man die Absicht hat sie diese Themen selbst langfristig umzuhängen statt eine schlüsselfertige Kubernetes Lösung zu nutzen. Nach etwa einem Jahr hatte der Dienstleister all die Dinge in Abstimmung mit Projekt Owner und Op-Erben in Open Source On Prem umgesetzt.

Dev implementierte Last-Tests. Wenn der Begriff Chaos Engineering noch frei gewesen wäre hätte man die Durchführung dieser Tests durchaus so bezeichnen können …

Dem dringenden Ersuchen des Projekt Owners jemand Erfahrenes aus der Belegschaft im Projekt einzubinden wurde von der Geschäftsführung stattgegeben. Erfahrung ist aber relativ. Auf den einen oder anderen wirkte diese Maßnahme wie ein Placebo. Zumal der neue Kubernetes erfahrene Mann des Kunden sich für Historie und Quellcode der Projektes, Präsentation und auch Kubernetes selbst augenscheinlich nicht die Bohne interessierte.

Plattform Battle

Technisch war nicht alles perfekt aber es gab Fälle die liefen. Wegen “Not invented here” und der nach wie vor schwierigen Kommunikation mit den Dev-Erben entschloss sich das Management für ein Battle. Die eigene Mannschaft sollte selbst auch nochmal ihre Kubernetes Plattform bauen. Entwickler sind ja schließlich Entwickler. Anwendung, Infrastruktur oder Plattform – spielt doch keine Rolle – same same. Die bessere Lösung würde dann produktiv gehen. Management setzte Doomsday. Formal sollte Doomsday “alles” an den Kunden übergeben werden. Abgesehen von der Kubernetes-Plattform Implementierung waren die Gewerke des Dienstleisters zu diesem Zeitpunkt bereits seit etwa einem Jahr dokumentiert, der Quellcode stand stets offen. Infrastruktur und Plattform wurde wie in der Präsentation skizziert umgesetzt.

Team Kunde legte mit der Präsentation seiner Lösung vor. Für die Pipelines wählte man anders als der Dienstleister natürlich das Produkt was man schon seit Jahren lizenziert im Haus hatte. Man demonstrierte einen CI Build und zeigte ein System-Diagramm. Das CI System schien abgesehen von der Erzeugung eines Images nicht besonders auf das Kubernetes Umfeld einzugehen.

Die Präsentation des Dienstleisters zeigte ebenfalls ein System-Diagramm und durch Commits ausgelöste Builds und Deployments mit dem auf Kubernetes spezialisierten System aus der Präsentation. Er bemühte sich abermals auf fundamentale Dinge wie deklarativen Infrastruktur Code einzugehen – Reconciliation, GitOps, Pets und Cattle, Automatisierung und so. Das Szenario Pizza selbst backen bzw. von Kubernetes backen lassen illustrierte den Unterschied zwischen imperativ und deklarativ. Von Bedeutung schienen der Entwicklungsabteilung diese Dinge nicht. Wenn alle mit Admin Rechten und Tool der Wahl imperativ deklarativ arbeiten würde das wohl gut gehen.

Der Projekt Owner wählte das System des Dienstleisters für den Livegang.  Nennenswerte Zwischenfälle gab es in Produktion bis auf weiteres erst einmal keine. Für die Entwicklungsabteilung stand dennoch fest: Die eigene Implementierung muss die des Dienstleisters ablösen weil “Not invented here” und auch eine Frage der Ehre. Befindlichkeiten bestimmten schon lange das Handeln.

Erwachet!

In Bezug auf den Begriff DevOps erhielt der Dienstleister unerwartet eine Mail eines Managers. Im Anhang war ein Zeitungsartikel welcher “Aspekte von DevOps im C# Umfeld” beleuchten sollte mit einem “spannenden Abschnitt zur Reduktion von Komplexität”. Der Dienstleister nahm Stellung. Inbesondere brachte er zum Ausdruck, das es nach seinem Verständnis sehr viel bedeutendere Themen an der Basis gebe über die man sich verständigen sollte – Dinge die auch in dem Artikel angesprochen wurden: “Kultur der Zusammenarbeit” und “Digitale Transformation”.

Der Dienstleister entschied sich einen letzten Versuch zu unternehmen dem Unternehmen die Bedeutung von DevOps näher zu bringen. Er schickte dem Kunden eine handvoll T-Shirts “DevOps – Deploying Services since 2000”. Anschließend verfasste er eine vertrauliche Mail an die Geschäftsführung. Er wies insbesondere darauf hin, dass essentielle Dinge wie Kubernetes und dessen Grundlage DevOps in akuter Gefahr schienen nachhaltig im Unternehmen zu scheitern. Er untermauerte mit Fakten.

Die Reaktion der Geschäftsführung ließ nur den Schluss zu das bis auf weiteres alles bleiben wird wie es ist ???. Das Haus brennt aber man sah keine Notwendigkeit etwas zu unternehmen. Es blieb unklar blieb ob man das Issue nicht sah oder nicht sehen wollte. Immerhin birgt “Raus aus Komfortzone und alles anders” ja auch das eine oder andere Risiko und die Zahlen in Excel waren zu diesem Zeitpunkt vielleicht noch nicht rot genug. Game over?

PS: Im Kontext Kubernetes gibt es eine wundervolle Failure Story Sammlung. Gibt es eine vergleichbare Sammlung im Kontext “Digitale Transformation”? Mit so Geschichten wie Die Lufthansa steckt in der Digitalfalle?