Development und Operations sollen besser zusammenarbeiten, um agile Arbeitsmethoden im Unternehmensalltag zu erreichen - das Zauberwort heißt dementsprechend DevOps. Hierbei müssen jedoch einige wichtige Regeln beachtet werden. Welche Regeln das sind und welche nützlichen Tipps und Tricks es außerdem zu dem Thema gibt, erfahren Sie im folgenden Blogpost.

New Relic Background

Einleitung: Ein Sturm an Komplexität

Da DevOps über die letzten Jahre deutlich an Bekanntheit zugelegt hat und Unternehmen dadurch immer größer werdende Erfolge verzeichnen, ist es nun an der Zeit, einen Blick auf ausgewählte Folgen von DevOps und cloud-basierten Technologien zu werfen: Firmen werden zwangsläufig mit einer wachsenden Komplexität konfrontiert, wenn sie beispielsweise Microservices oder Container in der Cloud verwenden. Was jedoch nicht bedeutet, dass DevOps und cloud-basierte Ansätze schlecht sind - im Gegenteil - die Vorteile überwiegen bei Weitem die Komplexität. DevOps bringt aber durchaus ein Risiko mit sich, das Unternehmen minimieren müssen, bevor es sich negativ auf IT und geschäftliche Resultate auswirkt. DevOps-gebundene Unternehmen, die noch nicht die Fertigkeiten, Best Practices und Tools für die nächste Phase der modernen Anwendungsentwicklung erworben haben, werden es deutlich schwieriger haben, ihre Ziele in Bezug auf ihre Anwendungsperformance und Lieferbarkeit weiterhin zu erreichen.

Lang lebe DevOps!

Im “State of DevOps 2019” Bericht stellt das DevOps Research and Assessment (DORA) fest: “Viele Analysten berichten, dass die Branche in Bezug auf DevOps und technologische Wandlung die Umstellung gemeistert hat und unsere Analyse in diesem Jahr bestätigen diese Beobachtungen. Die IT-Industrie wächst rasant und Geschwindigkeit sowie Stabilität sind beides möglich. Wobei die Umstellung auf Cloud-Technologien diese Entwicklung beschleunigt.” Während der Bericht von DORA die Cloud als Treibstoff für Geschwindigkeit und Stabilität bezeichnet, zeigt die Analyse, dass der Einsatz von Cloud Computing auch die Performance und Verfügbarkeit von Software voraussagt.

Cloud Computing auf AWS ermöglicht es beispielsweise, Self-Service-Methoden für die Bereitstellung von Infrastrukturen über den AWS Service Catalog zu nutzen. Entwickler können somit schneller neue Produkte auf den Markt bringen, da sie durch den AWS Service eine automatische Rückmeldung über ihre neu erstellten Features und deren Funktionalität bekommen. Vollständig verwaltete Services helfen Teams die Vorteile der AWS-Ressourcen zu nutzen, da sie die Automatisierung in Form von AWS Developer Tools unterstützen.

Die DevOps Rollen: Ursprünglich waren die Rollen und Verantwortlichkeiten innerhalb von DevOps klar definiert:

Dev: Entwickler besitzen ihre Anwendungen End-to-End - einschließlich der Infrastruktur, Bereitstellung, Kapazität und mehr. 
Ops: Entwickler verwenden dev-ähnliche Tools zur Verwaltung ihrer Infrastruktur, einschließlich der Überwachung und Automatisierung / Skripting.

Heutzutage gehen diese Rollen jedoch vermehrt ineinander über, da sich ein gemeinsames Ziel geformt hat: “Beseitige alle organisatorischen Barrieren für die optimierte Umsetzung der Anforderungen des Kunden - beschleunigt durch Tooling und Automatisierung.”

Der Preis für den Erfolg

Um die Geschwindigkeit, Agilität, Ausfallsicherheit, Skalierbarkeit und andere Kernvorteile der modernen Anwendungsentwicklung zu erreichen, müssen DevOps-Teams einen Preis zahlen: eine erhöhte Komplexität. Teams modernisieren sich durch den Umstieg von einheitlichen Anwendungen auf kleinere Microservices. Diese sind einfacher zu warten und können jederzeit wiederverwendet werden. Gleichzeitig werden die Anwendungen portabler und skalierbarer, indem sie moderne Technologien wie Container (Docker) und Container-Orchestrierung (Kubernetes) mit Amazon Elastic Container Service (ECS)  und Amazon Elastic Kubernetes Service (EKS)  oder serverlos mit (AWS Lambda) einsetzen.

