Heutzutage fällt es uns so schwer, DevOps zu definieren, da das Problem, das es ursprünglich löst, längst verschwunden ist.  Für einige neuere Unternehmen bestand das Problem nie wirklich! Sie machen alles richtig, aber stattdessen hat sich die Softwareentwicklungslandschaft so schnell entwickelt, dass die Lücke durch Tools und Cloud-Engineering geschlossen wurde.  Die Anfänge von DevOps und seinem Kulturwandel mit dem Ziel, die Silos zwischen Dev und Ops aufzubrechen, sind noch weit entfernt.  Die Dev- und Ops-Silos  Im Jahr 2008, als  Als er zum ersten Mal an DevOps dachte, betrachtete er die ineffektive Zusammenarbeit zwischen Entwicklung und Betrieb in einem Kontext, in dem das Projektmanagement gerade von der Wasserfallmethode auf Agile umgestellt worden war.   Patrick Dubois  Die damaligen Betriebsteams verwalteten alles, von Netzwerken, Servern, virtuellen Maschinen, Betriebssystemen bis hin zu Software-Updates. Dadurch wurden viele manuelle Vorgänge effektiv ausgeblendet. Nicht alles war manuell, aber das war, bevor es Puppet, Chef und Ansible – oder sogar Terraform – gab.  Die Verwaltung von Server- und Softwareversionen war keine einfache Aufgabe und erforderte viel Fachwissen. Dies verhinderte die schnelle und zuverlässige Bereitstellung neuer Softwareversionen.   Die Cloud, das erste Anzeichen schwindender Silos  AWS wurde 2006 gegründet und war der erste große Cloud-Anbieter. Der Begriff DevOps wurde 2008 geprägt und sollte kein Cloud-Management-Problem lösen, sondern die echten Silos zwischen dem Betrieb der Infrastruktur vor Ort. Dies ist die Wurzel der Verwirrung darüber, was DevOps ist. Etwa zur gleichen Zeit begannen zwei große Veränderungen in der Softwareentwicklungslandschaft.  Beim Cloud-Computing verwenden wir drei Hauptmodelle: Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS). Da wir diese hochrangigen Konstrukte verwenden, ist die OPS (Systemadministration) fast verschwunden. Das ist, als ob das ursprüngliche Kulturproblem, das die Väter von DevOps erkannt haben, nicht mehr existiert.  Jedes Modell bietet unterschiedliche Kontroll-, Flexibilitäts- und Verwaltungsebenen der zugrunde liegenden Infrastruktur und nur sehr wenige Unternehmen würden eine Infrastruktur vor Ort unterhalten.  Während also die DevOps-Bewegung versuchte   , war die Cloud-Infrastruktur bereits dabei, einen Teil des Problems zu beseitigen, indem   .  , die „Silot“-Probleme zwischen Dev und Ops zu lösen sie Ops obsolet machte  Keine Operationen, keine Silos  Die wichtigsten DevOps-Mottos lauten „Shift Left“ und „Sie bauen es, Sie führen es aus“, was nur dazu führen kann, dass die Aufgaben des Ops an die Entwickler übertragen werden. Cloud reduzierte den Bedarf an Systemadministratoren (Ops) durch das IaaS-Modell und verringerte den Aufwand für Entwickler, Anwendungen selbst zu verwalten und bereitzustellen.  Wir können es anders formulieren, damit es besser klingt! Ops stärkte die Entwickler, indem es Tools zur Vereinfachung der Softwareintegration und -bereitstellung anbot und so den Aufwand für die Betriebsteams zur Wartung der Infrastruktur reduzierte. Infolgedessen befanden wir uns in einer Situation, in der wir keine Systemadministration (Ops) benötigten.   Wir brauchen jedoch jemanden, der diese „Tools zur Vereinfachung der Softwareintegration und -bereitstellung“ wartet.  Diese neue Rolle hat noch keinen Namen, da sie von den ehemaligen Ops eingeführt wurde, die sie in „DevOps-Leute“ umbenannt haben. Nennen wir sie DevOps-Ingenieur. Irgendjemand hat es wahrscheinlich irgendwann einmal gesagt, und es ist hängen geblieben.   DevOps hat sich neu definiert  Bei DevOps ging es nie um Tools, sondern um Kultur. Die Idee dahinter ist, dass auch die Softwareentwicklung „schlanker“ werden kann und die Softwarebereitstellung pünktlich erfolgen kann. Das ursprüngliche Problem von DevOps mag längst gelöst sein, aber es war die Geburtsstunde der wichtigsten Idee in der Softwareentwicklung: Continuous Delivery.  Ich unterstütze schon lange diejenigen, die behaupten, DevOps sei weder eine Rolle noch ein Team, und wenn man es so nennt, liegt man falsch. Später wurde mir klar, dass die Dinge, nun ja, komplexer waren. Wir schufen unpassenderweise eine Rolle, „der Typ (oder die Typen), der (die) Tools pflegt (pflegen), um die Integration und Bereitstellung von Software zu vereinfachen“, aber wir hatten keinen Namen dafür.  Wenn Sie darüber nachdenken: Brauchen Sie wirklich „den/die Leute, die Tools pflegen, um die Integration und Bereitstellung von Software zu vereinfachen“, wenn alles ein Cloud-Angebot wäre? Vollständig verwaltet? Funktioniert auf Knopfdruck?  Dies ist der Traum der meisten Cloud-Anbieter und vieler DevOps-SaaS-Produkte (denken Sie beispielsweise an GitLab). Die Wahrheit ist jedoch nicht so einfach. Theoretisch hätte alles einfacher sein können, und Ops-Aufgaben hätten automatisiert, Dienste vollständig verwaltet usw. werden können. In Wirklichkeit haben wir jedoch ein Monster geschaffen.   Daher besteht die Herausforderung für die meisten Betriebs-/Infrastrukturteams (auch Ops genannt) darin, sich im Netz der unzähligen Tools und Dienste zurechtzufinden und diese Tools zu verstehen, einzusetzen und zu einer schlüssigen Infrastruktur und mit schlüssigen Tools zu verknüpfen, die von Entwicklern verwendet werden können.  „DevOps steckt fest“ ist das zentrale Schlagwort, das sich leicht in DevSecOps, FinOps, GitOps, MlOps usw. umwandeln lässt.  Aber wenn Sie es bemerken, ist der Duft, der bleibt, immer Ops. Das Lustige daran ist, dass jeder Ansatz darauf abzielt, die Ops aus den Gleichungen zu entfernen. Die Ops, auch bekannt als „der Typ (die Typen), der sich in das System einloggt und Dinge tut, damit es funktioniert.“  Kurz zusammengefasst  Das ursprüngliche Problem, das DevOps lösen sollte, besteht aufgrund der zunehmenden Verbreitung von Cloud-Infrastrukturen möglicherweise nicht mehr. DevOps hat jedoch die wichtige Idee der kontinuierlichen Bereitstellung hervorgebracht und einen Kulturwandel in der Softwareentwicklung herbeigeführt.  Auch wenn der Begriff „DevOps“ als Schlagwort im Umlauf geblieben ist, hat er doch zur Entwicklung neuer Ansätze wie DevSecOps, FinOps und GitOps geführt, die alle darauf abzielen, traditionelle Ops-Aufgaben überflüssig zu machen.  Letztlich entwickelt sich die Landschaft von DevOps und Cloud-Infrastruktur ständig weiter, und es ist schwierig, auf dem Laufenden zu bleiben und die richtigen Tools auszuwählen. Ironischerweise bedeutete DevOps ursprünglich die Zusammenarbeit zwischen Dev und Ops, aber mittlerweile wird Ops aus der Gleichung ausgeschlossen.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This piece was written for humor or satire and may include nonfactual statements, stories, or anecdotes.

Read My Stories

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Das DevOps-Paradoxon: Eine Abkehr vom operativen Geschäft

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps