Auf einen Chatverlauf zu … DevOps

In dieser Reihe unterhalten wir uns regelmäßig mit ChatGPT zu Themen aus dem compass-Kosmos. Die Antworten von Chat GPT bilden dabei das allgemein im Netz verfügbare Wissen ab und geben so einen guten Einblick, allerdings einen, der auch mit Vorsicht zu genießen ist. Daher wird jedes Interview zum Schluss mit einer Frage an einen Experten von Flying Circus abgerundet, der das Thema noch einmal aus seiner Sicht beleuchtet und möglicherweise richtigstellt. Und damit viel Spaß beim Lesen.

Beginnen wir mit etwas Hintergrundwissen. Was verstehen wir allgemein unter DevOps? 

DevOps ist ein Begriff, der für eine Zusammenarbeit zwischen Entwicklungs- (Development) und Betriebsteams (Operations) steht. Es ist ein agiler Ansatz für die Softwareentwicklung, der darauf abzielt, die Bereitstellung von Anwendungen schneller und effizienter zu gestalten. Traditionell waren Entwicklungs- und Betriebsteams voneinander getrennt und arbeiteten in Silos. Die Entwicklungsteams waren für die Entwicklung der Anwendungen verantwortlich, während die Betriebsteams für die Bereitstellung und Wartung der IT-Infrastruktur zuständig waren. Dies führte oft zu Verzögerungen bei der Bereitstellung von Anwendungen und mangelnder Kommunikation zwischen den Teams. DevOps zielt darauf ab, diese Trennung aufzulösen. 

Austausch und partnerschaftliche Zusammenarbeit sind also elementar für den DevOps-Ansatz?

DevOps verbessert die Zusammenarbeit und Kommunikation zwischen den Entwicklungsteams und Betriebsteams. Im Gegensatz zu traditionellen Methoden, die oft auf starren Prozessen und strikten Hierarchien basieren, fördert DevOps eine Kultur der Zusammenarbeit und Offenheit und schafft eine gemeinsame Verantwortung für den gesamten Lebenszyklus von Anwendungen. DevOps setzt auf Automatisierung, um Zeit und Kosten zu sparen und menschliche Fehler zu minimieren. Der Ansatz ermöglicht es Unternehmen zudem, schnell auf sich ändernde Anforderungen des Marktes zu reagieren und ihre Anwendungen schnell und effizient zu aktualisieren und zu erweitern.

Nun ist auch immer wieder von sogenannten NoOps zu hören und zu lesen. Was hat es damit auf sich?

NoOps (No Operations) ist ein Ansatz für die Softwareentwicklung, der darauf abzielt, die Abhängigkeit von IT-Operation-Teams zu reduzieren oder sogar zu eliminieren. Mit NoOps sollen Entwickler in der Lage sein, Anwendungen ohne Beteiligung von IT-Operation-Teams zu entwickeln, zu testen und bereitzustellen. NoOps basiert auf der Idee, dass Automatisierung und Cloud-Computing-Technologien es Entwicklern ermöglichen, die Infrastruktur und die Prozesse für die Bereitstellung von Anwendungen selbst zu managen. Mit NoOps müssen Entwickler nicht mehr auf IT-Operation-Teams warten, um die Anwendungsbereitstellung zu unterstützen oder die zugrunde liegende Infrastruktur zu verwalten.

NoOps ist jedoch kein Ansatz, der für jedes Unternehmen oder jede Anwendung geeignet ist. Es erfordert ein hohes Maß an Automatisierung und Selbstbedienungsfähigkeiten, sowie eine starke Governance-Struktur, um sicherzustellen, dass Anwendungen sicher und zuverlässig bereitgestellt werden. Daher ist NoOps eher für Unternehmen mit sehr schnellen Entwicklungszyklen und einer starken DevOps-Kultur geeignet. 

Klingt so, als würde NoOps zwar auf den ersten Blick Einsparpotenzial bieten, aber letztlich doch einige Nachteile gegenüber dem DevOps-Ansatz mit sich bringen.

