Gibt es so etwas wie Enterprise DevOps? Darauf können Sie wetten.

Denn letzten Endes ist DevOps einfach eine Methode, die schnellere, effizientere und qualitativ hochwertigere Software-Releases ermöglicht. Und das sind alles gute Dinge, egal ob Sie ein Startup mit drei Mitarbeitern oder ein Großunternehmen mit 3.000 Mitarbeitern sind.

Und deshalb ist DevOps für jeden geeignet – insbesondere heute, wo DevOps ausgereift ist. Lassen Sie mich das erklären …

Warum der Widerstand gegen DevOps anhält

Wir sind an der Reife Phasen der DevOps-Einführung . Während hochmoderne Praktiken rund um Mikrodienste , Kubernetes usw. stehlen die Show, die über 3 Jahre alten Kernkonzepte von DevOps sind ausgereift und die Akzeptanz ist enorm. Es gibt jedoch immer noch Widerstand. Und dieser kommt von allen Seiten — Sicherheit , Entwicklung, Betrieb und Tests, jeweils mit einer eigenen Abneigung. Die Sicherheitsabteilung glaubt, dass schnelleres Vorgehen mehr Schwachstellen schafft. Die Entwicklung ist möglicherweise nicht ausreichend rationalisiert (d. h. der Betrieb existiert noch). Der Betrieb hat Angst vor Kontrollverlust und bei den Tests bedeutet schnelleres Testen von Dingen wie Sicherheit normalerweise mehr Probleme, mit denen man sich befassen muss.

Nicht nur, dass manche Leute aus diesen Funktionen noch immer Bedenken gegenüber DevOps haben, sie arbeiten auch in einem Unternehmen, wo diese Bedenken mit der Unfähigkeit des Unternehmens einhergehen, Änderungen im gleichen Tempo wie Start-ups durchzuführen.

Die Geschichte zweier DevOps

Das Problem ist, dass es eine gewisse Unklarheit darüber gibt, was DevOps eigentlich ist. Und das liegt daran, dass es zwei DevOps gibt. Erstens gibt es DevOps als Funktion. Die Funktion ist ziemlich klar definiert als die Personen, die im Allgemeinen dem Betrieb unterstellt sind, aber Entwicklern dabei helfen, Lieferketten aufzubauen und zu warten und Infrastruktur bereitzustellen. Diese Definition impliziert organisatorische Strukturen, und es ist viel einfacher zu argumentieren, dass diese Funktion nicht in bestehende Strukturen passt, als zu argumentieren, dass die breitere DevOps-Definition dies tut.

Die zweite Definition von DevOps ist die Praxis, die die Entwicklung vorantreibt – „antreiben“ ist das Schlüsselwort. Es ist kein Ende. Wenn eine DevOps-Umgebung die Implementierung „abschließen“ würde, wäre sie sofort eine Nicht-DevOps-Umgebung. Der Grund dafür ist, dass Sie, wenn Sie DevOps praktizieren, eine Umgebung aufbauen, die sich auch leicht anpassen lässt. Mangelnde Anpassung war ein Kernproblem bei wasserfallbasierten Entwicklungspraktiken, sodass letztendlich die Lieferkette die Anwendung diktierte und nicht umgekehrt (so sollte es auch sein). Die DevOps-Reise endet nie wirklich.

Widerstand ist gleichbedeutend damit, zu sagen, wir wollen unsere Prozesse oder Anwendungen nicht verbessern, was den Zielen der meisten Organisationen in Bezug auf die Anwendungsentwicklung nicht gerecht würde. Allein der Begriff DevOps kann frustrierend sein, da es so viele Akronyme gibt, aber das Wort dient einem Hauptzweck. Es ermöglicht uns, über DevOps zu sprechen, ohne es jedes Mal neu definieren zu müssen.

Warum Agilität die Sicherheit und Qualität verbessert

Als Nächstes wenden wir uns einer Sorge zu, die durchaus berechtigt ist und auf taktischen Überlegungen beruht: der Sorge, dass DevOps-Umgebungen das Unternehmen einer größeren Anzahl von Fehlern und Sicherheitslücken aussetzen.

Für diejenigen, die jahrelange Erfahrung in den Bereichen Qualität und Sicherheit haben, scheint dies intuitiv. Das Ziel von DevOps besteht jedoch nicht darin, Prozesse zu unterbrechen, sondern sie effizienter zu gestalten. In effizienten Umgebungen sind Sicherheit und Qualität tatsächlich einfacher und besser zu implementieren.

