10 Jahre DevOps: Wie groß du doch geworden bist!

DevOps hat sich in 10 Jahren von einer Grassroots-IT-Protestbewegung zur etablierten Enterprise-Strategie entwickelt. Unser Autor Schlomo Schapiro war von Anfang an dabei. Ein Rückblick aus persönlicher Perspektive und ein Ausblick in die Zukunft.

In Pocket speichern vorlesen Druckansicht 108 Kommentare lesen
10 Jahre DevOps: Wie groß du doch geworden bist!
Lesezeit: 13 Min.
Von
  • Schlomo Schapiro
Inhaltsverzeichnis

Getreu dem Motto, ein Thema ist dann ein Thema, wenn es eine Konferenz dazu gibt, zählt die Konferenzreihe DevOpsDays, die 2009 in Gent ihren Anfang nahm, als wichtiges Barometer zum Thema DevOps. Der Begriff, der vor 2009 nicht anzutreffen war, hat sich seitdem zum Goldstandard für den Umgang mit betrieblichen Herausforderungen in der IT-Branche gemausert. Patrick Debois, der die Konferenzreihe damals begründete, gilt daher als einer der Urväter der DevOps-Bewegung.

Die DevOpsDays-Konferenz hat sich von einem kleinen Treffen von Enthusiasten zu einem weltweiten Community-getriebenen Konferenz-Franchise entwickelt, das immer noch Akzente setzt. Während viele kommerzielle Konferenzen den DevOps-Begriff für sich übernommen haben und damit die vielen "DevOps-Tools" befeuern, unterscheiden sich die DevOpsDays-Konferenzen davon wohltuend und legen den Fokus auf die zwischenmenschlichen Seiten der Thematik. Die rasante weltweite Expansion der Konferenz – neben vielen anderen ähnlich benannten Veranstaltungen – unterstreicht nur die Relevanz des Themas. 2019 gibt es insgesamt 80 Events – fast jede Woche finden mehrere DevOpsDays-Konferenzen irgendwo auf der Welt statt.

Erfreulicherweise finden sich heute, insbesondere bei jüngeren Kollegen, zunehmend mehr Leute, die die Zeit vor DevOps gar nicht mehr bewusst erlebt haben: Eine strikte Trennung des IT-Personals nach Aufgabenbereichen und damit einhergehend viele Übergabepunkte zwischen Teams oder Abteilungen: Produktmanager, Business-Analysten, Architekten, Entwickler, Tester, Release-Manager, Administratoren und Betriebsführer mussten sich abstimmen, um ein Stückchen Software zu planen, zu entwickeln, zu testen, in Betrieb zu nehmen, zu betreiben und regelmäßig zu warten.

Dabei wurde sehr viel Papier – oder Wiki-Seiten – vollgeschrieben, um die einzelnen Übergaben abzuwickeln und zu dokumentieren. Die viel zitierte Mauer zwischen Development (Dev) und Operations (Ops) bestand wirklich und war gelebte Realität. Heute lässt sich diese Arbeitsweise nur noch in wenigen Branchen live erleben, es sind vor allem streng regulierte Branchen, die erst jetzt langsam ihre Arbeitsprozesse reformieren.

Die Frage nach der DevOps-Definition hat sich über die Jahre natürlich verändert. Am Anfang stand die Anwendung agiler Prinzipien – wie sie das Agile Manifesto schon 2001 definiert hat – sowohl in der Softwareentwicklung, im Projektmanagement als auch im Betrieb im Vordergrund. "Bridging the gap between projects and operations by using agile techniques both in development, project management and system administration", erklärte Debois DevOps 2010 auf den ersten DevOpsDays in Hamburg, die der Autor besuchte und für heise Developer beschrieb. "DevOps" ist somit der Zusammenschluss aus Dev und Ops. Die Automation von Betriebsaufgaben als Infrastructure as Code war der Weg, um Arbeitsweisen und Herangehensweisen aus der Dev in die Ops zu bringen und um der damals allgegenwärtigen Handarbeit entgegenzutreten. Die Vortragsthemen von 2009 über Kanban im Betrieb, User Stories für nichtfachliche Anforderungen, Automatisierungswerkzeuge wie Puppet oder DevOps CI/CD Pipelines finden sich auch heute noch in ähnlicher Form auf jeder DevOps-Konferenz.

Der Autor war damals für ImmobilienScout24 (IS24) tätig, dort fielen die Ideen auf fruchtbaren Boden und bildeten den Grundstock für die Neuentwicklung der Betriebsautomation von IS24 im Rechenzentrum.

Anfang 2011 waren die Grundsätze schon entschieden, der Autor erklärte damals DevOps auf dem 1. Berliner DevOps Meetup mit diesen zwei Bildern:

Während früher Dev und Ops getrennt arbeiteten, dieselben Probleme wie das Deployment in Entwicklung und Produktion unterschiedlich lösten und sich über Wiki und E-Mail abstimmten, arbeiten in der neuen Welt alle gemeinsam an der Software, die dann gleichermaßen überall deployt wird. Die Abstimmung über Wikis und E-Mails entfiel zugunsten einer technischen Abstimmung in Form von installierbarer Software: RPM-Pakete für Linux. Statt Unstimmigkeiten und Missverständnissen konnte jetzt jeder selbst die Software testen und verbessern, bis es überall perfekt lief.