Hallo, Habr! Ich präsentiere Ihnen die Übersetzung des Artikels „Die Ursprünge von DevOps: Was steckt in einem Namen?“ Autor Steve Mezak.

Je nach Perspektive wird DevOps in diesem Jahr sein neuntes oder zehntes Jubiläum feiern. Im Jahr 2016 stellte der Bericht von RightScale über den Stand der Cloud fest, dass 70 Prozent der kleinen und mittelständischen Unternehmen DevOps-Methoden übernehmen. Jeder Bestandteil dieser Schätzung hat sich seitdem erhöht. Während DevOps bereit ist, sein zweites Jahrzehnt zu beginnen, wäre es spannend, die Gassen der Vergangenheit zu erkunden und zu den Wurzeln von DevOps zurückzukehren – und sogar zum Ursprung des Namens selbst.

Bis 2007: Die perfekte Abfolge von Ereignissen

Bis zum Jahr 2007 führte eine Reihe von Umständen letztendlich zur Entstehung dessen, was heute als DevOps bekannt ist.

Lean Production hat sich bereits als Best Practice etabliert. Auch bekannt als Toyota Produktionssystem, zielt Lean Production darauf ab, Prozesse in der Fertigung zu optimieren. (Übrigens war die ursprüngliche Führung von Toyota von den ursprünglichen Methoden der Fließbandfertigung inspiriert, die von der Ford Motor Company eingeführt wurden.) Kontinuierliche Verbesserung — ist das Mantra der schlanken Produktion. In der Praxis werden stets folgende Wege bewertet:

1. Die Unterstützung des Lagerbestands an Rohmaterialien und Fertigwaren auf einem Minimum. Schlanke Produktion bedeutet, dass nur die minimalen Mengen an Rohmaterialien für die Produktion von Waren und die minimalen Mengen an bereits fertigen Produkten, die auf die Verteilung oder den Versand warten, vorhanden sind.
2. Minimierung der Auftragswarteschlangen. Idealerweise sollten die erhaltenen Bestellungen sofort den Status „abgeschlossen“ erreichen. Eine Schlüsselmetrik der schlanken Produktion wird stets die Zeit vom Eingang der Bestellung bis zur Lieferung sein.
3. Maximierung der Effizienz des Produktionsprozesses. Die Reorganisation von Prozessen und verbesserte Automatisierung werden kombiniert, um die Produktion von Waren so schnell wie möglich zu gestalten. Jedes Fertigungssegment auf dem gesamten Weg (Schneiden, Schweißen, Montage, Testen usw.) wird auf Ineffizienzen überprüft.

In der IT haben traditionelle Methoden des Wasserfallmodells der Softwareentwicklung bereits den schnellen iterativen Methoden Platz gemacht, wie zum Beispiel Agile. Geschwindigkeit war ein Kampfaufruf, selbst wenn die Qualität manchmal auf der Jagd nach schneller Entwicklung und Bereitstellung litt. Ähnlich haben sich Cloud-Computing, insbesondere Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) als ausgereifte Lösungen in den Prozessen und der IT-Infrastruktur etabliert.

Schließlich sind kürzlich Werkzeugsätze für Continuous Integration (CI) entstanden. Das Konzept von CI-Tools wurde 1991 von Grady Booch in seiner Booch-Methode geboren und vorgestellt.

2007-2008: Ein enttäuschter Belgier

