Lesezeit ca. 6 Min.
arrow_back

DevOps in der Kritik: Viele Devs haben keine Lust mehr auf Ops


Logo von Computerwoche
Computerwoche - epaper ⋅ Ausgabe 40/2022 vom 30.09.2022

“Wenn man die Entwickler in zu viele andere Bereiche hineinzieht, schießt man sich selbst in den Fuß.“

James Brown, Head of Product, Ondat

Entwickler wollen sich größtenteils nicht mit betrieblichen Belangen befassen, stellt Emily Freeman, Head of Community Engagement bei Amazon Web Services und Autorin von „DevOps for Dummies“ auf Twitter fest. Bis dato habe sie für diese Beobachtung immer Gegenwind bekommen, berichtete die Managerin. Doch das scheint sich nun zu ändern. Freeman zufolge hätten sich ihre letzten Dutzend Beratungsgespräche hauptsächlich darum gedreht, wie man den Entwicklern die Verantwortung für den Betrieb abnehmen und trotzdem DevOps sein kann.

Das DevOps-Konzept entstand in den späten 2000er-Jahren – im Zuge der agilen Software-Entwicklung und des Cloud-Trends. Wie die Wortschöpfung aus Development und Operations schon andeutet, ging es darum, die Trennung zwischen ...

Artikelbild für den Artikel "DevOps in der Kritik: Viele Devs haben keine Lust mehr auf Ops" aus der Ausgabe 40/2022 von Computerwoche. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.
Weiterlesen
epaper-Einzelheft 10,99€
NEWS Jetzt gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Computerwoche. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1050 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 40/2022 von Wer schnell sein will, muss erst einmal Zeit investieren. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Wer schnell sein will, muss erst einmal Zeit investieren
Titelbild der Ausgabe 40/2022 von Salesforce überholt SAP: CEO Benioff feiert auf der Hausmesse Dreamforce. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Salesforce überholt SAP: CEO Benioff feiert auf der Hausmesse Dreamforce
Titelbild der Ausgabe 40/2022 von Vorratsdatenspeicherung: Bund will auf EuGH-Urteil schnell reagieren. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Vorratsdatenspeicherung: Bund will auf EuGH-Urteil schnell reagieren
Titelbild der Ausgabe 40/2022 von Bundestagsdebatte: Streit um die Digitalstrategie der Bundesregierung. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Bundestagsdebatte: Streit um die Digitalstrategie der Bundesregierung
Mehr Lesetipps
Blättern im Magazin
Bundestagsdebatte: Streit um die Digitalstrategie der Bundesregierung
Vorheriger Artikel
Bundestagsdebatte: Streit um die Digitalstrategie der Bundesregierung
Kyndryl Bridge – Service für die Integration von IT-Ressourcen
Nächster Artikel
Kyndryl Bridge – Service für die Integration von IT-Ressourcen
Mehr Lesetipps

... Software-Entwicklung und -Bereitstellung aufzuheben. Das fiel mit der Notwendigkeit zusammen, dass Softwareingenieure das Feedback der Anwender häufiger einholen und in ihre Arbeit einbeziehen sollten, was sich in sehr vielen Updates niederschlug.

Das Konzept, betriebliche und auch sicherheitsrelevante Belange im Zuge eines „Shift-Left-Ansatzes“ in den Zuständigkeitsbereich der Entwickler zu verlagern, habe sicher seine Vorteile, könne aber auch zu gefährlichen Engpässen führen, wie James Brown, Head of Product beim Kubernetes-Spezialisten Ondat, ausführt. „Wenn man die Entwickler in zu viele andere Bereiche hineinzieht, schießt man sich selbst in den Fuß“, urteilt Brown. Je nach Disziplin seien eben doch unterschiedliche Fähigkeiten vonnöten. Nick Durkin, Field CTO beim DevOps-Plattformanbieter Harness, findet noch deutlichere Worte: „Manche Leute fangen endlich an, es zu begreifen: Für Klempnerarbeiten heuert man keinen Elektriker an.“

Während die Zahl der Softwareentwickler in den Unternehmen noch nie so groß war wie heute, tritt ihr Fachwissen immer mehr in den Hintergrund – und das, obwohl ihre Arbeits belastung erheblich gestiegen ist. Wie der DevOps-Ingenieur und Ex-Systemadministrator Mathew Duggan in seinem Blog schreibt, hätten die Ops zwar immer noch ihre angestammten Aufgaben zu leisten, also Verfügbarkeit, Monitoring, Sicherheit und Compliance von Anwendungen. Doch heute müssten sie darüber hinaus die Software-Delivery-Pipelines aufbauen und pflegen. So würden sie die „Grundlage dafür schaffen, dass die Entwickler den Code schnell und sicher liefern können.“

