In the Code: Alle lieben DevOps - oder?

4. Mai 2015, 07:41
  • developer
  • elca
  • kolumne
image

Patrik Stampfli über die schwierige, aber fruchtbare Beziehung zwischen Entwicklung und Betrieb.

DevOps ist in aller Munde und der Name das Programm: Der aus Development (Entwicklung) und Operations (Betrieb) zusammengesetzte Begriff umschreibt das Zusammenführen und die intensivere, agile Zusammenarbeit von Entwicklung und Betrieb. Vorreiter des Konzepts sind die Internetriesen Google und Facebook, da es gerade in der B2C-Online-Welt unerlässlich ist, tagesaktuell und in hoher und kundenzufriedenstellender Qualität, neue Funktionalitäten oder Korrekturen schnell zu entwickeln und in das System zu integrieren.
Inzwischen bescheinigen auch die grossen Marktforscher diesem Trend Relevanz, der allerdings die alten IT-Strukturen ziemlich aufrüttelt. Schliesslich ist das jeweilige Hauptinteresse von Development und Operations scheinbar gegensätzlich: Während die Entwickler unter dem Druck des Geschäfts möglichst schnell möglichst viele neue Software-Releases veröffentlichen möchten, hat die Stabilität des IT-Betriebs höchste Priorität für Operations – und Änderungen wie ein neues Release stellen ein potentielles Risiko für diese (hart erarbeitete) Stabilität dar. Dies führt dazu, dass Development und Operations im Hinblick auf ihre Einstellung und die intern häufig unabhängig voneinander agierenden Organisationen wie durch eine Art Mauer getrennt waren beziehungsweise sind (die sogenannte "Wall of Confusion").
Die folgenden zwei Zahlen zeigen die divergierenden Interessen anschaulich auf: Die meisten Unternehmen geben mehr als 80 Prozent ihres IT-Budgets für Betrieb und Wartung aus. Das heisst, ziemlich wenig Budget fliesst in neue Entwicklungen und Innovationen. Gleichzeitig sind Änderungen wie Releases mit ebenfalls rund 80 Prozent der Hauptgrund für Systemausfälle und Downtimes – die Operations natürlich vermeiden will.
Aus Business- und Managementsicht ist es selbstverständlich erstrebenswert, beide Kennzahlen zu reduzieren und das DevOps-Konzept bietet nun (endlich) eine Antwort auf diese verzwickte Situation: Die "Wall of Confusion" zwischen den Entwickler- und den Betriebs-Teams soll verschwinden, indem beide Seiten von Beginn an in den Entwicklungs- und Lieferprozess eingebunden werden, sich austauschen und so die jeweils andere Seite besser verstehen.
Umdenken: "On-air"-Software durch DevOps
Die Vorteile des Konzepts sind vielversprechend und überzeugend: Durch DevOps können Software, neue Funktionalitäten oder Verbesserungen schneller entwickelt werden und live gehen. Es geht also wie beim agilen Ansatz darum, kontinuierlich zu optimieren und so die geschäftliche Dynamik wie auch die Akzeptanz der Anwender zu erhöhen. Dafür müssen bestimmte Infrastrukturen, Abläufe und Automatisierungen installiert werden. Continuous Integration und Continuous Delivery sind Voraussetzungen für DevOps, das erst eine wirkliche End-to-End-Agilität in der Softwareentwicklung ermöglicht. Last but not least, soll DevOps die IT produktiver und kosteneffizienter machen und sie noch stärker ans Business angleichen.
Die Herausforderungen, denen sich eine moderne IT heute stellen muss, sind gleichzeitig auch Treiber der DevOps-Bewegung:
1. die 24/7-Self-Service-Mentalität, die die Kunden heute fordern (für die die heutigen Back-Office-Systeme aber nicht gemacht sind)
2. die wachsende Notwendigkeit nach Agilität (warum planen, wenn die Pläne schneller überholt sind als sie freigegeben werden?)
3. die digitale Beschleunigung, die es notwendig macht, Innovationen schnell zu entwerfen und live zu bringen und gleichzeitig die Stabilität der Systeme zu gewährleisten (weil sonst User beziehungsweise Kunden abspringen, was zu Umsatzeinbussen und im schlimmsten Fall zu Kundenverlust führt).
Was bedeutet das nun alles für die IT? Die 24/7-Verfügbarkeit reformiert die Art und Weise der Entwicklung – von "zu testender Software" hin zu "On-air"-Software. Der hohe Bedarf an Agilität verändert auch die IT-Governance; weg von globalen Plänen hin zu momentanen Aktionsplänen und die digitale Beschleunigung beeinflusst die Art und Weise, wie wir Stabilität erreichen – anstelle von Zyklen mit einigen wenigen Releases wird Stabilität durch die kontinuierliche Lieferung erreicht. Dies natürlich nur, wenn die kontinuierliche Lieferung wie auch die Live-Schaltung neuer Releases standardisiert und automatisiert wird und so häufig passiert, dass ein Release zum (stabilen) Alltagsgeschäft wird.
Design-Build-Run-Zyklus ist überholt
Der klassische Design-Build-Run-Zyklus, der die Konzeption, die Entwicklung und den Betrieb von Software in drei Schritte oder Phasen aufteilt, wird ersetzt durch eine zusammenhängende Prozessschleife, die den gesamten Lebenszyklus von der Entwicklung bis zum Betrieb abdeckt, wobei der Betrieb direkt wieder in die Planungsphase für Verbesserungen übergeht.
Um das DevOps-Konzept umzusetzen, braucht es die effektive Zusammenarbeit zwischen Entwicklern und dem Betrieb – das heisst zum einen:
- Gemeinsame Umgebungen und eine gemeinsame Pipeline sowie tägliche Meetings, in denen die Probleme gemeinsam diskutiert und vor allem gelöst werden.
- Gemeinsame Tools, die von beiden Seiten genutzt werden. Das vereinfacht nicht nur die Kommunikation, weil alle dieselbe Auswertung / Darstellung bekommen, sondern führt quasi automatisch dazu, dass beide Seiten auf ihre Art versuchen, negative Ausschläge und Störfälle zu beheben.
- Die Entwickler müssen ihre Arbeit täglich im Hinblick auf Stabilität diagnostizieren und anpassen und lernen so, bei der Entwicklung mehr und mehr den Betrieb der Applikation direkt mitzudenken – das gilt anders herum auch für den Betrieb.
- Ein proaktives Business-Monitoring zeigt umgehend Fehlerquellen oder Optimierungspotenzial auf.
Zum anderen braucht es für DevOps einen hohen Grad an Automation beim Testing und beim Application Monitoring.
Die Programmierung der Roboter für das Aufsetzen des automatischen Testings ist übrigens ein geeignetes Anfangsprojekt, um Entwickler und Operations tatsächlich näher zusammen zu bringen. Denn hier müssen beide gemeinsam an einem konkreten Projekt arbeiten und sich bereits intensiver mit der jeweils anderen Seite auseinandersetzen.
Wichtige Eckpfeiler: Pipeline und Testen
Kernelement der DevOps-Organisation ist die "Deployment Pipeline", die die Software durchläuft und die aus verschiedenen Umgebungen besteht. Die erste Umgebung ist speziell für das automatische Testen. Hier wird alle paar Minuten automatisch kontrolliert, ob Struktur und Aufbau der Software durch neu entwickelte Änderungen beschädigt wurden. Der nächste Schritt in der Deployment Pipeline ist die Umgebung für Integration – die Hauptumgebung, in der Entwickler die Auswirkungen ihrer Entwicklungen auf das System testen können. Viele dieser Tests sind manuell, die Integrationsumgebung wird häufig upgedatet und ist dadurch noch instabil. Ziel der Tester ist es, den Code zu brechen. Sobald die Software stabilisiert ist, wird sie in die nächste Umgebung verschoben: die Validierung, in der das nächste grössere Release gemäss der Spezifikationen getestet wird. Nun wandert die Software weiter in die Umgebung für Performance-Testing. Neben der Leistung werden hier auch andere Arten von nicht-funktionalen Tests durchgeführt. Bevor die Software nun in die Produktion und damit live geht, folgen noch zwei weitere Umgebungen: die für Support und für die Pre-Production. In der Support-Umgebung werden einige der Korrekturen und dringende Funktionalitäten des nächsten grösseren Release in aktuelle Releases übertragen, so dass diese Funktionalitäten bereits bei einigen der häufiger durchgeführten kleineren Releases aufgespielt werden. In der "Vorproduktion" werden die Versionen, die erfolgreich getestet sind, noch einmal aus der Business-Perspektive überprüft. Ein Augenmerk liegt vor allem darauf, dass die rollende Installation richtig läuft.
Das automatisierte Testen spielt nicht nur am Anfang, sondern im kompletten Prozess eine wichtige Rolle. Einmal im Einsatz, wird das System konstant auf technischer sowie Business-Sicht beobachtet und analysierte Probleme laufen direkt als to-do in den agilen Backlog des Entwicklungsteams.
Software-Fabrik: nicht das Auto, sondern das Fliessband bauen
Die Unternehmen, die DevOps umsetzen möchten – und das sind gemäss einer kürzlich erschienenen Studie immerhin über 70 Prozent der Schweizer Unternehmen –, stehen also vor einer grossen Aufgabe. Neben dem Aufbau von DevOps-Kompetenzen müssen sich vor allem die Arbeitsweise, die Organisation und auch die Strukturen in der IT komplett ändern.
Gerade Unternehmen mit einem 24/7-Omnichannel-Geschäftsmodell und/oder jene, die eine gewissen Grösse im Hinblick auf die Softwarelieferungen erreicht haben, sollten sich intensiv mit DevOps auseinandersetzen, da sie am intensivsten von dem Konzept profitieren können. Viele IT-Anbieter preisen aktuell ihre DevOps-Kompetenzen an oder dass sie gemäss DevOps arbeiten. Für die Unternehmen als Kunden heisst das allerdings noch nicht viel – DevOps ist kein alleinstehendes Projekt. Bildlich gesprochen steht DevOps nicht für ein produziertes Auto (oder ein abgeschlossenes Projekt), sondern vielmehr für den Aufbau des Fliessbands beziehungsweise der ganzen Fabrik, um den Produktionsprozess für Software neu aufzusetzen und gleichzeitig zu standardisieren und so auch zu stabilisieren. Bei ELCA sprechen wir hier von dem Aufbau einer "Software Factory", da die IT komplett umgestaltet werden muss. (Patrik Stampfli)
Über den Autor
Patrik Stampfli leitet als Head of Operations das 150-köpfige Zürcher Team des Schweizer IT-Unternehmens ELCA. Unter anderem hat er die methodischen und infrastrukturellen Rahmenbedingungen für eine agile und betriebsnahe Projektabwicklung bei ELCA mit definiert und eingeführt. Sein Studium der Mathematik schloss Patrik Stampfli an der ETH Zürich ab.
(Interessenbindung: ELCA ist Werbekunde unseres Verlags.)

Loading

Mehr zum Thema

image

Ukrainische IT-Profis im hiesigen Jobmarkt

Die Schweizer ICT-Branche zeigt sich solidarisch mit Geflüchteten aus der Ukraine. Weil sich darunter auch viele IT-Profis befinden, könnten Unternehmen von den Fachkräften profitieren.

Von publiziert am 20.6.2022 1
image

IT-Woche: Fear and Loathing im Cyberspace

Der Untergang einer Software-Firma, die Sperrung des Schweizer Luftraums und die Ransomware-Abwehr eines Kantonsspitals machten diese Woche Schlagzeilen.

publiziert am 17.6.2022
image

#Security: IPv6 – ein unbeliebtes IT-Thema feiert Jubiläum

Die Version 6 des Internetprotokolls wurde vor 5 Jahren als Internetstandard definiert und soll damit als Basis für die Digitalisierung dienen. Ein wichtiges Thema für IT-Betreiber und Sicherheitsverantwortliche.

publiziert am 17.6.2022
image

Berger-Levrault macht Elca zum Vertriebspartner

Elca nimmt die EAM-Lösung Carl Source in sein Angebot auf.

publiziert am 14.6.2022