Vor rund zehn Jahren kam der Begriff DevOps auf. Seitdem hat sich technisch einiges verändert. Außerdem gibt es ganz neue Kollaborationsansätze in der IT.

Im Jahr 2019 ist die DevOps-Bewegung zehn Jahre alt geworden. Die öffentliche Initialzündung war ein Vortrag von John Allspaw und Paul Hammond von Flickr auf der O’Reilly Velocity Conference 2009 [1]. In diesem Vortrag beschreiben die beiden die seinerzeit übliche Arbeitsteilung zwischen Softwareentwicklung (Dev) und -betrieb (Ops) folgendermaßen: „Dev’s job is to add new features. Ops’s job is to keep the site stable and fast.“ Sie argumentieren, dass beide Parteien das Business unterstützen sollten und diese Unterstützung nur durch kontinuierlichen Change möglich sei. Damit der kontinuierliche Change aber nicht zu Fehlern und Ausfällen führt, brauche es neue Tools und kulturelle Ansätze („Lowering the risk of change through tools and culture“).

Wie sehr sich die Welt von einem Tag auf den anderen ändern kann, ist im Jahr zuvor am Beispiel der Bank Lehman Brothers und der weltweiten Finanzkrise nur allzu deutlich geworden. Die Wellen dieser Krise reichen weit bis ins Jahr 2009 hinein. In diesem Jahr meldeten unter anderem der Autohersteller GM und Arcandor AG (ehemals KarstadtQuelle AG) Insolvenz an. Einzig die politische Lage wirkt aus heutiger Sicht stabiler: Mit Barack Obama wurde ein Hoffnungsträger als US-Präsident vereidigt und aus der Bundestagswahl gingen CDU und FDP mit einer eindeutigen Regierungsmehrheit hervor. Die schnelle Bildung von Zweiparteienkoalitionen ist heute seltener geworden.

Die IT-Landschaft dieser Tage war auch noch sehr viel klassischer als heute: Das iPhone ist erst zwei Jahre alt und beginnt gerade erst, die mobile Internetnutzung zu verändern. Das Hosting von Anwendungen findet in der Regel ganz klassisch in Rechenzentren statt. AWS ist erst ca. drei Jahre alt und Google startet mit der Google App Engine for Java [2]. Beide sind zu diesem Zeitpunkt noch keine echten Alternativen zum On-Premise Hosting. Das bedeutet auch, dass IT-Infrastruktur zu dieser Zeit noch ein erhebliches Investment darstellte. Meist wurden schon zu Beginn einer Softwareentwicklung die Hardwaresysteme für den späteren Betrieb dimensioniert und bestellt. Die Kosten für diese Investition waren mindestens fünfstellige Eurobeträge.

Die Java-Community diskutierte im Jahr 2009 natürlich über die Übernahme von Sun Microsystems durch Oracle und darüber, welche Auswirkungen diese Entwicklung auf die Java-Plattform haben würde. Technisch beschäftigte sich die deutschsprachige Community im Java Magazin damit, ob REST oder SOAP für Web Services das richtige Paradigma wären (Abb. 1) oder ob man eher auf EJB 3.0 oder auf Spring 3.0 setzen sollte. OSGi war der Hoffnungsträger in Bezug auf feingranulare, modulare Architekturen, und im Enterprise-Bereich waren SOA und ESB die relevanten Themen.

Im Java Magazin und auf zahlreichen Konferenzen ließ sich beobachten, dass außerdem das Thema Agilität bzw. agile Softwareentwicklung mehr und mehr diskutiert wurde, aber noch viel erklärungsbedürftiger war als heute. In der Kolumne „Perspektivenwechsel“ im Java Magazin erhielten die Leser Tipps für die praktische Anwendung der noch relativ neuen Konzepte Scrum, Kanban, TDD oder XP. Die meisten agilen Ansätze blieben in der Realität des Jahres 2009 allerdings Insellösungen: Selbst wenn das Scrum-Team nach jedem Sprint ein Potentially Shippable Product Increment lieferte, schaffte es dieses Softwareartefakt allerhöchstens auf ein Entwicklungs- oder Testsystem. Die Auslieferung auf Integrations- oder gar Produktionssysteme fand viel seltener statt – oft nur einmal im Quartal.