Ja, das ist richtig. NoOps hat einige potenzielle Nachteile, insbesondere in Bezug auf die Sicherheit und Governance von Anwendungen und Systemen. Ohne eine klare Governance-Struktur und Überwachung können Anwendungen möglicherweise unsicher und instabil werden, was wiederum zu Geschäftsrisiken führt. Außerdem kann die Eliminierung von IT-Operations-Teams dazu führen, dass die Kenntnisse und Erfahrungen dieser Teams verloren gehen, was wiederum die Fähigkeit des Unternehmens beeinträchtigen kann, mit unerwarteten Ereignissen und Störungen umzugehen.

DevOps hingegen betont die Zusammenarbeit und Kommunikation zwischen Entwicklern und IT-Operations-Teams, was dazu beitragen kann, eine starke Governance-Struktur zu schaffen und ein höheres Maß an Sicherheit und Stabilität zu gewährleisten. Der Ansatz fördert auch die kontinuierliche Verbesserung und Automatisierung von Prozessen, um die Effizienz und Geschwindigkeit der Anwendungsentwicklung und -bereitstellung zu verbessern. 

Insgesamt ist DevOps daher oft eine bessere Wahl als NoOps, insbesondere für Unternehmen, die sicherstellen möchten, dass ihre Anwendungen sicher, zuverlässig und effizient sind.

Nun möchte ich als Unternehmen aber dennoch meinen DevOps-Bereich optimieren. Kann DevOps as a service hier ein passender Ansatz sein?

Ja, DevOps as a Service (DaaS) kann eine gute Möglichkeit sein, den DevOps-Bereich effizienter zu gestalten, insbesondere für kleinere Unternehmen oder Unternehmen, die nicht über die Ressourcen verfügen, um ein eigenes DevOps-Team aufzubauen. 

DaaS ist ein Modell, bei dem ein Drittanbieter-Service-Provider DevOps-Tools und -Prozesse bereitstellt und verwaltet, um die Anwendungsentwicklung und -bereitstellung zu erleichtern. DaaS kann auch andere Dienstleistungen wie Continuous Integration, Continuous Delivery, Monitoring und Automatisierung umfassen.

Durch DaaS können Unternehmen von der Expertise und Erfahrung des DaaS-Anbieters profitieren und sich auf ihre Kernkompetenzen konzentrieren, während sie gleichzeitig die Vorteile einer effizienten DevOps-Praxis genießen. DaaS kann auch dazu beitragen, die Kosten für die Bereitstellung von Anwendungen zu reduzieren, da Unternehmen nur für die tatsächlich genutzten Ressourcen bezahlen müssen, anstatt teure Infrastrukturen und Tools bereitzustellen. 

Allerdings sollten Unternehmen bei der Auswahl eines DaaS-Anbieters sorgfältig vorgehen und sicherstellen, dass der Anbieter ihre spezifischen Anforderungen erfüllen kann und eine klare Governance-Struktur hat, um sicherzustellen, dass Anwendungen sicher und zuverlässig bereitgestellt werden.

Gut gewählt ist also schon mal halb gewonnen. Danke ChatGPT. 
 

Gerne geschehen! Wenn Sie weitere Fragen haben, stehe ich Ihnen gerne zur Verfügung.

Bleibt die Frage an die Experten von Flying Circus: Christian Theune, wie schätzt du die Gedanken von ChatGPT ein? Und warum glaubt ihr bei Flying Circus an den Austausch zwischen Devs und Ops und das Prinzip DevOps as a service? 
 

Christian Theune: Dass ChatGPT „Zusammenarbeit“ zwischen Teams als ersten Begriff wählt, hat mich positiv überrascht. DevOps wird häufig missverstanden und mit bestimmten Techniken, Technologien oder Produkten assoziiert. DevOps heißt für viele, dass man AWS oder Kubernetes benutzen muss. Auch bei der Nachfrage reagiert ChatGPT mit einem Schwerpunkt auf der Kultur von Zusammenarbeit und Offenheit und gemeinsamer Verantwortung – das deckt sich mit unserer Erfahrung.

