Ein Nachruf auf DevOps

Konzept und Geschichte von DevOps

• DevOps ist ein Konzept, das etwa 2007 eingeführt wurde und darauf abzielte, die Trennung zwischen denjenigen aufzuheben, die Hardware verwalten, und denjenigen, die Software schreiben
• Anfangs war es ein Versuch, die Sicherheit von Code-Deployments zu erhöhen, indem Verfahren und Ideen der NASA nachgeahmt wurden
• Der Prozess der Softwarebereitstellung sah damals wie folgt aus:
  • Das Entwicklungsteam bereitete ein Release der Server-Software vor, das QA-Team testete es anschließend, bevor es an die Kunden ausgeliefert wurde
  • Das Betriebsteam erhielt ein Playbook mit den Softwareänderungen und Anweisungen, wie bei Problemen zu reagieren sei
  • Updates wurden schrittweise im Rechenzentrum ausgerollt und dabei überwacht
  • Ein Deployment-Tag wurde festgelegt, anschließend wurde nach dem Deployment überwacht

Probleme von DevOps

• DevOps war sehr arbeitsintensiv
• Es erforderte Zusammenarbeit zwischen Entwicklungsteam, QA-Team, technischen Redakteuren und Betriebsteam
• Feature-Releases waren langsam, und wichtige Updates wurden priorisiert
• Viele Organisationen führten DevOps aus folgenden Gründen ein:
  • Technische Fachkräfte ließen sich nicht einfach ersetzen
  • Recruiting war schwierig und teuer
  • SaaS-Anbieter reduzierten die Komplexität
  • Die Vorteile von Cloud-Plattformen wurden stark hervorgehoben
  • Entwickler waren unzufrieden damit, dass selbst kleine Änderungen sehr lange bis zum Deployment brauchten

Wie DevOps in der Praxis aussah

• DevOps zielte darauf ab, Entwicklungs- und Betriebsteam zu einem einzigen Team zu verschmelzen
• QA-Teams wurden entlassen, und durch schnelles Deployment und Feedback verkürzte sich die Dauer interner Tests
• DevOps wird manchmal mit Googles SRE verwechselt, aber SRE verfolgt einen strukturierteren und strengeren Ansatz
• Der tatsächliche DevOps-Prozess sah so aus:
  • Entwickler erstellen in git einen Branch und fügen ein Feature hinzu
  • Sie öffnen einen PR, ein Teammitglied prüft ihn, danach wird in main gemergt
  • Das CI/CD-System startet den Build und pusht den Container in die Registry
  • Das CD-System informiert die Server über das neue Release und überwacht, ob das Deployment erfolgreich war
  • Über releasebezogene Metriken werden Veränderungen nach dem Deployment beobachtet

Gründe für das Scheitern von DevOps

• Entwickler testeten in lokalen Umgebungen und deployten dann auf Linux-Server, wodurch kleine Unterschiede entstanden
• Das Betriebsteam überwachte Deployments nicht, was die Problemlösung erschwerte
• Entwickler verfügten nicht über ausreichendes Wissen zum Betrieb von Systemen
• Mit der Einführung von Containern wurden einige Probleme gelöst, die Komplexität des Betriebs blieb jedoch bestehen

Einführung und Grenzen von Containern

• Container lösten das Problem „Auf meinem Rechner hat es funktioniert“
• Sie vereinfachten die Komponenten von Linux-Servern
• Verbleibende Probleme
  • Betrieb (Operate): Erfordert Fachwissen für Infrastrukturwartung, Upgrades usw.
  • Beobachtung (Observe): Schwieriger Aufbau und Betrieb komplexer Monitoring-Systeme
  • Kontinuierliches Feedback: Unzureichende Verarbeitung internen Feedbacks
  • Entdecken (Discover): Mangelnder Wissensaustausch zwischen Teams
  • Planung (Plan): Schwierigkeiten bei zentralisierter Planung

Das Aufkommen von Platform Engineering

• Platform Engineering ist ein Nachfolgekonzept von DevOps: Statt dass Entwicklungsteams den Plattformbetrieb verstehen und Probleme selbst lösen müssen, übernimmt ein Plattformteam diese Aufgabe
• Dieser Ansatz trennt die Verantwortung von Entwicklungsteam und Plattformbetrieb klarer und macht die Rollenverteilung deutlicher, erfordert aber weiterhin viel technisches Know-how
• Sowohl Entwickler als auch Betriebsteam müssen mehr Arbeit leisten

Fazit

• Im Infrastrukturbereich nimmt die Tendenz zu, nach einfachen und nicht plattformgebundenen Tools zu suchen
• Viele Organisationen geben komplexe Technologien wie Kubernetes auf und kehren zu einfacheren Workflows zurück
• Platform Engineering ist keine Universallösung, und Organisationen müssen unterscheiden, was sie wirklich brauchen und was nicht
• Die Vorteile des DevOps-Ansatzes sollten erhalten bleiben, während der Fokus stärker auf Vereinfachung und Stabilität gelegt wird

Meinung von GN⁺

1. Die Entwicklung von DevOps und seine heutige Lage zeigen sehr gut den Wandel der Trends in der Technologiebranche. Es ist interessant zu sehen, wie die Lücke zwischen den anfänglich idealistischen Zielen und der Realität erkannt wird und wie nach pragmatischen Ansätzen gesucht wird

