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

Zeit für Devs und Ops, wieder getrennte Wege zu gehen?


Foto: isaravut – shutterstock.com

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 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 Form sehr viel häufiger Updates niederschlug.

Viele Unternehmen nutzten die Gelegenheit, um diese beiden Spezialistenguppen zusammenzubringen und Probleme gemeinsam in zuvor nicht für möglich gehaltener Geschwindigkeit zu lösen. Manche nahmen den DevOps-Trend allerdings auch einfach zum Anlass, ihren Entwicklern die Verantwortung für operative Aufgaben zusätzlich aufzudrücken.

Emily Freeman, Head of Community Engagement bei Amazon Web Services und Autorin von “DevOps for Dummies”, spricht auf Twitter vielen Entwicklern aus der Seele:

Dass die AWS-Managerin damit offensichtlich einen Nerv getroffen hat, zeigen Hunderte von Reaktionen. Hier einige ausgewählte:

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, ist ihr Fachwissen immer mehr in den Hintergrund getreten – un das, obwohl ihre Arbeitsbelastung 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.”

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 erforderlich hohen Grad iterativer Harmonie aufrecht erhalten 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.

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.” Dabei sei es wichtig, daran zu denken, dass die Implementierung von DevOps von Unternehmen zu Unternehmen variiere. 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 von dem 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 die Produktion zu übertragen.”

Ondat-Manager Brown ist der Ansicht, dass die Container-Orchestrierung mit Kubernetes die unsichtbare Linie zwischen Ops und Devs sei, die deren Belange voneinander trenne. So könnten sich Entwickler auf ihren Code und Operations 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) gab 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 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 Teams 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.”

Wenn DevOps nicht die engültig Lösung für die Software-Entwicklung ist, welche ist es dann? Als beliebt hat sich der Ansatz Site Reliability Engineering (SRE) erwiesen, der Googles DevOps-bedingten Wachstumsschmerzen entsprungen ist. Wenn Sie sich jetzt fragen was das ist – Ben Treynor, Vice President of Engineering bei Google und Pate von SRE, wird diesbezüglich oft wie folgt zitiert: “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 Morgan Stanley fest.

“Es ist ein differenziertes Problem, das es zu lösen gilt”, sagt 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 einen 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 sicherstellen, 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 hat sich darüber hinaus die Idee von internen Entwicklungsplattformen beziehungsweise von Plattform-Engineering herauskristallisiert. 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 stellen. Das wird zu einer unternehmenseinheitlichen Plattform kombiniert, die von einem engagierten Team von Spezialisten oder Product Ownern gepflegt wird.

Der Softwareingenieur und DevOps-Spezialist Sid Palas sieht DevOps vor dem Hintergrund der genannten Probleme bereits als Phänomen der Vergangenheit und setzt auf Plattform-Engneering, wie er im folgenden Twitter-Post verdeutlicht:

Brandon Byars, Leiter der Technologieabteilung bei Thoughtworks, bestätigt Palas. Die Aufteilung in Plattform-Engineering-Teams funktioniere in der Praxis häufig gut. 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)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.