Für diese Zeit war es revolutionär, dass die beiden Flickr-Mitarbeiter schon in ihrem Vortragstitel von zehn oder mehr Deployments am Tag (!) sprachen und eine Reihe von Tools und Eigenschaften ihrer Kultur vorstellten, um eine bessere Kooperation von Dev und Ops zu erreichen. Folgende Tooling-Aspekte zählten sie auf (Abb. 2):

1. Automated Infrastructure: Entgegen der zu dieser Zeit gängigen Praxis (manuelle Installation) plädierten die beiden für eine Provisionierung der Infrastruktur mit Werkzeugen wie Chef oder Puppet.

2. Shared Version Control: Die Skripte für die automatisierte Provisionierung der Infrastruktur sollten im selben Versionskontrollsystem wie der Anwendungscode liegen.

3. One Step Build and deploy: Ebenso wie die Provisionierung der Infrastruktur sollten auch Deployments in einem automatisierten und vor allem nachvollziehbaren Prozess stattfinden („Wer hat was zu welchem Zeitpunkt deployt“).

4. Feature flags: Die beiden argumentierten, dass man bei Webanwendungen andere Versionierungsansätze als bei Desktopsoftware brauchen würde, und plädierten für den Einsatz von Trunk Based Development und Feature-Flags [3].

5. Shared Metrics: Für diese Zeit revolutionär war auch der Ansatz, gemeinsame Systemmonitoringwerkzeuge für Entwicklung und Betrieb bereitzustellen.

6. IRC and IM robots war ein Vorläufer dessen, was später als ChatOps bekannt wurde.

Der wichtigste Ratschlag in kultureller Hinsicht war der des gegenseitigen Respekts. Nach wie vor bedeutet das insbesondere, mit Vorurteilen aufzuräumen und die jeweils andere Seite als Experten auf ihrem Gebiet anzuerkennen. Diese Expertise soll aber nicht zu geheimem Herrschaftswissen führen, vielmehr sollen alle Aspekte der Entwicklung und des Betriebs transparent werden (Einbindung von Ops in Featurediskussionen bzw. Einbindung von Dev bei Infrastrukturänderungen). Nur so entsteht Vertrauen, das unabdingbar für eine sinnvolle Kollaboration ist. Darüber hinaus sollten alle Beteiligten immer unterstellen, dass jeder sein Bestes für das Business gibt. Sie sind sich sicher, dass trotzdem Fehler passieren werden und es eine gesunde Fehlerkultur ohne Blaming geben muss.

Der Begriff DevOps tauchte in dem Flickr-Vortrag noch nicht auf, tatsächlich wurde das Thema noch im Jahr 2008 eher unter dem Begriff „Agile Infrastructure“ oder „Agile Systems Administration“ diskutiert. Der Begriff DevOps entstand später im Jahr 2009 auf einer Konferenz in Gent. Inspiriert durch den Vortrag von Allspaw und Hammond sowie durch seine eigenen Erfahrungen rief Patrick Debois die DevOps Days ins Leben [4]. Auch dort ging es sowohl um Tooling bzw. Automatisierung als auch um kulturelle Aspekte der Kollaboration (Abb. 3).

DevOps ist mehr als Tooling ...

Mit steigender Popularität wurde der Begriff DevOps immer häufiger mit Tooling bzw. Automatisierung gleichgesetzt – vor allem in den Marketingbotschaften. Dabei ging es aber in der Regel nicht um Tooling-Prinzipien, wie Allspaw und Hammond sie beschrieben hatten, sondern eher um das Versprechen, man müsse nur Tool XYZ einsetzen, um erfolgreich zu sein. Wie so oft stellte sich auch hier schnell Ernüchterung ein. Eine bessere Kollaboration und damit häufigere, stabile Softwareauslieferungen lassen sich eben nicht einfach durch ein Tool erreichen.

