Hey Habr! Ich präsentiere Ihnen die Übersetzung des Artikels von Steve Mezak.
Abhängig von Ihrer Sichtweise feiert DevOps in diesem Jahr sein neuntes oder zehnjähriges Jubiläum. Im „State of the Cloud“-Bericht von RightScales aus dem Jahr 2016 wurde festgestellt, dass 70 Prozent der KMU DevOps-Praktiken übernehmen. Jeder Indikator, der diesen Wert ausmacht, ist seitdem gestiegen. Während sich DevOps auf das zweite Jahrzehnt vorbereitet, wäre es großartig, einen Spaziergang durch die Vergangenheit zu machen und zu den Ursprüngen von DevOps zurückzukehren – und sogar zu den Ursprüngen des Namens selbst.
Vor 2007: Eine perfekte Ereigniskette
Vor 2007 führten eine Reihe von Umständen schließlich zu dem, was heute als DevOps bekannt ist.
Mager hat sich bereits als Best Practice bewährt. Auch bekannt als Toyota-ProduktionssystemLean Manufacturing ist bestrebt, die Prozesse in der Fertigung zu optimieren. (Übrigens ließ sich das Toyota-Management zunächst von den ursprünglichen Fließbandmethoden der Ford Motor Company inspirieren.) Ständige Verbesserung ist das Mantra für Lean Manufacturing. In der Praxis werden folgende Wege ständig evaluiert:
- Halten Sie die Lagerbestände an Rohstoffen und Fertigprodukten auf ein Minimum. Unter Lean Manufacturing versteht man einen Mindestbestand an Rohstoffen zur Herstellung von Waren und eine Mindestmenge an Fertigprodukten, die auf Bestellung oder Versand warten.
- Minimierung der Bestellwarteschlange. Im Idealfall gehen eingegangene Bestellungen sofort in den abgeschlossenen Zustand über. Die entscheidende Messgröße für Lean Manufacturing wird immer die Zeit vom Auftragseingang bis zur Auslieferung sein.
- Maximierung der Effizienz des Produktionsprozesses. Prozessumgestaltung und verbesserte Automatisierung tragen dazu bei, Waren so schnell wie möglich herzustellen. Jeder Produktionsbereich entlang des gesamten Prozesses (Schneiden, Schweißen, Montage, Prüfung usw.) wird auf Ineffizienzen überprüft.
In der IT-Welt sind traditionelle Methoden des Wasserfallmodells der Softwareentwicklung bereits schnellen iterativen Methoden wie z Agil. Geschwindigkeit war das Motto, auch wenn die Qualität im Streben nach schneller Entwicklung und Bereitstellung manchmal litt. Ähnlich verhält es sich insbesondere mit Cloud Computing Infrastruktur als ein Service (IaaS) und Plattform-als-Service (PaaS) haben sich als ausgereifte Lösungen in IT-Prozessen und Infrastruktur bewährt.
Schließlich gibt es seit Kurzem auch Toolkits für Kontinuierliche Integration (CI). Die Idee der CI-Tools wurde bereits 1991 von Gradi Booch in seiner Booch-Methode geboren und vorgestellt.
2007–2008: Enttäuschter Belgier
Der belgische Berater, Agile-Projekt- und Praxismanager Patrick Debois hat einen Termin von einem belgischen Ministerium angenommen, um bei der Migration von Rechenzentren zu helfen. Insbesondere war er an der Zertifizierung und den Bereitschaftstests beteiligt. Zu seinen Aufgaben gehörte die Koordinierung und der Aufbau von Beziehungen zwischen Softwareentwicklungsteams und Server-, Datenbank- und Netzwerkbetriebsteams. Seine Frustration über den mangelnden Zusammenhalt und die Mauern, die Entwicklungs- und Betriebsmethoden trennten, machten ihn verbittert. Desbois‘ Wunsch, sich zu verbessern, veranlasste ihn bald zum Handeln.
Auf der Agile-Konferenz 2008 in Toronto schlug Andrew Schaefer vor, ein speziell arrangiertes informelles Treffen zu moderieren, um das Thema zu diskutieren.Agile Infrastruktur„Und nur eine Person kam, um das Thema zu diskutieren: Patrick DeBois. Ihre Diskussion und ihr Ideenaustausch brachten das Konzept der agilen Systemadministration voran. Im selben Jahr gründeten DeBois und Schaefer die mäßig erfolgreiche Agile Systems Administrator-Gruppe bei Google.
2009: Der Fall der Zusammenarbeit zwischen Dev und Ops
Auf der O'Reilly Velocity-Konferenz hielten zwei Flickr-Mitarbeiter, Senior Vice President of Technical Operations John Allspaw und CTO Paul Hammond, die mittlerweile berühmte Präsentation „10 Bereitstellungen pro Tag: Dev- und Ops-Zusammenarbeit bei Flickr“.
Die Präsentation war ein Drama, bei dem Allspaw und Hammond die komplexen Interaktionen zwischen Entwicklungs- und Betriebsvertretern während des Softwarebereitstellungsprozesses nachstellten, komplett mit Schuldzuweisungen und Vorwürfen wie „Es ist nicht mein Code, es sind alle Ihre Computer!“ Ihre Präsentation bestätigte, dass die einzig sinnvolle Option darin besteht, dass Softwareentwicklungs- und Bereitstellungsaktivitäten nahtlos, transparent und vollständig integriert sind. Im Laufe der Zeit wurde diese Präsentation legendär und gilt heute als bahnbrechender Meilenstein, als die IT-Branche begann, die Methodik zu fordern, die heute als DevOps bekannt ist.
2010: DevOps in den Vereinigten Staaten von Amerika
Die DevOpsDays-Konferenz erfreute sich einer wachsenden Fangemeinde und fand unmittelbar im Anschluss an die jährliche Velocity-Konferenz zum ersten Mal in den Vereinigten Staaten in Mountain View, Kalifornien, statt. Spulen wir vor ins Jahr 2018: Es sind mehr als 30 DevOpsDays-Konferenzen geplant, darunter Dutzende in den Vereinigten Staaten.
2013: Projekt „Phoenix“
Für viele von uns war die Veröffentlichung des Buches „The Phoenix Project“ von Gene Kim, Kevin Behr und George Safford ein weiterer bemerkenswerter Moment in der Geschichte von DevOps. Dieser Roman erzählt die Geschichte eines IT-Managers, der sich in einer verzweifelten Situation befindet: Er hat die Aufgabe, ein kritisches E-Commerce-Projekt zu retten, das fehlgeschlagen ist. Der geheimnisvolle Mentor des Managers – ein Vorstandsmitglied, das sich leidenschaftlich für Lean-Manufacturing-Methoden einsetzt – schlägt dem Protagonisten neue Denkweisen über IT und Anwendungsentwicklung vor und nimmt damit das Konzept von DevOps vorweg. Übrigens hat uns „The Phoenix Project“ dazu inspiriert, das Buch „Outsource or else...“ über eine ähnliche Geschäftsgeschichte zu schreiben, in der ein Software-Vizepräsident DevOps bei der Entwicklung eines neuen großen ausgelagerten Produkts einsetzt.
DevOps für die Zukunft
Es lohnt sich, DevOps als eine Reise oder vielleicht als einen Wunsch und nicht als ein endgültiges Ziel zu beschreiben. DevOps strebt wie Lean Manufacturing nach kontinuierlicher Verbesserung, erhöhter Produktivität und Effizienz und sogar nach kontinuierlicher Bereitstellung. Automatisierte Tools zur Unterstützung von DevOps entwickeln sich ständig weiter.
Seit der Einführung von DevOps im letzten Jahrzehnt wurde viel erreicht, und wir gehen davon aus, dass wir 2018 und darüber hinaus noch mehr sehen werden.
Source: habr.com