Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps: Entwicklung, Betrieb... und Softwarearchitektur?

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.

Patrick Peschlow

November 06, 2013
Tweet

More Decks by Patrick Peschlow

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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
  4. codecentric AG Praktiken − Schlüsselbegriff „Continuous“ − Automatisierung mit geeigneten

    Tools sdarchitect.wordpress.com/2013/10/16/understanding-devops-part-6-continuous-deployment/
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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, …
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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“
  20. 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 [email protected] www.codecentric.de