Das Buch „The Phoenix Project“ [5], das mittlerweile als Standardwerk der DevOps-Bewegung gilt, beschrieb einige Jahre später sehr anschaulich, dass DevOps vor allem einen Kulturwandel bedeutete. Die Geschichte spielt in der fiktiven Firma Parts Unlimited. Und obwohl es um das strategische IT-Projekt des Unternehmens und Herausforderungen des IT-Betriebs geht, dreht sich sehr wenig um konkrete Tools oder Technologien. Ich selbst war beim ersten Lesen sogar etwas überrascht, weil ich mehr grundlegend Neues erwartet hatte. Stattdessen kannte ich viele Ansätze des sehr gut geschriebenen Buches bereits aus Lean, Kanban etc. Auch hier stellt sich wie bei Allspaw und Hammond wieder die Frage, ob DevOps nicht einfach Agilität über die Softwareentwicklung hinaus bedeutet. Genau wie in der agilen Softwareentwicklung ist es nicht mit der Einführung eines Tools getan. Es handelt sich vielmehr um eine Reise, die kontinuierliche Anstrengungen bedeutet und eigentlich nie zu Ende ist.

Der „2018 State of DevOps Report“ [6], [7] versucht, diese Reise zu beschreiben und in sechs verschiedene Stationen zu gliedern. Stufe 0 ist sozusagen der ständige Reisebegleiter und zugleich die Grundlage einer DevOps-Reise. Die Inhalte dieser Stufe orientieren sich stark am sogenannten CAMS-Modell. CAMS bedeutet Culture, Automation, Measurement und Sharing (Abb. 4). Das Modell greift zahlreiche Aspekte wieder auf, die Allspaw und Hammond in ihrem Vortrag beschrieben haben. Automation bedeutet in diesem Zusammenhang die Automatisierung von Tests und konsequente CI/CD.

Auch wenn DevOps also in erster Linie als Kulturwandel zu verstehen ist, hat der technologische Fortschritt in den letzten Jahren diesen Wandel ohne Zweifel ermöglicht oder beschleunigt.

... aber Tools und Technologien sind Enabler für DevOps

Die kurze Rückblende am Anfang des Artikels enthielt auch das Thema OSGi. Diese Komponententechnologie versprach kleinere Komponenten, die sich leichter zur Laufzeit austauschen lassen. OSGi bedeutete damit eine Abkehr von der bisherigen Praxis, möglichst große Deployment-Artefakte zu bauen und auszuliefern. Im Jahr 2009 bestand eine Java-Anwendung in der Regel aus einer großen EAR-Datei, die in einem Application-Server deployt wurde. Neben diesen beiden gab es nur wenige, ebenfalls sehr große Anwendungskomponenten (z. B. Datenbank, Message Broker, ESB).

OSGi hat den Trend eingeleitet, wieder in vielen kleineren Deployment-Einheiten zu denken. Dieser Trend hat sich in den folgenden Jahren verstetigt, auch wenn OSGi heute nicht mehr die gleiche Rolle spielt. Eine moderne Anwendung besteht heute aus Dutzenden kleiner Einzelteile (Abb. 5). Bei diesen kleinen Einzelteilen handelt es sich oft um Microservices. Ein sehr kleiner Service kapselt eine oder wenige fachliche Problemstellungen (Bounded Context), enthält technisch aber alle notwendigen Bestandteile wie einen Webserver etc., um autonom einsatzfähig zu sein. Im Gegensatz zu OSGi-Modulen lassen sich diese Services viel einfacher unabhängig voneinander skalieren.