The new microservices way of building software optimizes for rapid and large-scale change, but there is a cost, and that cost is complexity. With powerful technology like Kubernetes, real risks can result if organizations aren’t ready for the complexity that comes with distributed systems. I implore customers to take serious steps to get ready for modern systems and use modern tools to work with them.”

- Kelly Looney, SI Practice Lead, DevOps, Amazon Web Services


All dies führt zu einer wachsenden Anzahl von Microservices, die über Hunderte von Containern laufen oder als serverless angeboten werden. Nun multipliziert man diese Anzahl mit der täglichen oder stündlichen Bereitstellung vieler verschiedener Dienste und fügt eine laufende Infrastruktur und Automatisierung (bspw. Container, Load Balancing und Autoscaling) hinzu. Der nächste Schritt auf der DevOps-Reise sollte nun sein, hierbei die Komplexität zu bändigen, ohne dabei verwertbare Erkenntnisse zu verlieren.

Kubernetes Cluster-Explorer
Kubernetes Cluster-Explorer, der KPIs für einen bestimmten Pod anzeigt.

3 Wege, um die Komplexität einzuschränken und Ergebnisse kontinuierlich zu verbessern

1. Monitoring

Das Gegenmittel gegen die Komplexität in modernen cloud-basierten Umgebungen ist das Monitoring. Monitoring bedeutet, alle relevanten Daten laufend zu messen und auszuwerten, um sich einen Überblick über die Beziehungen und Abhängigkeiten innerhalb eines Systems, sowie dessen Leistung, zu bilden. Das Monitoring gibt Teams die Möglichkeit, eine vernetzte, kontextbezogene Sicht auf alle Leistungsdaten zentral und in Echtzeit zu sehen, um Probleme schneller zu erkennen, zu verstehen, zu lösen und letztendlich ausgezeichnete Kundenerlebnisse zu liefern.

👉🏻

2. Kurze Feedbackschleifen

Erfolgreiches Versagen, in Form von “schnell Versagen”, ist essenziell in Bezug auf DevOps. Der Autor, Forscher und DevOps-Experte Gene Kim nennt Feedbackschleifen als einen der “Drei Wege” , die die Prozesse, Verfahren und Praktiken von DevOps begleiten. Dabei verweist er auf die Bedeutung der Feedbackschleifen von rechts nach links. Dies bedeutet, diese Schleifen so anzupassen, dass dadurch kontinuierlich Korrekturen vorgenommen werden können. Schnelle Feedbackschleifen kombinieren das Prinzip des Vertrauens mit Tools und Prozessen, die es Teams ermöglichen:

  • Experimente zu fördern: Förderung einer Kultur der Innovation und mutiger Ideen (zusammen mit Misserfolgen), um die Markteinführung und die Einführung neuer Technologien zu beschleunigen und gleichzeitig die Geschäftsergebnisse zu verbessern.
  • ein regelmäßiges Deployment durchzuführen: Ein System von kleinen, häufigen Implementierungen von Mikrofunktionen und Bugfixes, sowie deren Erfolgsmessung.
  • Risiken zu akzeptieren: Kleine Fehler ohne größere Auswirkungen sind in Ordnung, wenn sie die Kosten für ein schnelleres Ergebnis sind. Hierzu gehört die Akzeptanz des Teams, mit dem Verständnis, dass Konsistenz wichtiger ist als Perfektion.
  • aus jedem Fehler zu lernen: Eine genaue und gründliche Dokumentation hilft einem Team aus Vorfällen zu lernen und vorbeugende Maßnahmen ergreifen zu können, um eine Wiederholung des Fehlers zu verhindern. Dabei ist der bevorzugte Weg, eine detaillierte Retrospektive, die sich auf konstruktives Lernen und Verbesserung konzentriert und nicht auf Bestrafung oder Schuldzuweisung.
  • Release-Dashboards zu verwenden: Hierbei wird für jedes Feature-Release ein “Feature Dashboard” erstellt, das die für dieses Feature spezifischen Kennzahlen verfolgt. Das Dashboard sollte die Bereitstellung von Services, sowie die Nutzung von AWS-Diensten ermöglichen, um die Auswirkungen auf die Anwendung nachvollziehen zu können.
KPIs
KPIs, die sich auf die Bereitstellung bestimmter Services beziehen.

Nicht auf andere zeigen! Der Zweck einer guten Retrospektive besteht darin, dass alle Parteien verstehen, wieso etwas falsch gelaufen ist und dadurch wichtige Anhaltspunkte für die Prozessverbesserung bekommen - alles mit dem Ziel, ein Wiederauftreten des Problems zu vermeiden oder zumindest zu mildern. Erfahren Sie in diesem Blogpost, wie Ihre Teams Retrospektiven durchführen sollten.