Diese zusätzlichen Aufgaben erfordern nach Meinung von Duggan umfassende Umschulungen, bei denen Cloud-Engineering- und Infrastructure-as-Code-Kenntnisse im Fokus stehen müssten. „Meiner Meinung nach war die Situation noch nie so düster wie heute“, schreibt Duggan. „Die gesamte Software-Entwicklung ist mit der massiven Ausweitung ihrer Aufgaben aber auch mit den unrealistischen Erwartungen des Managements in Sachen Geschwindigkeit völlig überfordert.“

Herausforderung iterative Harmonie

Tyler Jewell, Managing Director bei Dell Technologies Capital, bestätigt den Befund von Duggan in einer Research Note: „Es ist unglaublich herausfordernd, eine Organisation aufzubauen, die über einen längeren Zeitraum den erforderlichen hohen Grad iterativer Harmonie aufrechterhalten kann.“ Je komplexer die Systeme würden und je mehr Feedback der End-User einfließe, desto schwieriger werde es für Menschen, zu beurteilen, welche Auswirkungen die ständigen Änderungen auf das Gesamtsystem hätten.

Problem erkannt, Problem gebannt?

Möglicherweise ist die Situation aber nicht ganz so hoffnungslos, wie Duggan, Jewell und andere glauben – auch wenn eine grundlegende Neuausrichtung von Entwicklungsteams und ihren Zuständigkeiten nötig werden könnte. „Ziel muss es sein, die Entwickler mit den richtigen Systeminformationen zur rechten Zeit zu bedienen“, meint Durkin. Dann könnten sie die Systeme so konfigurieren, dass Betriebs-, Sicherheits- und Infrastrukturteams angemessen arbeiten könnten.

Auch Nigel Simpson, ehemals Director Enterprise Technology Strategy bei der Walt Disney Company, ist der Meinung, dass Unternehmen dieses Problem erkennen und daran arbeiten sollten. „Entwickler können sich nicht damit befassen, wie die gesamte Maschinerie funktioniert. Sie sollten sich darauf konzentrieren, das zu tun, was sie am besten können – Software zu schreiben.“ Zudem sei es wichtig, zu bedenken, dass die Implementierung von DevOps von Unternehmen zu Unternehmen variiert. Nur weil Entwickler vorübergehend einige zusätzliche Aufgaben übernähmen, heiße das nicht, dass sie das für immer tun sollten.

„Die Kontrolle der Entwickler über die gesamte Infrastruktur ist keine Bedingung für den Erfolg“, schreibt Gartner-Analystin Lydia Leong. Die Verantwortung könne über den Lebenszyklus von Anwendungen hinweg verteilt werden. Unternehmen könnten vom DevOps-Prinzip „You build it, you run it“ profitieren, ohne ihre Entwickler im Regen stehen zu lassen. „Es ist völlig in Ordnung, wenn Sie Ihren Devs den vollen Self-Service-Zugang zu Entwicklungs- und Testumgebungen gewähren und ihnen auch die Möglichkeit geben, Infrastructure-as-Code-Templates zu erstellen, ohne ihnen die ganze Verantwortung für den Betrieb zu übertragen.“

Ondat-Manager Brown ist der Ansicht, dass die Container-Orchestrierung mit Kubernetes die unsichtbare Grenze zwischen Ops und Devs bilde, die die Belange beider Seiten voneinander trenne. So könnten sich Devs auf ihren Code und Ops auf Infrastruktur und Pipelines konzentrieren. Er appelliert: „Lassen Sie uns keinesfalls zu den unterschiedlichen Teams zurückkehren, die nicht miteinander sprechen.“ Tatsächlich sagten in VMwares Analyse „State of Kubernetes in 2022“ immerhin 54 Prozent der Befragten, die Einführung von Kubernetes habe die Entwicklereffizienz verbessert. Und mehr als ein Drittel (37 Prozent) gaben an, jetzt auch die Effizienz der Ops-Teams verbessern zu wollen.

Container-Umgebungen haben allerdings den Nachteil, dass es immer nur wenige Spezialisten gibt, die sich damit auskennen. „Machen