Ermöglicht wurde diese Entwicklung durch das Aufkommen von Containertechnologien – in erster Linie Docker. Container erlauben auf einfache Weise, alle notwendigen Softwarebestandteile (Applikationsartefakt, Webserver etc.) transportierbar in einen Container zu packen und ohne Installation auf einer beliebigen Basisplattform auszuführen. Das Java-Motto „Write once, run anywhere“ wird damit auf Betriebssystemebene angewendet. Für etliche Application-Server, Datenbanken etc. existieren fertige Images, die einfach um eigene Komponenten und Konfigurationen ergänzt werden können.

Der zweite Turbo für immer kleinteiliger werdende Anwendungsarchitekturen und vor allem deren Skalierung sind die Plattformen der führenden Public-Cloud-Anbieter. Vor rund zehn Jahren war die Bereitstellung von Rechenkapazität und Speicher ein langfristiges Investment und mit langen Vorlaufzeiten verbunden. Heute ist beides in der Cloud nur wenige Mausklicks entfernt und kann ebenso schnell wieder abgeschaltet werden. Interessanterweise gab es sogar schon einen Vortrag zu einem Cloudthema im Programm der DevOps Days in Gent.

Auch die Begriffe Rechenkapazität und Speicher passen eher zur IT-Infrastruktur-Welt des Jahres 2009 als in die heutige Zeit. Damals war es gängige Praxis, Root-Server zu mieten und dann einen Datenbankcluster, einen Suchindex, eine NoSQL-Datenbank oder einen Application-Server auf diesen Maschinen von Hand zu installieren und insbesondere dann später auch zu betreiben und zu patchen. Dieser Ansatz wird zunehmend durch Managed Services ersetzt. Statt den Datenbankserver selbst zu betreiben, wird er als Service gemietet. Der Managed-Service-Provider kann diesen Service in der Regel viel günstiger und sicherer anbieten als seine Kunden. Zum einen bedingt durch Skaleneffekte, zum anderen, weil die meisten Managed Services wieder auf Basis-Services der großen Public-Cloud-Anbieter wie AWS basieren. Mit Managed Services setzt sich ein Trend fort, der mit der Nutzung von Programmbibliotheken seinen Anfang genommen hat. Vor zehn Jahren haben die Softwareentwickler nach passenden Java-Bibliotheken gesucht, um nicht alles selbst entwickeln zu müssen. Heute suchen sie zusätzlich noch nach passenden Managed Services für Infrastrukturkomponenten. Solche Services existieren für alle denkbaren Anwendungsfälle (z. B. Messaging, Sprachausgabe, Caching, Authentication, relationale Datenbanksysteme, NoSQL-Datenbanken, Suchindizes, File Storage etc.). Managed-Services-Anbieter nehmen dem Kunden dabei immer mehr Arbeit ab. Manche Services, wie z. B. Heroku, gehen so weit, dass die Entwickler nur noch ihr Artefakt deployen müssen und nach wenigen Sekunden die laufende Webanwendung im Browser aufrufen können – auf Wunsch auch in einer geclusterten Version.

Der aktuelle Höhepunkt dieser Entwicklung ist Function as a Service (FaaS) – der bekannteste Vertreter aus dem Serverless-Umfeld. Im FaaS-Modell deployt der Kunde ein Stück Code, das dann zu bestimmten Ereignissen aufgerufen wird (Veränderungen in einem Clouddateisystem, einkommende Requests, asynchrone Nachrichten aus Messagingsystemen oder zeitgesteuert). Dem Kunden wir dabei nur die tatsächliche Ausführungszeit in Rechnung gestellt. Die Kosten für die Infrastruktur lassen sich so nahezu linear mit der Last auf der Anwendung skalieren.

Mit der Anzahl der Einzelteile einer Anwendung steigt der Bedarf der Orchestrierung dieser Teile. Es braucht ein Betriebssystem, auf dem z. B. Docker-Container betrieben werden können. Das bekannteste Betriebssystem für Container ist heute Kubernetes. Kubernetes bildet eine Schicht zwischen den Containern und den Maschinen, auf denen diese Container ausgeführt werden. Es kann Container anhand ihrer Anforderungen an Speicher, Disk oder Prozessor auf die passenden Maschinen verteilen, abgestürzte Container neu starten und unterstützt beim Update von Containern. Aufsetzend auf einem Betriebssystem wie diesem gibt es außerdem heute Service Meshes wie Istio, die bei der Verwaltung einer großen Anzahl von Microservices helfen.