Um auf die Bedenken der Sicherheits- und Testexperten einzugehen, dass Geschwindigkeit im Allgemeinen mehr Probleme schafft, bedeutet Geschwindigkeit nicht weniger Tests oder weniger berücksichtigte Aspekte. Im Gegenteil. In einer DevOps-Lieferkette gibt es im Allgemeinen mehr Kontrollen und Ausgleiche, aber diese finden in Computerzeit statt, nicht in menschlicher Zeit. Daher sind diese Kontrollen und Ausgleiche schneller, genauer und wiederholbarer. Agilität kann und sollte in diesem Fall also mehr Sicherheit und höhere Softwarequalität bedeuten, nicht weniger.

Die Schönheit der DevOps-Praxis

Das Beste an DevOps ist, dass es keine Organisationsstruktur voraussetzt. Es setzt keine Anwendungsstruktur voraus und es setzt kein Alter oder Reife der Einführung voraus. Organisationen müssen nicht sofort „ Zwei-Pizza ” Entwicklungsteams. Sie müssen keine containerbasierten Microservices-Anwendungen haben und es müssen auch keine einjährigen Startups im Silicon Valley sein. Und um den größten Irrtum auszuräumen: Entwickler müssen plötzlich nicht mehr unbedingt mit der Betriebsabteilung befreundet sein oder umgekehrt. Sie müssen nur dieselben Ziele verfolgen.

Nehmen wir eine extreme Form des unwahrscheinlichsten Kandidaten für DevOps und sehen wir, warum DevOps trotzdem nützlich ist. Betrachten wir XYZ Corp., ein Unternehmen mit über 10.000 Mitarbeitern, einer Bibliothek monolithischer Anwendungen und 100 Entwicklern, die diese unterstützen. Der Großteil der Entwicklung ist integrationsbasiert, wobei veralteter benutzerdefinierter Code für alle ein Rätsel ist. Projekte werden von Geschäftseinheiten initiiert und von Projektmanagern und Geschäftsanalysten geleitet. Nehmen wir an, dieses hypothetische Unternehmen ist in der Baubranche tätig und hat keine kommerziellen Endbenutzer – und schon gar keine technischen.

Warum sollte die XYZ Corp. die Einführung von DevOps-Best Practices in Betracht ziehen? Aus denselben Gründen, aus denen sie überall betriebliche Verbesserungen in Betracht ziehen: geringere Kosten und höhere Effizienz. Obwohl ihnen bessere Benutzererfahrungen und häufigere Releases letztendlich enorme Vorteile bringen, können sie nicht leugnen, dass die Rationalisierung der Entwicklung und die Steigerung der Effektivität ihrer Anwendung für die Benutzerbasis nicht die Kosten für die Erstellung der Anwendung senken, den Bedarf an neuen Mitarbeitern verringern und mehr Betriebsprobleme schneller lösen werden. Projekte werden mehr Kontrollpunkte für Endbenutzer haben, um ihre Wünsche zu validieren, was bedeutet, dass das Risiko eines Projektfehlers geringer ist und die Ausgaben für dieses Projekt besser genutzt werden. Eine verbesserte Release-Geschwindigkeit steigert auch die Wettbewerbsfähigkeit, da sie besser in der Lage sind, die sich häufig ändernden Kundenerwartungen zu erfüllen und zu übertreffen.

XYZ Corp muss seine Infrastruktur nicht am Tag nach der Einführung von DevOps neu gestalten. Sie müssen lediglich nach Möglichkeiten zur Automatisierung suchen und die Anwendungsentwicklung als Teil ihres Kernwerts und nicht als Kostenstelle betrachten. Die Realität ist, dass XYZ, selbst wenn es heute nicht dem gleichen Druck hinsichtlich der Qualität von Anwendungen ausgesetzt ist, nur eine Frage der Zeit ist, bis dies der Fall sein wird. Irgendwann wird die Technologie ein so großer Teil ihres Kerngeschäfts sein, dass bessere Anwendungen erforderlich sein werden.

Einhörner nicht erforderlich

Sie müssen kein Unicorn-Unternehmen oder -Entwicklungsteam sein, um DevOps zu nutzen, denn DevOps ist die Methode, die die Effizienz Ihrer Betriebsabläufe und Lieferketten steigert, und nicht die Vorschrift, wie diese aufgebaut werden. Die neuesten Tools sind da und werden immer da sein. Aber um DevOps zu nutzen, müssen Sie nicht alle davon nutzen. Was Sie wirklich tun müssen, ist Fokus auf Automatisierung , Qualität und Reaktionsfähigkeit Ihrer Softwarelieferkette.