Viele weitere Informationen rund um das Thema DevOps finden Sie online auf der Website der COMPUTERWOCHE unter: DevOps – es gibt „room for improvement“ Wie DevOps die IT beschleunigen www.cowo.de/30714337 Fallstricke: Wie DevOps im Fail endet www.cowo.de/3551240 Data Governance: Das sollten DevOps-Teams wissen

Sie nicht den Fehler, aus jedem einen Experten machen zu wollen“, empfiehlt Kaspar von Grünberg, Gründer der Entwicklungsplattform Humanitec, in einem Blogbeitrag. In jedem leistungsstarken Team gebe es nur wenige echte Experten für Kubernetes. „Die Teams bemühen sich, das Abstraktionsniveau für alle hochzuhalten, damit die kognitive Belastung für das gesamte Team nicht zu hoch wird.“

DevOps ist tot – und jetzt?

Als DevOps-Alternative bietet sich der Ansatz Site Reliability Engineering (SRE) an, den Google entworfen hat. Ben Treynor, Vice President of Engineering bei Google und Pate von SRE, beschreibt die Idee wie folgt: „Im Grunde ist es das, was passiert, wenn man einen Softwareingenieur bittet, eine Operations-Funktion zu designen.“

Die Einführung eines SRE-Sicherheitsnetzes – sowohl auf der zentralen Betriebsebene als auch innerhalb der einzelnen Entwicklerteams – hat beispielsweise den US-Finanzdienstleistern Vanguard und Morgan Stanley dabei geholfen, die richtige Balance zwischen Entwicklungsgeschwindigkeit und Betriebsstabilität zu finden. Beide Unternehmen hatten bei der Umstellung auf Cloud-Native-Methoden Schwierigkeiten, Dev- und Ops-Aufgaben miteinander in Einklang zu bringen. Frei von Kritik ist allerdings auch SRE nicht: „Die Einführung von SRE-Prinzipien wird manchmal als Rebranding des Ops-Teams missverstanden“, stellt Trevor Brosnan, DevOps-Verantwortlicher bei Morgan Stanley, fest.

„Es ist ein differenziertes Problem, das es zu lösen gilt“, ergänzt Christina Yakomin, Site Reliability Engineer bei Vanguard. „Die Einführung von SRE gibt den Leuten das Gefühl, dass wir die Ops wieder zurück in ein Silo drängen wollen. Tatsächlich möchte ich aber unsere Entwickler und Betriebsspezialisten dazu ermutigen, die Verantwortung für die Sicherheit zu teilen und sicherzustellen, dass Teams mit gemeinsam genutzten Plattformen die volle betriebliche Verantwortung übernehmen.“

Um Entwicklern die für ihre Arbeit nötigen Tools an die Hand zu geben, ist darüber hinaus die Idee von internen Entwicklungsplattformen beziehungsweise von Platform-Engineering entstanden. Diese geben den Devs die Tools, die sie brauchen, und sorgen parallel auch für die entsprechenden organisatorischen Leitplanken, damit sie sich auf ihre Kernaufgaben konzentrieren können. Solche internen Entwicklerplattformen bieten in der Regel:

► APIs,

► Tools,

► Services,

► Know-how und

►Support.

Dinge also, die Entwickler benötigen, um ihren Code produktiv zu erstellen. Das wird zu einer unternehmenseinheitlichen Plattform kombiniert, die von einem engagierten Team von Spezialisten oder Product Ownern gepflegt wird.

Devs brauchen ein Plattform-Team

Die Aufteilung in Plattform-Engineering-Teams funktioniere in der Praxis häufig gut, bestätigt Brandon Byars, Leiter der Technologieabteilung bei Thoughtworks. Die Reibungsverluste für die Entwickler seien gering, gleichzeitig behielten sie die Möglichkeit, an den wichtigen Reglern zu drehen. Der Experte schränkt jedoch ein: „Wenn man von den Devs verlangt, all diese Arbeit ohne ein übergeordnetes Plattform-Team und ohne entsprechende Tool-Unterstützung zu leisten, funktioniert es nicht mehr gut.“

Jedem Unternehmen, das sich mit DevOps-Praktiken beschäftigt hat, ist der Spagat zwischen Softwareentwicklungs- und Betriebsteams vertraut. Es ist ein Balanceakt, der im Zeitalter der Cloud-Native-Komplexität immer schwieriger zu bewältigen ist.

(fm)