Tooling – eher Praktiken als konkrete Tools

Der wichtigste Tooling-Grundsatz aus der Präsentation von Allspaw und Hammond war die Infrastrukturautomatisierung (Infrastructure as Code). Im Jahr 2009 war damit eher noch gemeint, mit Tools wie Chef oder Puppet auf einem Root-Server Komponenten wie einen Application-Server o. Ä. automatisiert zu installieren und mit den passenden Anwendungsartefakten zu bestücken. Dabei handelte es sich bereits um einen großen Fortschritt, wenn man sich überlegt, dass diese Installationen vorher in der Regel manuell durchgeführt wurden. Eine Automatisierung erhöht die Geschwindigkeit, reduziert Fehler und erlaubt z. B. Entwicklungsteams, produktionsgleiche Testumgebungen zu haben. Außerdem werden Änderungen an den Infrastrukturkomponenten so für alle nachvollziehbar. Ist doch mal ein Fehler passiert, lassen sich die Änderungen zurückrollen oder die komplette Umgebung lässt sich von Grund auf neu aufsetzen. Letzteres war 2009 weitgehend undenkbar. Die meisten Serverumgebungen waren irgendwann einmal aufgesetzt worden und wurden dann sukzessive erweitert. Gab es Probleme mit der Umgebung, wurde sie von den Ops-Mitarbeitern regelrecht gesund gepflegt. Man sagt heute dazu, dass die Umgebungen wie Haustiere behandelt und gehätschelt werden [8]. Mit dem Aufkommen von Virtualisierungs- und vor allem von Public-Cloud-Lösungen ist es sehr viel einfacher geworden, fehlerhafte Infrastrukturkomponenten zu stoppen und durch neue zu ersetzen. Mit Infrastructure as Code rückt dabei die programmatische Beschreibung der Infrastruktur in den Vordergrund, weil in der Cloud beliebig viele Kopien davon erzeugt werden können. In diesem Vorgehen werden die Infrastrukturkomponenten als Nutzvieh bezeichnet. Die Cloud schützt aber nicht vor Haustierinfrastruktur. Auch hier gibt es immer wieder Komponenten, die schnell manuell in der Weboberfläche erstellt wurden.

Durch den gestiegenen Einsatz von Managed Services hat sich der Fokus von Infrastructure as Code in den letzten Jahren verschoben. Chef und Puppet sind noch sehr programmatisch bzw. ablauforientiert – nicht ohne Grund heißen die Artefakte in Chef Rezepte. Die Infrastructure-as-Code-Artefakte für Managed Services sind hingegen eher deskriptiv und beschreiben den gewünschten Zielzustand.

Es gibt immer wieder Firmen, in denen DevOps mit Infrastrukturautomatisierung gleichgesetzt wird. Entsprechende Initiativen beschränken sich auf diesen Aspekt oder beginnen zumindest damit, die Bereitstellung von Infrastruktur zu automatisieren. Laut „State of DevOps Report 2018“ sind diese Initiativen in der Regel zum Scheitern verurteilt. So ist es z. B. wenig zielführend, in Infrastrukturautomatisierung zu investieren, wenn es im Unternehmen eine Vielzahl unterschiedlicher Technologiestacks gibt. Im bereits angesprochenen sechsstufigen Modell der DevOps-Reise aus demselben Report ist Infrastrukturautomatisierung demnach auch erst der vorletzte Schritt [6], [7]. Vorher ist es für das Unternehmen wichtig, seinen Technologiestack auf eine möglichst kleine Anzahl von Standardkomponenten zu reduzieren (Abb. 6).