Die Schlussfolgerung bezüglich der Reaktionsfähigkeit auf sich ändernde Anforderungen am Markt ist so weit korrekt – da fehlt mir aber eigentlich die tiefere Betrachtung, also das „Warum“. Das ist nämlich gar nicht so eindeutig: Häufig werden Automatisierung und Zeit- und Kostenersparnis durch hohe Standardisierung erreicht. Das führt aber häufig zu weniger Reaktionsfähigkeit. Hier geht es also ganz stark um das „Wie“. Die Betrachtung erfordert, dass man passende Denkansätze für eine komplexe Welt braucht: Da muss ich eben Ineffizienzen zulassen, aushalten oder sogar explizit herbeiführen – um flexibel zu bleiben, wenn ich eine Umgebung noch nicht kenne oder verstanden habe oder sich diese ändert. Und dann muss ich aber eben doch später in der Lage sein, Dinge effizient zu machen, sobald ich sie verstanden habe und wirtschaftlich skalieren möchte. In der besten Ausprägung kann ich in einem Projekt immer zwischen Effizienz und Innovation hin- und herpendeln.

Ich finde es spannend, dass ChatGPT bei NoOps explizit auch auf Risiken eingeht. An sich scheint etwas wie „NoOps“ die logische Konsequenz von DevOps zu sein, allerdings schüttet man damit eben das Kind mit dem Bade aus. DevOps hat ja bereits zum Ziel, unnötige Abhängigkeiten zu eliminieren. Insofern doppelt sich das in der NoOps-Definition. Gleichzeitig zeigt es auch, dass es plötzlich von einer fruchtbaren Zusammenarbeit zu einer stringenten Governance wechselt. Das ist eine Rochade, die eher an träge Strukturen erinnert und eben nicht an schnelle Entwicklungszyklen: weil plötzlich formale Aspekte die inhaltlichen Anforderungen ausbooten können und eben der Wert nicht mehr darin liegt, die unterschiedlichen Kompetenzen (Devs und Ops) fruchtbringend in Austausch zu bringen, sondern genau das zu eliminieren. In unserer Erfahrung steht dann die Effizienz vor der Effektivität, was schnell dazu führen kann, dass eben gar nichts mehr einfach so geht.

ChatGPT reagiert dann in den Nachfragen mit Texten, die man tatsächlich so relativ leicht als „Buzzword-Bingo“ lesen könnte. Ich fand es aber interessant, dass es dann noch zu einem abschließenden Vergleich greift, wobei mir das Ergebnis zu oberflächlich ist – und wenn man es aufmerksam liest, etwas unsinnig …: NoOps ist laut ChatGPT für Unternehmen mit starker DevOps-Kultur aber mit dem Wunsch nach schnellen Entwicklungszyklen verbunden, was ja aber auch das Ziel von DevOps ist. NoOps war ursprünglich auch eher sarkastisch eingeführt worden, um sich einem überzogenen Spardruck von vermeintlich „reinen Kostentreibern“ zu entledigen, während gerade DevOps auf die unterschiedlichen, sich ergänzenden Kompetenzen Wert legt.

„DevOps as a Service“ finde ich eigentlich gar nicht schlecht dargestellt, aber dass ChatGPT scheinbar in „Governance-Strukturen“ verliebt zu sein scheint, entspricht weniger unserem Blick auf die Dinge … Bei Flying Circus ist es uns wichtig, dass eine fruchtbare Zusammenarbeit eben nicht nur die Lücke für kleine Unternehmen ohne eigene Teams füllen soll. Wir sehen eben gerade auch bei große Unternehmen, dass diese mit hoher Komplexität kämpfen und mehr auf die Situation angepasste Lösungen und Dienstleistungen brauchen. Hier kommt unser Modell ins Spiel, bei dem wir uns als Erweiterung des Entwicklerteams und der Product-Owner verstehen und eben nicht nur „das Ende der Futterkette“ sind, bei dem man Tickets einwirft oder Stunden bucht. Unsere Application Operations Engineers und System Engineers übernehmen für die Projekte unserer Kunden Betriebsverantwortung und engagieren sich weit über den Tellerrand des Betriebs, indem sie Entwicklern und Anwendungsinhabern Feedback geben und eigene Ideen einbringen, die das Projekt voranbringen können. Dabei können wir eben Wissen aus ganz unterschiedlichen Branchen, Projektgrößen und Technologien einbringen, die ein internes Team nicht abdecken kann.