Der belgische Berater, Projektmanager und Agile-Praktiker Patrick Debois erhielt einen Auftrag der belgischen Regierungsbehörde, um bei der Migration von Rechenzentren zu helfen. Insbesondere war er für die Zertifizierung und die Überprüfung der Bereitschaft zuständig. Seine Aufgaben erforderten die Koordination von Aktionen und den Aufbau von Beziehungen zwischen Software-Entwicklungsteams und Betriebsgruppen. Server, Datenbanken und Netzwerke. Seine Enttäuschung über das Fehlen von Kohäsion und den Mauern, die die Entwicklungs- und Betriebsansätze trennten, brachte ihn zum Nachdenken. Der Wunsch nach Verbesserung führte Debois bald zum Handeln.
Im Jahr 2008 schlug Andrew Schaffer auf einer Agile-Konferenz in Toronto vor, ein informelles Treffen zu moderieren, um das Thema "Agile-Infrastruktur" zu diskutieren. Nur eine Person erschien, um das Thema zu besprechen: Patrick Debois. Ihr Austausch und die Diskussionen trugen zur Weiterentwicklung des Konzepts der Agile-Systemadministration bei. Im selben Jahr gründeten Debois und Schaffer die moderat erfolgreiche Gruppe Agile Systems Administrator bei Google.

2009: Die Zusammenarbeit zwischen Dev und Ops

Auf der O’Reilly Velocity Konferenz präsentierten zwei Mitarbeiter von Flickr, der Vice President of Technical Operations John Allspaw und CTO Paul Hammond, die mittlerweile berühmte Präsentation „10 Deployments pro Tag: Zusammenarbeit zwischen Dev und Ops bei Flickr“.

Die Präsentation war im dramatischen Stil gehalten, Allspaw und Hammond spielten komplexe Interaktionen zwischen Vertretern von Development und Operations während des Software-Deployments nach, begleitet von der Suche nach Schuldigen und gegenseitigen Beschuldigungen im Sinne von „Das ist nicht mein Code, das sind alles deine Server!“ Ihre Präsentation bestätigte, dass der einzig sinnvolle Ausweg darin bestand, den Prozess der Software-Entwicklung und -Bereitstellung reibungslos, transparent und vollständig integriert zu gestalten. Im Laufe der Zeit wurde diese Präsentation legendär und wird nun historisch als ein grundlegender Meilenstein angesehen, als in der IT-Branche die Nachfrage nach der Methodik entstand, die heute als DevOps bekannt ist.

2010: DevOps in den USA

Mit dem Wachstum der Anhängerschaft fand die DevOpsDays-Konferenz erstmals in den USA in Mountain View, Kalifornien, direkt nach der jährlichen Velocity-Konferenz statt. Reisen wir ins Jahr 2018: Über 30 DevOpsDays-Konferenzen sind geplant, darunter Dutzende in den USA.

2013: Projekt Phoenix

Für viele von uns war die Veröffentlichung des Buches „Das Phoenix-Projekt“ von Gene Kim, Kevin Behr und George Spafford ein bemerkenswerter Moment in der Geschichte von DevOps. In diesem Roman wird die Geschichte eines IT-Managers erzählt, der sich in einer ausweglosen Situation befindet: Er soll ein kritisches E-Commerce-Projekt retten, das schiefgelaufen ist. Ein geheimnisvoller Mentor des Managers – ein Mitglied des Vorstands, das von Lean-Methoden besessen ist – gibt dem Protagonisten Anregungen, neue Wege des Denkens über IT und Anwendungsentwicklung zu finden, und antizipiert damit das Konzept von DevOps. Übrigens hat „Das Phoenix-Projekt“ uns inspiriert, das Buch „Outsourcing, sonst...“ über eine ähnliche Geschichte im Geschäft zu schreiben, in der der Vizepräsident für Software DevOps bei der Entwicklung eines neuen Großprodukts im Outsourcing nutzt.

DevOps für die Zukunft

DevOps lässt sich eher als eine Reise oder vielleicht als eine Bestrebung beschreiben, als als ein endgültiges Ziel. Ähnlich wie in der Lean-Produktion strebt DevOps nach kontinuierlicher Verbesserung, Produktivitätssteigerung und Effizienz sowie nach einem ständigen Einsatz. Automatisierte Werkzeuge zur Unterstützung von DevOps entwickeln sich ständig weiter.

Seit der Einführung von DevOps im letzten Jahrzehnt wurde bereits viel erreicht, und wir erwarten, auch 2018 und in Zukunft noch mehr zu sehen.

Quelle: habr.com