Überraschenderweise sind einige der Praktiken von Allspaw und Hammond auch rund zehn Jahre später nicht flächendeckend umgesetzt. So gibt es auf der einen Seite noch Firmen, die keine sinnvolle automatisierte Testbasis haben und von echter Continuous Integration bzw. Continuous Delivery [3] noch weit entfernt sind. Andere Firmen haben das agile Mantra hinter CI, „Wenn etwas schmerzhaft und aufwendig ist, tue es früh und oft“ verinnerlicht und holen das Thema Security mit DevSecOps aus seinem Stiefkindstatus, wie es Jahre zuvor mit dem Thema automatisierte Tests passiert ist. Auch ein gemeinsames Monitoring gibt es in etlichen Firmen noch nicht.

DevOps – eine Kultur der Kollaboration und Transparenz

Dabei ist vor allem ein gemeinsames Monitoring für eine bessere Kollaboration zwischen Softwareentwicklung und -betrieb überaus wichtig. Und die Stärkung der Kollaboration zwischen Dev und Ops bleibt das Kernstück der DevOps-Philosophie. Wie sollen diese beiden Gruppen aber besser miteinander kollaborieren, wenn sie bislang getrennte Wege in unterschiedlichen Silos gegangen sind? Darauf gibt es nicht die eine richtige Antwort und es heißt auch nicht zwangsläufig, dass die Ops-Teams aufgelöst werden müssen. Matthew Skelton hat eine Webseite aufgebaut, auf der er zahlreiche verschiedene Patterns und Antipatterns beschreibt [9]. Dabei sind nach meiner Meinung die folgenden drei am häufigsten anzutreffen:

• Ein Team aus Dev und Ops: Die vorher getrennten Teams verschmelzen zu einem Team und übernehmen zukünftig gemeinsam die Entwicklung und den Betrieb der Anwendung (Abb. 7). Dieses Modell kommt dem Leitsatz „You build it, you run it“ von Werner Vogels, dem CTO von Amazon, am nächsten.

• Kollaboration: Dev und Ops kollaborieren z. B. über Hospitationsmodelle miteinander bzw. nehmen gegenseitig an Meetings wie Sprint Planning oder Stand-up teil (Abb. 8). Außerdem stellt das Dev-Team ordentliche Run Books etc. für das Ops-Team bereit.

Infrastructure as a Service: Das Ops-Team stellt Services bereit, die das Entwicklungsteam selbstständig verwenden kann. Dafür muss das Ops-Team nicht zur selben Firma gehören, sondern kann z. B. bei einem Cloudanbieter sitzen (Abb. 9).

Ein gängiges Antipattern ist in der Realität leider auch häufig anzutreffen. Die beiden Teams für Dev und Ops bleiben bestehen und haben keinen direkten Kontakt zueinander. Zwischen den beiden steht ein DevOps-Team, das für Infrastrukturautomatisierung etc. zuständig ist.

Google hat mit dem Site Reliability Engineering ein weiteres Muster für sich entwickelt, das mittlerweile auch von anderen Firmen übernommen wurde. Die Kernidee dieses Konzepts ist, Ops-Teams aus Software Engineers zu bilden. Software Engineers haben laut Google ein intrinsisches Interesse daran, Abläufe zu automatisieren und zu verbessern. Dadurch sollen Anwendungen entstehen, die sich im Wesentlichen ohne menschliches Zutun selbst überwachen und im Notfall heilen. Aus diesem Grund darf ein SRE-Team auch maximal 50 Prozent seiner Zeit für die Behebung von Incidents oder andere klassische Ops-Tätigkeiten aufwenden. Der Großteil der Zeit muss in Automatisierungen und Verbesserungen fließen.