2. Der Übergang zu Platform Engineering wirkt wie ein Versuch, die Grenzen von DevOps anzuerkennen und neue Lösungen zu finden. Doch auch das ist keine perfekte Lösung, und es wird ein maßgeschneiderter Ansatz nötig sein, der zur Größe und den Eigenschaften einer Organisation passt

3. Mit der zunehmenden Komplexität Cloud-nativer Technologien und von Microservices-Architekturen findet eine Neubewertung von Einfachheit und Stabilität statt. Das deutet darauf hin, dass bei Technologieentscheidungen Geschäftswert und Betriebseffizienz noch stärker berücksichtigt werden müssen

4. Die Veränderungen bei DevOps und Platform Engineering unterstreichen die Bedeutung kontinuierlichen Lernens und Anpassens in Softwareentwicklung und Betrieb. Fachkräfte müssen nicht nur neue Tools und Methoden lernen, sondern auch die Fähigkeit entwickeln, ein Gleichgewicht zwischen Geschäftsanforderungen und technischer Komplexität herzustellen

5. Künftige Ansätze für Softwareentwicklung und Betrieb werden voraussichtlich flexibler und situationsgerechter sein. Statt dass große Organisationen und kleine Startups demselben Modell folgen, wird sich der Trend verstärken, je nach eigener Situation die optimalen Prozesse und Tools zu wählen

[kaydash]

Ziemlich oft
haben Führungskräfte
die falsche Vorstellung, dass allein die Einführung des Konzepts DevOps
ohne Anstrengung eine großartige Innovation hervorbringen werde
(egal ob Großkonzern oder Mittelstand)
bei altmodischen Unternehmen

[GN⁺]

Hacker-News-Kommentar

• Der entscheidende Punkt beim Diagramm des "DevOps-Zyklus" ist der Fokus auf "build, test, deploy"

  • Der Schwerpunkt lag auf Geschwindigkeit, technische Exzellenz wurde dabei nicht berücksichtigt
  • Das Operations-Team wurde entlassen und QA wurde umstrukturiert
  • Jedes Team bekam einen On-Call-Plan
  • Für kurzfristige Gewinne wurden dem System chaotische Änderungen aufgezwungen
  • Ein paar Monate später verursachte praktisch jede Änderung Probleme
  • DevOps-Tools waren nützlich, aber teuer und frustrierend
  • Neue Entwickler kennen DevOps nicht, aber sie kennen Container

• Dies ist eine Meinung auf Grundlage der Probleme, die DevOps-Teams erlebt haben

  • Man sollte in der Lage sein, neue Services hinzuzufügen und die Infrastruktur sicher zu verwalten
  • DevOps ist zum Standard geworden, und manuelle Arbeit von Systemadministratoren wird nicht benötigt

• Die Kritik an Kubernetes ist fehlgeleitet

  • Kubernetes ist ein Beispiel für hervorragendes Software Engineering, wird gut unterstützt und läuft überall
  • Es ist besser, Kubernetes zu lernen, als wahllos Bash-Skripte zu verwenden

• Bei DevOps geht es darum, Hürden zu beseitigen, um die Auslieferung von Software zu erleichtern

  • Tägliche Deployments helfen dabei, Code in höherer Qualität auszuliefern
  • Wichtig ist die Option, nur dann deployen zu können, wenn der Code bereit ist
  • Monatliche Releases erzeugen Druck und können zu ineffizienten Entscheidungen führen

• DevOps ist eine Philosophie, keine Methodik

  • Ziel ist es, Operations in den SDLC zu integrieren
  • Die Cloud hat das erleichtert
  • Mit dem Entstehen von "DevOps"-Teams wurde die ursprüngliche Philosophie verzerrt

• Das "Aufbrechen von Silos" durch die Führungsebene ist fast nur Formsache

  • Autorität ohne Verantwortung ist wirkungslos
  • Die besten DevOps-Talente haben Freude daran, sich selbst durch Code zu ersetzen
  • DevOps-Tools sind ausgereift und gut dokumentiert
  • Ein Entwickler, der Kubernetes nicht lernt, ist wie ein Entwickler, der keine Linux-Befehle kennt

• Wenn Nutzer als Tester fungieren können, sollte man das tun

  • Es ist nur eine wirtschaftliche Frage
  • Wenn es viele Kunden gibt, sollten die Nutzer testen; wenn es nur wenige Kunden gibt, muss man selbst testen

• Plattform-Teams sind nur in großen Unternehmen realistisch

  • Kleine und mittlere Unternehmen müssen wegen des Mangels an DevOps-Fachkräften Stress und Risiken in Kauf nehmen
  • Das Fehlen eines Plattform-Teams verursacht viele Probleme

• DevOps ist eine Philosophie, keine Methodik

  • Erfahrungen in Silo-Teams belegen die Notwendigkeit von DevOps
  • DevOps ermöglicht es Teams, ein Projekt vollständig zu verstehen und bereitzustellen

• DevOps hat gute Absichten

  • Schnelle Feedback-Schleifen sind wichtig für die Entwicklungsgeschwindigkeit
  • Man muss die optimale Lösung finden, die zur Organisation und zum Produkt passt