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.

Transcript

1. codecentric AG Patrick Peschlow DEVOPS ENTWICKLUNG, BETRIEB... UND SOFTWAREARCHITEKTUR ?
2. codecentric AG Am Anfang war Dev = Ops …
3. codecentric AG Ein bisschen Geschichte
4. codecentric AG Ein bisschen Geschichte DEV OPS
5. codecentric AG Ein bisschen Geschichte DEV OPS en.wikipedia.org/wiki/File:AlamereFalls.JPG
6. codecentric AG Ein bisschen Geschichte AGILE
7. codecentric AG Ein bisschen Geschichte
8. codecentric AG Ein bisschen Geschichte WATER – SCRUM – FALL
9. codecentric AG Ein bisschen Geschichte
10. codecentric AG Ein bisschen Geschichte
11. codecentric AG DevOps − Versucht das „Water-Scrum-Fall“-Problem zu lösen − 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
12. codecentric AG Zusammenarbeit − DevOps schließt alle mit ein − 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
13. codecentric AG Prozess − Einsehbare, klar definierte Aufgaben (Tasks) − Gemeinsame, agile Planung von Etappenzielen − Schließt Release-Planung mit ein − Kontinuierliches Feedback − Kanalisiert nach klaren Regeln − Anwendung einer Reihe von Praktiken
14. codecentric AG Praktiken − Schlüsselbegriff „Continuous“ − Automatisierung mit geeigneten Tools sdarchitect.wordpress.com/2013/10/16/understanding-devops-part-6-continuous-deployment/
15. codecentric AG Automatisierung
16. codecentric AG Continuous Integration − Versionskontrolle − Build-Server − Zentraler Speicher für Artefakte
17. codecentric AG Continuous Delivery − Build-Pipeline
18. codecentric AG Continuous Delivery − Automatisierte Konfiguration und Start von Servern − Virtualisierung − ggf. Public oder Private Cloud − Infrastructure as Code − Wiederverwendung für alle Umgebungen − Versionskontrolle − Änderungen werden dadurch dokumentiert − Automatisiertes Deployment
19. codecentric AG Continuous Testing − Unit Tests, Integration Tests − 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
20. codecentric AG Continuous Monitoring − Performance-Daten und Fehler aus Testumgebungen 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
21. codecentric AG Lohnt sich DevOps ? − Mehrwert von DevOps 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
22. codecentric AG Welche Rolle spielt Softwarearchitektur im DevOps-Kontext? − Kein 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
23. codecentric AG Auswahl von Komponenten − Horizontale Optimierung vs. vertikale 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
24. codecentric AG Lose Kopplung und Fehlertoleranz − Definiere einfache, abstrakte 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
25. codecentric AG Versionierung von APIs − Versioniere APIs − Am 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
26. codecentric AG Logging − Logging ist selbstverständlich, nützliches Logging leider nicht − Geeignete Wahl von Logleveln − Strategie für Exceptions/Errors − Zentralisierung von Logs − Einfache Suche- und Abfragemöglichkeiten − Nutze Tools − Graylog2, logstash, fluentd, …
27. codecentric AG Einheitliches Monitoring − Sammeln/Auswerten relevanter Daten findet oft 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
28. codecentric AG Kritische Betrachtung von Komplexität − Inhärente vs. freiwillige 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
29. codecentric AG Feature Flags − Vorbereiten von Features ohne Gefahr 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
30. codecentric AG Deployment − Automatisiertes Rolling Upgrade − Ggf. laufende 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
31. codecentric AG Fazit − DevOps − Zusammenarbeit − Prozess − Automatisierung − Softwarearchitektur − Kann förderlich oder hinderlich für die Umsetzung von DevOps sein devopsdays.org/blog/wp-content/uploads/2010/05/itsdevops.pn
32. codecentric AG Referenzen − Allgemeine Liste von Quellen und Weblinks 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“
33. codecentric AG Fragen? Dr. rer. nat. Patrick Peschlow codecentric AG Merscheider Straße 1 42699 Solingen tel +49 (0) 212.23 36 28 54 fax +49 (0) 212.23 36 28 79 patrick.peschlow@codecentric.de www.codecentric.de