Ein weiteres Konzept aus dem Site Reliability Engineering ist das des Error Budgets. Dabei geht man davon aus, dass nahezu keine Softwareanwendung eine Verfügbarkeit von 100 Prozent benötigt. Was allein schon deshalb sinnvoll ist, weil Infrastrukturkomponenten wie WLAN, Mobilfunknetz, Internetanschluss etc., die zwischen dem Nutzer und der Anwendung liegen, auch keine solch hohe Verfügbarkeit haben. Wenn die Verfügbarkeit also kleiner als 100 Prozent ist, wird sie meist über die Anzahl der Neuner hinter dem Komma definiert (je mehr, desto teurer). Die Differenz zwischen 100 Prozent und der angestrebten Verfügbarkeit ist das Error Budget (quasi eine prognostizierte Nichtverfügbarkeit). Diese Zeit kann für geplante Downtimes verwendet werden, wird aber auch durch ungeplante Ausfälle reduziert.

An der Einstellung zu Ausfällen und Fehlern zeigt sich ein grundlegender Unterschied zum Jahr 2009. Der IT-Betrieb hatte traditionell das Ziel, Ausfälle und Fehler auf null zu reduzieren. In Zeiten komplexer, verteilter Infrastruktur können Ausfälle und Fehler nicht mehr (zu sinnvollen Kosten) ausgeschlossen werden, deshalb versucht man den Umgang damit zu professionalisieren. Dazu gehört zum einen das absichtliche Provozieren von Ausfällen im Chaos Engineering (Ausfall oder Beeinträchtigungen von Infrastrukturkomponenten) und zum anderen eine gesunde Fehlerkultur, wie sie auch schon Allspaw und Hammond in ihrem Vortrag thematisierten. Eine solche Kultur bedeutet, dass man akzeptiert, dass Fehler passieren, man aber trainiert, sinnvoll mit ihnen umzugehen und aus ihnen zu lernen. Ein Mittel dafür sind sogenannte Blameless Post-mortems. Dabei handelt es sich um spezielle Retrospektiven, die einem festen Muster folgen [11]. Die Ergebnisse werden dokumentiert und als Lernmaterial allen anderen Teams in der Organisation zur Verfügung gestellt.

Ein Team, das ein Blameless Post-Mortem durchführt, steht vor der Herausforderung, den Ablauf eines Incidents und die verschiedenen Einflussfaktoren lückenlos zu rekonstruieren. Besonders einfach wird diese Forensik, wenn man wie GitHub alle Deployments, Metriken etc. im Group-Chat-Tool abgebildet hat. Dieses Vorgehen wird als Chat Ops bezeichnet, und wir erinnern uns, dass auch der Vortrag von Allspaw und Hammond eine Vorstufe davon enthielt.

Fazit und Ausblick

Wenn wir auf die Anfänge der DevOps-Bewegung im Jahr 2009 zurückschauen, hat sich im technischen Bereich vieles verändert. Kulturell und methodisch sind die Gedanken insbesondere von Allspaw und Hammond überraschend aktuell.

Doch zunächst zu den technischen Aspekten. Sebastian Meyen schreibt im Editorial des Java Magazins 6.2009:

„Die Idee, das Thema Hardware und Basisinfrastruktur im Sinne des Cloud Computings zu organisieren, wird sich indes ohne Zweifel durchsetzen. Bis dahin ist aber noch ein steiniger Weg zu gehen. Noch existiert kein Konsens, wie viel und in welcher Weise z. B. Java unterstützt werden soll, noch haben sich die Cloud-Anbieter nicht auf gemeinsame Standards geeinigt, um größtmögliche Kompatibilität zu erzielen. Die Cloud-Revolution steht gerade erst am Anfang und es konkurrieren vor allem hochproprietäre Angebote um die Gunst der Kunden.“

Zehn Jahre später gibt es kaum noch Unternehmen, die sich nicht mit dem Thema Cloud auseinandersetzen (müssen). Gemeinsame Industriestandards sind dabei nicht direkt entstanden. Mittlerweile schickt sich aber Kubernetes an, der De-facto-Standard als Cloudbetriebssystem zu werden.

