Gibt es so etwas wie Enterprise DevOps? Aber sicher.

Letzten Endes ist DevOps einfach eine Methodologie, 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 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 drei Jahre alten Kernkonzepte von DevOps sind ausgereift und werden enorm angenommen. Es gibt jedoch immer noch Widerstand. Und dieser kommt von allen Seiten – Sicherheit , Entwicklung, Betrieb und Test, jeder mit seiner 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 befürchtet Kontrollverlust; und für die Testabteilung bedeutet schnelleres Testen von Dingen wie Sicherheit in der Regel mehr Probleme, mit denen man sich befassen muss.

Manche Leute aus diesen Funktionen hegen nicht nur immer noch Vorbehalte gegenüber DevOps, sondern sie arbeiten auch in einem Unternehmen, wo diese Bedenken mit der Unfähigkeit des Unternehmens einhergehen, Änderungen im gleichen Tempo wie Startups vorzunehmen.

Die Geschichte zweier DevOps

Das Problem ist, dass es eine gewisse Unklarheit darüber gibt, was DevOps eigentlich ist. Das liegt daran, dass es zwei DevOps gibt. Erstens gibt es DevOps als Funktion. Diese Funktion ist ziemlich klar definiert als die Personen, die in der Regel dem operativen Geschäft unterstellt sind, aber Entwicklern beim Aufbau und der Wartung von Lieferketten sowie der Bereitstellung von Infrastruktur zur Seite stehen. 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 – „treiben“ ist das Schlüsselwort. Es ist kein Ende. Tatsächlich wäre eine DevOps-Umgebung, wenn die Implementierung „abgeschlossen“ wäre, sofort eine Nicht-DevOps-Umgebung. Der Grund dafür ist, dass Sie mit DevOps eine Umgebung aufbauen, die sich leicht anpassen lässt. Mangelnde Anpassung war ein Kernproblem bei wasserfallbasierten Entwicklungspraktiken, sodass letztendlich die Lieferkette die Anwendung diktierte und nicht umgekehrt (was auch so sein sollte). Die DevOps-Reise endet nie wirklich.

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

Warum Agilität Sicherheit und Qualität verbessert

Als Nächstes wenden wir uns der Sorge zu, die durchaus berechtigt ist und auf Taktiken beruht: der Sorge, dass DevOps-Umgebungen das Unternehmen mehr Fehlern und Sicherheitslücken aussetzen.

Für diejenigen, die über langjährige Erfahrung in den Bereichen Qualität und Sicherheit verfügen, erscheint dies intuitiv. Das Ziel von DevOps besteht jedoch nicht darin, Prozesse zu unterbrechen, sondern sie effizienter zu gestalten. In effizienten Umgebungen lassen sich Sicherheit und Qualität tatsächlich einfacher und besser umsetzen.

Um auf die Bedenken von Sicherheits- und Testexperten einzugehen, dass Geschwindigkeit generell mehr Probleme schafft: Geschwindigkeit bedeutet nicht weniger Tests oder weniger berücksichtigte Aspekte. Im Gegenteil. In einer DevOps-Lieferkette gibt es generell mehr Kontrollen und Abwägungen, aber diese erfolgen in Computerzeit, nicht in menschlicher Zeit. Daher sind diese Kontrollen und Abwägungen 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 setzt weder Alter noch 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 und umgekehrt. Sie müssen nur die gleichen Ziele verfolgen.

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

Warum sollte XYZ 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. Zwar werden ihnen bessere Benutzererfahrungen und häufigere Releases letztendlich enorme Vorteile bringen, doch lässt sich nicht leugnen, dass eine Rationalisierung der Entwicklung und eine Steigerung der Benutzerfreundlichkeit ihrer Anwendung weder die Kosten für die Anwendungserstellung senken noch den Personalbedarf verringern und mehr Betriebsprobleme schneller lösen wird. Projekte werden mehr Kontrollpunkte für Endbenutzer bieten, um ihre Wünsche zu validieren. Das bedeutet, dass das Risiko eines Projektfehlers geringer ist und die Projektausgaben besser genutzt werden. Eine schnellere Release-Geschwindigkeit steigert zudem die Wettbewerbsfähigkeit, da sie die sich häufig ändernden Kundenerwartungen besser erfüllen und übertreffen können.

XYZ muss seine Infrastruktur nicht sofort nach der Einführung von DevOps umgestalten. Vielmehr muss das Unternehmen nach Automatisierungsmöglichkeiten suchen und die Anwendungsentwicklung als Teil seines Kerngeschäfts und nicht als Kostenfaktor betrachten. Selbst wenn XYZ heute nicht dem gleichen Druck hinsichtlich der Qualität seiner Anwendungen ausgesetzt ist, ist es nur eine Frage der Zeit, bis dies der Fall sein wird. Irgendwann wird Technologie so stark in das Kerngeschäft integriert sein, dass bessere Anwendungen erforderlich werden.

Einhörner nicht erforderlich

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