DevOps: Entwicklung, Betrieb... und Softwarearchitektur?
(In German) Presentation held at the 6th Meeting of the Working Group "Software Architecture" of the "Softwareforen Leipzig" in Leipzig on November 6, 2013.
Anspruch/Ziel an den Software-Lebenszyklus: − Generiere schnell und zuverlässig Mehrwert für die Nutzer/Kunden der Software − Und damit auch für das eigene Unternehmen − Ansammlung von Praktiken zur Balance zwischen Innovation und Stabilität − Wende durchgängig Agile und Lean Prinzipien an − DevOps = Zusammenarbeit + Prozess + Automatisierung
Stakeholder bzw. Product Owner − Entwicklung − QA − Betrieb − Gemeinsame Ziele und Definition von „Erfolg“ − Schaffung gemeinsamer Anreize − Kultur des Sharing − Gemeinsame Retrospektiven − „Noch besser“ geht immer
Gemeinsame, agile Planung von Etappenzielen − Schließt Release-Planung mit ein − Kontinuierliches Feedback − Kanalisiert nach klaren Regeln − Anwendung einer Reihe von Praktiken
Servern − Virtualisierung − ggf. Public oder Private Cloud − Infrastructure as Code − Wiederverwendung für alle Umgebungen − Versionskontrolle − Änderungen werden dadurch dokumentiert − Automatisiertes Deployment
Als Bestandteil von Continuous Integration − Nichtfunktionale Tests − Sind nur auf möglichst produktionsnahen Umgebungen aussagekräftig − Akzeptanztests − Sind immens wichtig, werden aber oft stiefmütterlich behandelt − Oft unterschätzt: − Testdatenmanagement − Geeignetes Formulieren von Testfällen − Generierung realistischer Last
direkt auswerten − Laufend Daten von der Produktionsumgebung auswerten − Unmittelbar Alarm schlagen wenn etwas verdächtig ist − Nicht nur Ops − Oft unterschätzt: − Im Alarmfall müssen die relevanten Informationen schnell auffindbar sein − Auswirkungen von False Negatives
für das Unternehmen: − Ideen werden schneller umgesetzt und an die Endnutzer ausgeliefert − Mehr Spielraum für Innovationen − Höhere Stabilität − Eine Umsetzung von DevOps kann dauern und anstrengend sein − Vor allem bei großen/verteilten Teams oder bei Outsourcing − Klein anfangen, aber trotzdem alle ins Boot holen − Faustregel: − Potentieller Mehrwert als Auslöser − Gemeinsamer Wille als Voraussetzung − Automatisierung als Enabler
zwingender Zusammenhang − Kein einziger Aspekt von Softwarearchitektur wird ausschließlich durch DevOps bedingt oder ist deshalb neu erfunden worden − Aber jede Menge Synergieeffekte − DevOps-Praktiken passen sehr gut zu einer ganzen Reihe bekannter Architekturaspekte − Eine geeignete Softwarearchitektur kann die Umsetzung von DevOps begünstigen
Optimierung − Dev sagt: Vertikal! − Wähle die optimale Architektur für die Anwendung − Ops sagt: Horizontal! − Ermögliche Wiederverwendung bekannter/bewährter bzw. bereits betriebener Komponenten − DevOps sagt: Collective Ownership! − Gemeinsame Abstimmung von Beginn an − „Infrastructure as Code“ und „Continuous Delivery“ sorgen dafür, dass die Komponenten sich bereits bewährt haben wenn sie produktiv gehen
APIs − Unabhängigkeit und leichte Austauschbarkeit − Mehr Freiheiten bei Test und Deployment − Schnellere Reaktion auf geänderte Anforderungen möglich − Rechne mit Fehlern zur Laufzeit − Komponenten (Hardware/Software) werden ausfallen − Strebe „Fail-fast“ bzw. „graceful degradation“ an − Nutze Circuit Breaker
besten so früh wie möglich − Keep it simple − Wichtig ist die Abwärtskompatibilität bei Einführung einer „neuen“ Version − Ermöglicht das teilweise Ausrollen von Änderungen − Zum Beispiel für schnelles Feedback bei neuen Features − Und mögliche Rollbacks − Vereinfacht laufende Migrationen
erst in Produktion statt − Denn nur dort wird lizenzpflichtige Monitoring-Software eingesetzt − Monitoring wichtiger Metriken sollte frühzeitig stattfinden − Dev − Test − DevOps: Gemeinsame Definition von Metriken − Explizite Unterstützung von Monitoring durch die Applikation − Nicht nur Black Box
Komplexität − Wichtig bei Entscheidung für bzw. gegen Komponenten/Tools/Bibliotheken − Wie viel Zeit spart die Verwendung? − Wie viel (unnötig) komplexer wird das System? − Prototypen können gesondert behandelt werden − Schneller Proof-of-Concept ist oft wichtig
für das Produktionssystem − Trotzdem frühzeitige Integration − Alternative zu Branches im Versionskontrollsystem − Release eines Features = Aktivieren eines Flags − Kann auch im Betrieb geschehen − Hohe Flexibilität − Rollback kann ggf. durch Deaktivieren des Flags realisiert werden − Ermöglicht Ausrollen von Features nur für einen Teil der Benutzer
Migration − Schrittweise über alle Server bzw. „Blue-Green Deployment“ − Unterstützt durch die Anwendung − Kann schon frühzeitig getestet werden − Ausliefern von Features nur für einen Teil der Nutzer oder Clients − „Canaries“ − Mittels Feature Flags oder Load Balancer commons.wikimedia.org/wiki/File:Canary.jpg
Automatisierung − Softwarearchitektur − Kann förderlich oder hinderlich für die Umsetzung von DevOps sein devopsdays.org/blog/wp-content/uploads/2010/05/itsdevops.pn
in „Die DevOps-Bewegung“: − www.codecentric.de/kompetenzen/publikationen/die-devops-bewegung/ − Weiterführende Quellen für die Darstellung in diesem Vortrag: − sdarchitect.wordpress.com/2013/10/16/understanding-devops-part-6- continuous-deployment/ − Bücher: − Michael Nygard: „Release It! “ − Jez Humble, David Farley: „Continuous Delivery“
peschlowp
sugamasao
tkikuchi
kamina_zzz
abemii
oracle4engineer
kakehashi
cmusudakeisuke
shigashiyama
nikkei_engineer_recruiting
fullkaiten
sansantech
salaboy
soudai
chriscoyier
stephaniewalter
tammyeverts
sachag
hatefulcrawdad
erikaheidi
brad_frost
garrettdimon
ufuk
aki_iinuma
kneath