Nicht auf andere zeigen!  Der Zweck einer guten Retrospektive besteht darin, dass alle Parteien verstehen, wieso etwas falsch gelaufen ist und dadurch wichtige Anhaltspunkte für die Prozessverbesserung bekommen - alles mit dem Ziel, ein Wiederauftreten des Problems zu vermeiden oder zumindest zu mildern. Erfahren Sie in diesem  Blogpost, wie Ihre Teams Retrospektiven durchführen sollten.

3. Kontinuierliche Verbesserung

Um von der Einführung von DevOps zu profitieren, bedarf es einer Unternehmens-Kultur und eines Prozesses, der der kontinuierlichen Verbesserung gewidmet ist. Zu Beginn sollte die Leistung mit den Geschäftsergebnissen korreliert werden. Auf diese Weise kann gezeigt werden, wie sich Infrastruktur- und Anwendungsänderungen letztendlich auf das Kundenerlebnis und die Geschäftskennzahlen auswirken. Wenn die Ergebnisse für das Unternehmen nicht messbar sind, ist es schwer zu belegen, dass die Bereitstellung erfolgreich war. Andere Möglichkeiten, die Leistung von DevOps trotz Komplexität weiter zu verbessern, sind die Verwendung fortschrittlicher Release-Strategien:

  • Bereitstellung einer Sandbox: Zur Förderung von Experimenten gehört auch die Schaffung von Umgebungen, in denen es keine Folgen hat, Risiken einzugehen und neue Ansätze und Technologien auszuprobieren.
  • Aktivieren der Feature-Flag: Wenn eine Freigabe erfolgt, wird die Feature-Flag umgedreht. Dies kann aufgehoben werden, wenn die Dinge nicht wie erwartet laufen.
  • Kommunikation mit den Usern von Diensten: Jede Abteilung sollte sich als User auf Entwicklungsniveau verstehen. Dies ermöglicht einen Raum, in dem neue und frühere Versionen gleichzeitig gewartet werden. Das führt zwar zu mehr Aufwand, der Vorteil liegt jedoch in  risikoarmen Releases.
  • Wahl des Rollout-Ansatzes: Für risikoreichere Features verwendet man einen Rollout auf der gesamten Userbasis. Die Feature-Flag kann hierbei ein Counter anstelle eines Triggers sein (z.B. 0% der User -> 5% -> 10% -> 10% -> 25% -> 50% -> 70% -> 100%).
  • Anwendung des Canary-Testing: Canary-Testing bezieht sich auf die Praxis, eine Code-Änderung für eine Teilmenge von Usern freizugeben und dann zu untersuchen, wie sich dieser Code im Vergleich zu dem alten Code verhält, den die Mehrheit der User vorher noch ausgeführt hat. Canary-Server oder Container führen den neuen Code aus und wenn neue User eintreffen, wird eine Teilmenge von ihnen auf die Canary-Hosts umgeleitet. Monitoring kann dann helfen, die Ergebnisse zu überwachen und zu messen, ob der neue Code korrekt funktioniert.
KPIs
KPIs, die sich auf die Bereitstellung bestimmter Funktionen beziehen.
  • Übernahme von Blue/Green Deployments: Um Ausfallzeiten beim Livegang zu vermeiden und Korrekturen zu beschleunigen, kann das Blue/Green Deployment herangezogen werden. Dabei entstehen zwei nahezu identische Produktionsumgebungen: eine grüne und eine blaue. Zum Beispiel ist hierbei die blaue Umgebung die aktuelle Produktionsumgebung. In der grünen Umgebung werden abschließende Tests durchgeführt und auf deren Grundlage werden User während der Entwicklung in diese Umgebung geleitet. Die blaue Umgebung bleibt dabei unverändert und bietet daher einen schnellen Weg, um bei Bedarf auf den alten Stand zurückzukehren.
  • Nutzen der Vorteile eines Dark Launch: Ein Dark Launch ist ähnlich wie das Canary-Testing. Der Unterschied liegt in den neuen Features die erstmal nur für eine kleine Gruppe an Usern freigegeben werden. Die Reaktionen der User auf das neue Feature können dann fokussiert bewertet werden. Normalerweise sind sich diese User der neuen Funktion nicht bewusst - daher die Namensgebung.

Mehr Informationen zum Thema?

Untenstehend finden Sie zusätzlich einige hilfreiche Ressourcen - egal wo Sie sich auf Ihrer DevOps-Reise befinden:


Über NewRelic

ℹ️
Software- und DevOps-Teams verlassen sich weltweit auf New Relic, um schneller zu werden, bessere Entscheidungen zu treffen und erstklassige digitale Erfahrungen zu machen. Erfahren Sie mehr unter  newrelic.com.