Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Architektur und Automation als Enabler für DevOps

DevOps kann man nicht kaufen, es ist etwas das man selber machen muss und auf seinen Kontext, seine Kultur und Technologie anpassen. Es gibt aber gewisse Faktoren, welche die Transformation zu DevOps begünstigen Auf zwei davon geht diese Präsentation näher ein: Die Architektur im Unternehmen und in Anwendungen, und der Automatisierungsgrad im gesamten DevOps-Zyklus

  • Login to see the comments

  • Be the first to like this

Architektur und Automation als Enabler für DevOps

  1. 1. Architektur und Automatisierung als Enabler für DevOps 1. DevOps Meetup Bern, 29. Mai 2017 Matthias Fritschi, Software Architect & Consultant, avega IT AG
  2. 2. Themen ■ Was haben Architektur & Automation mit DevOps zu tun? ■ Case Study I: Online- & Cross-Channel Systems Dev 🚧 Ops ■ Case Study II: Customer Information System Dev 💚 Ops ■ Fazit
  3. 3. Das DevOps- Modell für diesen Talk
  4. 4. „You Can‘t Buy DevOps“ ... aber es gibt gewisse Enabler welche die Transformation begünstigen Zusammenarbeit Architektur Automation Kurze Feedbackzyklen Plattformen SystemdenkenOrganisation Gemeinsame Verantwortung Technologie Continuous Everything Kultur Transparenz
  5. 5. „You Can‘t Buy DevOps“ ... aber es gibt gewisse Enabler welche die Transformation begünstigen Architektur Automation
  6. 6. Architektur As I observed, large organizations using DevOps “have thousands of developers, but their architecture and practices enable small teams to still be incredibly productive, as if they were a startup“. -- Randy Shoup, A Director Of Engineering At Google [...] In this scenario, everyone feels productive - the architecture allows small teams to work safely and architecturally decoupled from the work of other teams, using self-service platforms that leverage the collective experience of Operations and Information Security. -- Gene Kim, „The DevOps Handbook“
  7. 7. Cloud-Native & 12-factor Apps 12 Factor Apps • Eine versionierte Codebasis • Explizite Deklaration von Abhängigkeiten • Konfiguration als Teil der Umgebung • Backends als Ressourcen behandeln • Build, Release, Run - Separiert • Prozesse sind Stateless • Service-Exposition über Ports • Skalierung übers Prozessmodell • „Wegwerf“-Prozesse: Kurzer Startup/Shutdown • Dev & Prod gleich aufgesetzt • Logs als Event-Streams • Admin-Tasks als einmal-Prozess
  8. 8. Cloud-Native & 12-factor Apps Infrastruktur innert Minuten aufgesetzt Infrastruktur-Provisionierung und Konfiguration automatisierbar 1 Binary – viele Umgebungen Schnelleres Testumgebungssetup Konfiguration, Infrastruktur versioniert Skalierbarkeit Parität Dev/Prod Standardisierung Unterbruchsfreies Deployment
  9. 9. Modularisierung ➡
  10. 10. Modularisierung Einfacheres Rollback Unabhängige Releases Wartbare, fokussierte Tests Schnellere Builds & Tests Forcierte Entkopplung Unabhängige Skalierbarkeit Separater Lifecycle Resilienz Komplexität managen
  11. 11. Automation “Speed is the ultimate defense” -- Elon Musk on being faster than anyone else
  12. 12. Automation “Automate everything and make those parts that can’t be automated a self-service” -- Gregor Hohpe on how corporate IT can remain competive
  13. 13. Automation Statische Code-Analyse, Coverage Continuous Integration Test-Automation Release-Automation (Branching, Tagging, Artefakte) Deployment-Automation Infrastructure-as-Code Automatisiertes Mergen Monitoring, Alerting, Log Aggregation Transparente aktuelle KPIs für Dev & Ops
  14. 14. Case Study I Online- & Cross-Channel Systems
  15. 15. Kontext ☁➡ ➡
  16. 16. Architektur ■ Architektur-Initiative gestartet für Modularisierung, Standardisierung, Cloud-Transformation (Container/PaaS) der Online-Systeme mit dem langfristigen Ziel, DevOps & Continous Deployment einzuführen ❶ Blueprint für Anwendungen basierend auf 12-factor Apps ❷ Gap-Analyse Ist/Soll à Migrationsplan ❸ Umsetzung
  17. 17. Architektur ■ Herausforderung Continous Deployment & Trennung Release/Deployment: Starke Abhängigkeiten durch nicht evolutions-/versionsfähige Schnittstellen 🔒
  18. 18. Automation ■ Beschleunigung des Infrastruktur-Setups von Monaten zu Minuten
  19. 19. Automation ■ Beschleunigung des Infrastruktur-Setups von Monaten zu Minuten Projektdauer / Zeit bis Infastruktur produktiv 6 Monate
  20. 20. Automation ■ Beschleunigung des Infrastruktur-Setups von Monaten zu Minuten Zeitdauer für Infrastruktur-Setup Minuten Projektdauer / Zeit bis Infastruktur produktiv 6 Monate
  21. 21. Automation ■ End-to-End Business Process Monitoring entlang des User Journeys für Dev & Ops & & & &➡ ➡ ➡ ⏱💥✅
  22. 22. Lessons Learned ■ Viel schnellere Provisionierung von Infrastruktur und OS mit dynamischer Infrastruktur & Container ■ Modularisierung bringt Flexibilität und Autonomie, aber Komplexität muss gemanagt werden ■ Gemeinsame Tools, Prozesse führen zu gemeinsamer Verantwortung
  23. 23. Case Study II Transportation Information System
  24. 24. Kontext Deployment von neuen Features ohne Downtime Speed: Beispiel Bugfix, innert 2 Stunden von Discovery bis in Produktion Technologie: Plattform-/Service-basiert
  25. 25. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services
  26. 26. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services Separat Verteilbare Services
  27. 27. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services Stateless Services, Horizontal skalierbar
  28. 28. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services Stateful TCP à HTTP (Load Balanced)
  29. 29. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services Rückwärtskompatible Interfaces (JSON, iterative Changes, Versionierung)
  30. 30. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services Resilienz (Retry, Timeout, Healthcheck, ...)
  31. 31. Architektur ■ Cloud Native / 12-factor App ■ Modulare Services Gemeinsame Tools für Dev & Ops
  32. 32. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Statische Code-Analyse zeigt Testlücken und Technical Debt auf
  33. 33. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Änderungen werden nach Pull Request gemergt, Build & Unit Tests getriggert
  34. 34. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Für jedes Feature werden Integrations- und/oder Feature-Tests entwickelt und laufen in jeder Pipeline-Instanz durch
  35. 35. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Binaries werden 1x gebaut und von Test bis Produktion 1:1 verwendet
  36. 36. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Die Laufzeitumgebung ist als Docker-Container versioniert und erhält die Umgebungskonfiguration zur Laufzeit (1:1 selber Container von Test bis Produktion)
  37. 37. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Rollendes Deployment der neuen Version automatisch & kontinuierlich auf die Entwicklungsumgebung. Nach hochfahren des Containers wird geprüft ob die Anwendung korrekt läuft, sonst wird das Deployment abgebrochen. Die alte Version wird nach & nach heruntergefahren.
  38. 38. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Deployment-Automatisierung auf Staging und Produktion gleich wie auf Development. Je nach Bedarf manuelle Q/A-Checks auf Staging. Trigger auf Staging und Prod noch manuell. Keine Downtime durch rollendes Deployment, tagsüber jederzeit möglich.
  39. 39. Automation ■ Standardisierte PaaS-Cloud-Infrastruktur ermöglichte den Aufbau der automatisierten Deployment Pipeline Monitoring und Log-Aggregation als SaaS-Lösung bezogen. Geringer Aufwand fürs Entwicklungsteam, trotzdem gute UX für Dev & Ops.
  40. 40. Automation ■ Infrastructure as Code Ops kann die Laufzeitumgebung mit Limiten, Verrechnung etc. im Self-Service einrichten
  41. 41. Automation ■ Infrastructure as Code Dev/Ops beschreiben nötige Endpoints, Skalierung, Network, Konfiguration, Container-Builds als versionierte Deklaration (OpenShift & Docker).
  42. 42. Automation ■ Infrastructure as Code Infrastruktur-Setup automatisiert mittels Deklaration. Jede Umgebung erhält ihre spezifische Konfiguration, das restliche Setup ist identisch von Entwicklung bis Produktion.
  43. 43. Automation ■ Infrastructure as Code Initiales Setup des gesamten Prozesses mit Lernkurve in 2 Tagen. Setup einer zusätzlichen Anwendung in 2 Stunden.
  44. 44. Lessons Learned ■ Architektur und Automatisierung machen schnelle, kleine Deployments tagsüber ohne Downtime möglich ■ Monitoring/Logging als SaaS-Lösung eingesetzt und mit wenig Aufwand integriert – gemeinsame Tools für Dev & Ops ■ Cloud-Plattform ermöglicht die Konzentration auf fachliche Entwicklung und stellt Ops standardisierte Infrastruktur zur Verfügung
  45. 45. Fazit ■ Die Vorteile von DevOps lassen sich nur mit konsequenter Automatisierung wirklich realisieren – Refactor your Processes ■ Die Architektur muss diese Automatisierung erlauben und unterstützen

×