Anders als im Jahr 2009 bedeutet Cloud-Computing heute immer seltener, Rechenleistung und Storage in Form von virtuellen Servern zu mieten und dort Infrastrukturkomponenten zu installieren. Stattdessen mieten Unternehmen zunehmend sogenannte Managed Services wie Datenbanken, Webserver etc., bei denen sich der Anbieter um Skalierbarkeit, Ausfallsicherheit und das Patching kümmert. Dieser Trend wird sich in den nächsten Jahren verstetigen. Damit folgt die Entwicklung im Infrastrukturbereich der in der Softwareentwicklung. Genauso wie eine moderne Anwendung heute zum größten Teil aus fremdem Code in Form von Libraries besteht, werden auch mehr und mehr Infrastrukturkomponenten durch Managed Services ersetzt. Am Ende wird nur eine sehr schmale Schicht mit anwendungsspezifischen Aspekten übrigbleiben. Das klingt eigentlich wie das hohe Ziel der Softwareentwicklung: Die Entwickler können sich vollständig auf ihre Businesslogik konzentrieren und alle anderen Aspekte werden ihnen abgenommen. Mit diesem Anspruch waren auch Enterprise JavaBeans (EJBs) seinerzeit angetreten. Genau wie bei EJBs ist die Komplexität aber nicht verschwunden, sondern wandert an andere Stellen – damals in die komplexen XML-Deployment-Deskriptoren, heute in die komplexen Infrastructure-as-Code-Beschreibungen. Es bleibt dabei, dass sich Komplexität in der IT nicht abschaffen, sondern nur verschieben lässt.

Dies soll kein Plädoyer gegen Infrastructure as Code sein – im Gegenteil. Schon 2009 forderten Allspaw und Hammond die Automatisierung von Infrastruktur ein. Daraus ergeben sich viele Vorteile. Neue Umgebungen können innerhalb kürzester Zeit erzeugt werden, Deployments sind sicherer und für alle nachvollziehbar und sorgen dafür, dass wir uns von den Haustieren in der IT verabschieden.

Infrastrukturautomatisierung ist einer der offensichtlichsten Teile der DevOps-Philosophie und wird relativ gut durch Tools unterstützt. Aus diesem Grund gibt es leider immer noch Unternehmen, die Infrastrukturautomatisierung und DevOps gleichsetzen. Dabei können Initiativen in diesem Bereich nur erfolgreich sein, wenn vorher bestimmte Hausaufgaben wie die Bereinigung der Technologiestacks durchgeführt werden.

Noch häufiger wird allerdings die kulturelle Seite der DevOps-Idee vergessen, deren Grundstein Allspaw und Hammond schon 2009 legten. Ein wichtiges Prinzip der DevOps-Kultur ist das transparente Teilen von Informationen. Das beginnt mit den gemeinsamen Metriken, geht weiter über das CAMS-Modell, in dem das S für Sharing steht, und findet sich heute auch in Praktiken wie Blameless Post-Mortems oder ChatOps wieder. Das zweite Prinzip, das sich wie ein roter Faden durch alle erfolgreichen DevOps-Ansätze zieht, ist eine gesunde Fehlerkultur. In modernen Organisationen akzeptieren wir heute, dass Fehler passieren können und werden. Wir versuchen, möglichst gut damit umzugehen.

Diese beiden Prinzipien sind das Fundament einer vertrauensvollen Kollaboration zwischen Dev und Ops, um gemeinsam das Business voranzubringen. Wenn diese Kollaboration sich erfolgreich entwickelt und die beiden Silos verschmelzen, werden oft die anderen Silos in der Organisation sichtbar, die sich rund um Dev und Ops befinden: Fachbereiche, Produktmanagement, Support, Marketing, Sales. Die DevOps-Reise macht in diesem Fall nicht halt, sondern versucht, immer mehr Silos in der Organisation aufzulösen, um das Business erfolgreich zu machen. So entstehen mit der Zeit echte cross-funktionale Produktteams.

Technologisch haben sich viele Firmen bereits auf die DevOps-Reise begeben und erste Fortschritte gemacht, in kultureller Hinsicht gibt es aber etliche, die noch am Anfang der Reise stehen.