DevOps – der Ansatz Entwicklung und Betrieb zusammen zu führen wurde geboren im Umfeld der Informations-Technologie. Er geht in der Regel einher mit Automatisierung, Cloud und Microservices. Insofern also nicht verwunderlich, dass DevOps vorwiegend technisch anmutet. Bei der Implementierung in einer Organisation lohnt sich ein Blick unter die Haube. Was steckt drunter? Expedition eines neugierigen Laien.
DevOps Einstieg Microservices
Den Gipfel des Hype-Zyklus lassen sie so langsam hinter sich. Cool, am Markt gefragt, und grundsätzlich relevant sind Microservices aber allemal noch. Sie als Ursache für das Öffnen der Büchse der Pandora auszumachen greift allgemein sicher zu kurz. Im Folgenden sollen sie exemplarisch zu Illustrationszwecken dienen.
Das Streben nach Agilität und Skalierbarkeit sollten wesentliche Motivation für den Einsatz von Microservices sein. Aber warum ist diese Architektur so disruptiv und oft auch so unerwartet teuer?
Ein kleiner Teil der Antwort auf diese Frage ist einfach: Microservices sind eine Software Architektur. Diese zu ändern ist “per Definition” schon aufwendig 😉. Vermutlich wird aber auch niemand ernsthaft behaupten das eine Migration hin zu Microservices oder weg zum Monolithen günstig ist.
Microservices bringen ein erhebliches Maß an neuer Komplexität mit sich.
Obacht : Komplexität!
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
Alan Perls
Komplexität ist allgemein maßgeblicher Treiber für viele Dinge, die wir heute tun. Unter anderem löst sie Kontrollverlust aus – und Angst davor.
Aber was ist Komplexität eigentlich?
Nicht-Linearität ist eine äußerst unangenehme Eigenschaft von komplexen Systemen. Kleine Änderungen können unvorhersehbar große Wirkung bedingen. Oft sind auch kausale Feedback Schleifen im Spiel. Wir beobachten Verhalten welche wir mit Paradigmen wie Reduktion und Analyse nicht erklären können.
Im Kontext von Software Systemen betrachtet Brooks in No Silver Bullet Komplexität. Er unterscheidet zwischen Essentieller (Inhärenter) und Versehentlicher. Moseley und Marks folgen Brooks bei dieser Unterscheidung in Out of the tarpit. Sie widersprechen ihm aber in der Aussage das die meiste Komplexität in heutigen Systemen essentieller Natur ist. Sie definieren den Begriff nicht, sagen aber dass es Komplexität ist was Software Systeme schwer verständlich macht – insbesondere Zustand und Kontroll-Fluss. Ferner stellen sie fest, dass Abhängigkeit vom Code Volumen nicht linear ist. Helfen uns diese Sichtweisen Microservices besser zu verstehen? Betrachtet man das erste Gesetz “Don’t!” von verteilten Objekten, so erscheinen sie als versehentliche Komplexität (weil fachlich in der Regel irrelevant) die wir vermeiden sollten. Sind es lediglich die technischen Prozess Grenzen welche uns Schwierigkeiten bereiten?
Container als Wirt dieser technischen Prozesse sind zweifellos elementarer Baustein von Microservices der sehr viele Konsequenzen mit sich bringt. Container ändern technisch … alles. Es sind flüchtige Entitäten welche über traditioneller Infrastruktur mit einem hochdynamischen Overlay Netzwerk kommunizieren. Der Vergleich mit dem menschlichen Organismus ist durchaus angemessen (Video einmal starten und eine Minute schauen!):
Wie weitreichend die Folgen sind wird deutlich, wenn man einen Blick auf die Cloud Native Landschaft wirft und sich dabei vergegenwärtigt, dass Kubernetes erst vor gut fünf Jahren freigegeben wurde. Und die Entwicklungen im Epizentrum der digitalen Transformation sind ungebremst rasend schnell.
Man sollte reflektieren, ob eine Einführung im konkreten Fall die Organisation ihrem Ziel überhaupt einen Schritt näher bringt, oder ob es womöglich sogar eine Regression werden könnte. Der Artikel Choose Boring Technology bietet viele Denkanstöße aus einer holistischen Perspektive.
Agile zur Rettung!
Warum nochmal tun wir uns Microservices an? Agilität, stimmt ja. Wir wollen schließlich schneller als der Wettbewerb am Markt sein. Helfen Container da wirklich? Für den Moment sieht es so aus, als ob sie vor allem versehentliche Komplexität bringen. Die Antwort auf Komplexität kennen wir inzwischen ja auch – Agile Methoden. Hä? Müssen wir agil sein, um mit komplexen Microservices klar zu kommen? Ja. Mag seltsam klingen aber Geschwindigkeit und Stabilität schließen sich eben nicht aus sondern bedingen einander. Die Schere zwischen Low- und High Performern geht auseinander. Agiles Vorgehen war was nochmal? Im Allgemeinen Probe, Sense, Respond. Konkret im IT-Umfeld manifestiert es sich seit 20 Jahren(!) im Agile Manifesto oder den drei DevOps Prinzipien. Setzen wir diese Werte um? Experimentieren wir? Können wir mit Scheitern umgehen? Praktizieren wir Retrospektiven? Gibt es (ehrliches) Feedback? Gehen wir wertschätzend miteinander um? … Optimieren wir mit Blick auf das große Ganze? Sind unsere Teams … selbstorganisiert? Warum tun wir uns mit diesen Dingen so schwer?
Kultur
Unser ökonomisches und gesellschaftliches Umfeld wird getrieben durch Dinge wie Digitalisierung zunehmend komplexer, Dinge ändern sich immer schneller. Agilität wird folglich existentieller. Agilität und Organisationskultur bedingen einander. Kultur (=Wertesystem) entwickelt sich aber mit der Dynamik einer Wanderdüne.
Welche Werte sollten eine agile Organisation prägen?
In enger Anlehnung an Spiral Dynamics betrachtet Frederic Laloux in Reinventing Organizations die Entwicklung von Organisationen mit ihrem Wertesystemen. Komplexität ist entscheidender Treiber bei diesen Entwicklungen. Die am höchsten entwickelte Stufe (Türkis / Evolutionär) ist gekennzeichnet durch Selbstorganisation, Holismus (in den DevOps Prinzipien reflektiert durch den ersten Weg – Systems Thinking) und verteilter Führung. Laloux nutzt hier die Metapher Organismus. In türkisen Organisationen finden wir Systemverhalten wie beim Atmen oder bei … Microservices. Natürlich ist Spiral Dynamics nur ein Modell. Insofern ist eine Organisation auch nicht genau an einer Stelle. Man versteht die Verortung einer Organisation besser als den Schwerpunkt ihrer Entwicklung.
Fun fact: Kollektive wie Teams und auch ganze Organisationen selbst sind außerordentlich komplexe Systeme. Genau deswegen bieten sich auch hier agile Methoden für die Entwicklung an. Die Spielregeln sind natürlich ein wenig anders, weil man nur eine Instanz hat (In der Regel also z.B. kein Test-System). 😉
Besonders bemerkenswert erscheint, dass die stärksten Hebel für Veränderung in System-Thinking sich aus elementaren Eigenschaften von Systemen ableiten lassen. Kultur hat signifikant stärkeren Einfluss als Kommunikation von Menschen und/oder Maschinen (Automatisierung). Außerdem besteht offensichtlich eine enge Beziehung zwischen dem “speziellen” Gesetz von Conway mit dem “allgemeinen” Eisberg Modell aus System Thinking: (Kommunikations-)Strukturen generieren Ereignis-Muster und so auch konkrete von einer Organisation produzierte Software.
Resilience
COVID-19, Klimawandel oder die Ausfälle bei AWS oder Google in den letzten zwei Monaten. Eine Tatsache, der man sich stellen sollte – “Organismen erkranken”. Entscheidend ist ein möglichst milder Verlauf (Resilience).
Manche Krankheiten wie z.B. der Solarwinds-Hack werden mit böswilliger Absicht herbeigeführt. Kubernetes wurde in der Vergangenheit mehrfach mit einem trojanischen Pferd der großen Tech Firmen verglichen. Ob man die Analogie hier bis zur beabsichtigten Infektion und Erkrankung des Wettbewerbs durch einen Virus treiben möchte bleibt der Fantasie des Lesers überlassen 😉.
Ist DevOps also eine technische Herausforderung? Zweifellos, aber Einschränkung auf Entwicklung und Betrieb von Software ist sicherlich viel zu kurz gedacht. Und der technische Aspekt ist vermutlich der einfachere Teil.
Update 11.11.2021: Der aktuelle Artikel Complexity is killing software developers ist in diesem Kontext auf jeden Fall lesenswert (“modern software development is a study in entropy, and it is not getting any more simple.” – 2. Hauptsatz der Thermodynamik – Physik ist keine Verhandlungssache 😉)