layout: true
class: tnw-white
---
class: middle, center, tnw-title
DevOps
---
layout: true
class: tnw-white
---
# About me
- Michael Scherer
- Softwareentwickler
- Lead Cloud Development bei [the native web GmbH](https://www.thenativeweb.io)
- Mit dem Thema DevOps seit ca. 5 Jahren beschäftigt
- Momentan hauptsächlich Einführung von DevOps- und Cloudstrategien bei einem Kunden
- Immer neugierig darauf, was sich jenseits des Tellerrandes befindet
---
class:split-50
# Agenda
.column[
- Geschichte und Motivation
- Prinzipien
- DevOps ist nicht…
- Culture
- Automation
]
.column[
- Lean
- Measurement
- Sharing
- DevOps in traditionellen Firmen
]
---
class: middle, center, tnw-intertitle
# Geschichte & Motivation
---
# Geschichte
- 1980er und 1990er:
Schlanke und ganzheitliche Organisation (Lean Management)
- um das Jahr 2000:
Agile Entwicklungsmethoden (Extreme Programming, Scrum)
- 2006:
Amazon startet Amazon Web Services ([AWS](https://aws.amazon.com))
- 2009:
Erste [Devopsdays](https://devopsdays.org) Konferenz (Patrick Debois)
---
# Motivation
#### Wahrgenommene Probleme
- Silos
- Manueller Overhead
- Kommunikation
- Unterschiedliche Ziele
- Vertrauen
---
# Motivation
#### Entwicklung einer *DevOps Kultur*
.column[
- Verbessern der Zusammenarbeit zwischen den Teams zur…
- Entwicklung (*Dev*) und
- Betrieb (*Ops*)
…eines Softwareprodukts
- Nicht ausschließlich auf diese beiden Teams beschränkt
- Agile Prinzipien im ganzen Unternehmen
]
.column[
- Ergebnis:
- Schnellere Auslieferung der Software
- Höhere Stabilität und weniger Fehler
- Weniger administrativer Aufwand
]
???
Schlanke Prozesse, aber
- Agile Vorgehensmodelle sind keine Voraussetzung
- Auch mit z.B. ITIL kombinierbar
---
# Optimierungen
Hauptsächlich 3 Bereiche:
- Interaktionen
- Prozesse
- Werkzeuge
Iterativer Prozess
Basiert auf *Vertrauen*. Wird mit jeder Iteration verstärkt.
???
Bild:
Interaktionen
/ \
Prozesse-----Werkzeuge
Vertrauen
---
# Optimierungen
#### Interaktionen
Hauptsächlich Verbesserung der Kommunikation
.column[
- Bessere Verbreitung von Wissen
- Unterschiede als Chance
- Gemeinschaftsgefühl
- Innerhalb einer Gruppe
- Zwischen verschiedenen Gruppen
]
.column[
- Transparenz
- Vorbild: Agile Entwicklungsmethoden
]
---
# Optimierungen
#### Prozesse
- Sinn verständlich machen
- Möglichst schlank
- Automatisierung
- Beschleunigung
- Reduzierung von Fehlern
---
# Optimierungen
#### Werkzeuge
- Unterstützen bei Interaktionen und Prozessen
- Nutzen und Probleme abwägen (für *alle* Beteiligten)
- Immer wieder neu bewerten
- Möglichst gleiche Werkzeuge für alle
- Aber: Unterschiedliche Anforderungen berücksichtigen
---
class: middle, center, tnw-intertitle
# Prinzipien
---
# Prinzipien
Es gibt keine verbindlichen Prinzipien
Aber: Bestimmte Begriffe werden häufiger zu Erklärung verwendet
- The Three Ways
- CALMS
---
# The Three Ways
Aus dem Bereich des Lean Management abgeleitet
Ziel: Möglichst kurze Deployment Lead Time
"The Phoenix Project" von Gene Kim, Kevin Behr, George Spafford
???
Bild:
Ticket Start Arbeit Fertig
|--Process Time--|
|-------------Lead Time------------|
---
# The Three Ways
#### The First Way: The Principles of Flow
Technologischer Value Stream: Arbeit fließt von der Entwicklung in den Betrieb
- Arbeit sichtbar machen (z.B. globales Kanban-Board)
- Work in Progress begrenzen
- Arbeitspakete reduzieren
- Anzahl der Übergaben reduzieren
???
Bild:
Dev ----> Ops
---
# The Three Ways
#### The Second Way: The Principles of Feedback
Schnelles Feedback ist bei der Arbeit mit komplexen Systemen wichtig
- Informationen werden in allen Arbeitsschritten gesammelt
- Beschleunigung durch Automatisierung der Build-, Integrations- und Testprozesse
- Keine langen Freigabe-Ketten; Stattdessen z.B. Peer-Reviews
- Monitoring des Produktivsystems
- Alle an Problemlösung beteiligen
???
- Toyota: Arbeit wird gestoppt, wenn Problem nicht sofort gelöst werden kann.
- Qualität müssen DIE Teams sicherstellen, die die Arbeit machen.
Bild:
Dev ----> Ops
\________/
---
# The Three Ways
#### The Third Way: The Principles of Continual Learning
Schaffung einer Kultur des ständigen Lernens
- Vorschläge dürfen nicht ignoriert werden
- Fehler und das Hinweisen auf Probleme dürfen keine negativen Folgen haben
- Zeit reservieren, um die Arbeitsabläufe zu verbessern
- Stresstests des Produkts; Fehler finden, bevor der Kunde es tut
- Neues Wissen in der Organisation verbreiten
???
- Es darf keine Atmosphäre der Angst geben
- Fehler sind die Folge von Veränderungen
Bild:
Dev ----> Ops
\__oooo__/
---
# CALMS
Grundwerte, auf denen DevOps aufbaut
Geprägt von Damon Edwards und John Willis
Von Jez Humble um das *L* erweitert
- Culture
- Automation
- Lean
- Measurement
- Sharing
???
Werden noch näher betrachtet…
---
class: middle, center, tnw-intertitle
# DevOps ist nicht…
---
# …kein Werkzeug
- Aber: Werkzeuge können bei der Entwicklung einer DevOps-Kultur helfen
- Entscheidend ist, *wie* ein Werkzeug verwendet wird
---
# …kein Team
- Und auch kein Job
- Kein Vermittler zwischen Entwicklung und Betrieb
- Die Kompetenzen bleiben bei den jeweiligen Teams
- Die Zusammenarbeit soll optimiert werden
- Gemeinsames Team zur Einführung für erste Projekte möglich
---
# …nicht abschätzbar
- Einzelne Verbesserungen sind messbar
- Aber: Eine Änderung der Kultur kann nicht zeitlich geplant oder abgeschätzt werden
- Iterativer Prozess
- Geschwindigkeit individuell unterschiedlich
---
# …kein Vorgehensmodell
- Kein festes Regelwerk
- Alles ist "DevOps", was Geschwindigkeit und Qualität der Produktion verbessert
---
# …nicht nur für Start-ups und Internetfirmen
- Diese Firmen spüren den Druck zur Optimierung besonders stark:
- Kurze Release-Zeiten sind ein entscheidender Vorteil gegenüber der Konkurrenz
- Fehler betreffen sofort einen großen Teil der Kunden
- Aber: Höhere Geschwindigkeit und Qualität sind immer positiv
---
class: middle, center, tnw-intertitle
# Culture
---
# Culture
- Sozialer Aspekt einer Organisation
- Raum für ständiges Lernen schaffen
- Kommunikation
- Vertrauen
- Oft vernachlässigt
???
Stories:
- Dokumentation
- GitHub
---
# Dokumentation
#### Situation
- Entwickler leitet Informationen an Dokuabteilung weiter
- Die Informationen werden in proprietäres Tool eingepflegt und das Ergebnis dem Entwickler zur Korrektur gegeben
- Solange wiederholt, bis alle zufrieden…
---
# Dokumentation
#### Änderungen
- Neues gemeinsames Datenformat: Markdown
- Versionierung und Kollaboration über GitHub
- Automatisierung des Publishing
- Gleiche Tools für lokale Arbeit und Publish-Pipeline (Docker)
---
# Dokumentation
#### Ergebnis
- Schnelleres Einpflegen von neuen Informationen
- Keine Konvertierung notwendig
- Alle können Änderungen vornehmen
- Bessere Zusammearbeit zwischen Entwicklung und Dokumentation
- Einbeziehung von Dritten (z.B. Support, Kunden)
- Aber: Kontrolle bleibt bei Dokuteam!
- Beispiel: https://docs.microsoft.com/de-de/dotnet/
---
# GitHub
#### Situation
- Codeverwaltung über Subversion oder CVS
- Tägliche Arbeit stockt oft, da viele Aktionen eine Verbindung mit dem SVN-Server erfordern
- Erstellen und Mergen von Branches kompliziert, daher…
- Gemeinsame Entwicklung im Hauptbranch
- Branching nur bei Release *durch Experten*
---
# GitHub
#### Änderungen
- Umstellung auf Git
- Branchen und Mergen wird von allen beherrscht und täglich durchgeführt
- Jede Entwicklung findet ungestört im eigenen Branch statt
- Hauptbranch kann *immer* released werden
- Wichtigste Änderung:
Umzug auf [GitHub](https://github.com)
---
# GitHub
#### Ergebnis
- Keine gegenseitige Störung bei paralleler Entwicklung
- GitHub bietet [Pull Requests](https://help.github.com/articles/about-pull-requests/):
- Möglichkeit, über Änderungen am Code zu diskutieren
- Persistente, nachvollziehbare Kommunikation
- [Beispiel](https://github.com/thenativeweb/roboter/pull/48)
- GitHub macht es einfach, Projekte in Open Source umzuwandeln
---
# GitHub
#### Anti-Pattern
- Gitolite
- Günstige Alternative: [GitLab](https://about.gitlab.com)
---
class: black
# Gitolite
---
class: middle, center, tnw-intertitle
# Automation
---
# Automation
- Beschleunigt Prozesse
- Vermeidet Fehler
- Immer betrachten: Ist Gewinn größer als Aufwand?
- Auf Wartbarkeit achten
- Ständige Suche nach Möglichkeiten
???
Bild:
Einsparung
| ? ++++
| ? ++++
|---- ?
|---- ?
|------------
Häufigkeit
Stories:
- Build- und Test-Infrastruktur
---
# Build- & Testinfrastruktur
#### Situation
- Der Hauptteil der Tests wird vor Release manuell durchgeführt – *oft nur auf einer Plattform*
- Es werden keine neuen VMs verwendet, sondern "bereits eingerichtete"
- Erst *nach* den Tests werden die endgültigen Installationspakete für die Kunden gebaut
- Code wird während des Release-Vorgangs weiterhin geändert, aber *nicht neu getestet*
- Dauer eines Releases: Mehrere Monate
---
# Build- & Testinfrastruktur
#### Änderungen
.column[
- Automatisches Erzeugen der *endgültigen* Installationspakete
- QS arbeitet *nur* mit diesen Paketen
- Anteil der automatisierten Tests drastisch erhöht
- jMeter
- Cucumber
- Selbst geschriebene Tests
]
.column[
- Bei jedem Durchlauf werden neue Tests-VMs erzeugt
- Automatisierung mitels [Vagrant](https://www.vagrantup.com/) und [Terraform](https://www.terraform.io/)
- Alle unterstützten Plattformen werden getestet
- Sowohl Cloud als auch interne Systeme werden verwendet
]
---
# Build- & Testinfrastruktur
#### Ergebnis
- Automatischer Teil des Releasevorgangs innerhalb von Stunden vollständig durchlaufen
- Nutzung der Cloud macht automatisierten Testaufbau sehr einfach
- Sicherheit so hoch, dass bereits ins firmeneigene Produktivsystem deployed wird
- Viel Zeit für Entwicklung, aber auch viel Einsparung
---
# Build- & Testinfrastruktur
#### Anti-Pattern
- Testinfrastruktur muss nicht unbedingt selbst bereitgestellt werden
- Gerade für kurzlebige Testdurchläufe kann die Cloud günstig sein
- Cloud besonders für Tests geeignet, die die Ressourcen stark belasten
- Automatisierung mittels Terraform u.ä. sehr einfach
- Oft wird der Wartungsaufwand bei eigenen Lösungen unterschätzt
---
class: middle, center, tnw-intertitle
# Lean
---
# Lean
- Schlanke Prozesse
- Globale Sicht: Auch Übergabe zwischen Teams betrachten
- Auch mit Hilfe von Automatisierung
- Wirkt sich auf den Aufbau der Software aus
???
Globale Sicht:
- Story von der Reduzierung der Lead-Time um 50% in Dev und Ops:
Ergebnis: Nur 10% gesamt
Stories:
- 12-Faktor-App
- API-Schnittstellen
---
# The Twelve-Factor App
[Best practices](https://12factor.net) für die Entwicklung von Software as a Service (SaaS)
- Nicht nur geeignet für das Deployment in die Cloud
- Möglichst reibungsloser Übergang zwischen Entwicklung und Betrieb (Continuous Deployment)
- Einfache Skalierung im laufenden Betrieb
???
Bild:
(FaaS: Serverless Computing)
SaaS: Software-aaS (Programmfenster)
PaaS: Platform-aaS (Windows-Logo)
IaaS: Infrastructure-aaS (Computer)
---
# The Twelve-Factor App
#### Die 12 Faktoren
.column[
##### 1. Codebase
Eine im Versionsmanagementsystem verwaltete Codebase, viele Deployments
##### 2. Abhängigkeiten
Abhängigkeiten explizit deklarieren und isolieren
]
.column[
##### 3. Konfiguration
Die Konfiguration in Umgebungsvariablen ablegen
##### 4. Unterstützende Dienste
Unterstützende Dienste als angehängte Ressourcen behandeln
]
---
# The Twelve-Factor App
#### Die 12 Faktoren
.column[
##### 5. Build, release, run
Build- und Run-Phase strikt trennen
##### 6. Prozesse
Die App als einen oder mehrere Prozesse ausführen
]
.column[
##### 7. Bindung an Ports
Dienste durch das Binden von Ports exportieren
##### 8. Nebenläufigkeit
Mit dem Prozess-Modell skalieren
]
---
# The Twelve-Factor App
#### Die 12 Faktoren
.column[
##### 9. Einweggebrauch
Robuster mit schnellem Start und problemlosen Stopp
##### 10. Dev-Prod-Vergleichbarkeit
Entwicklung, Staging und Produktion so ähnlich wie möglich halten
]
.column[
##### 11. Logs
Logs als Strom von Ereignissen behandeln
##### 12. Admin-Prozesse
Admin/Management-Aufgaben als einmalige Vorgänge behandeln
]
---
# The Twelve-Factor App
#### … und CALM(S)
.column[
#### Culture
1. Codebase
5. Build, release, run
6. Prozesse
#### Automation
2. Abhängigkeiten
3. Konfiguration
4. Unterstützende Dienste
9. Einweggebrauch
12. Admin-Prozesse
]
.column[
#### Lean
8. Nebenläufigkeit
#### Measurement
7. Bindung an Ports
10. Dev-Prod-Vergleichbarkeit
11. Logs
]
---
# API-Schnittstellen
#### Situation
- Ein System besteht aus Prozessen, die von verschiedenen Teams entwickelt werden
- Keine einheitliche Schnittstelle zwischen den Komponenten
- Historisch gewachsen: Von selbst erfundenen Protokollen bis zu SOAP
- Keine konsistente Dokumentation dieser Schnittstellen
- Nur die *Experten* können Änderungen vornehmen
---
# API-Schnittstellen
#### Änderungen
- Einführung von REST, wo möglich
- Schulung der Mitarbeiter, so dass *jeder* mit REST vertraut ist
- Definition der Schnittstellen via [OpenAPI](https://www.openapis.org)
- Dafür wird [Swagger](https://swagger.io/swagger-editor/) eingesetzt
- Änderungen werden durch die Codeverwaltung versioniert
---
# API-Schnittstellen
#### Ergebnis
- HTTPS anstelle von unsicheren, selbst entwickelten Formaten
- Verbreiterung der Wissensbasis: Jeder kann die Spezifikation verstehen
- Spezifikation dient auch Kunden als Quelle für eigene Anbindungen
- Automatische Code-Generierung möglich
---
# API-Schnittstellen
#### Anti-Pattern
- Nicht in jedem Fall ist REST geeignet
- z.B. zu hohe Last durch Polling der Clients
- Aber: Immer prüfen, ob die Voraussetzungen geschaffen werden können
---
class: middle, center, tnw-intertitle
# Measurement
---
# Measurement
- Nur, was man messen kann, kann man optimieren
- Basis für Entscheidung, ob Erfolg
- Betrifft Prozesse, aber auch das Produkt selbst
- Möglichst schnelles Feedback
- Benötigte Metriken können sich mit der Zeit ändern
---
# Logging & Monitoring
#### Situation
- Monitoring des Produkt ist wichtig
- Erfolg von Änderungen
- Kritische Situationen erkennen
- Logdaten können wertvolle Hinweise liefern
- Aber: Meist nur für Post-Mortem Analysen verwendet
- Dateizugriff ist oft nur schlecht möglich
- Bei verteilten Systemen weit verstreut
---
# Logging & Monitoring
#### Änderungen
- Sammeln aller Logdaten an einer zentralen Stelle
- [ELK-Stack](https://www.elastic.co/de/) (Elasticsearch, Logstash, Kibana)
- Auch als SaaS verfügbar
---
# Logging & Monitoring
#### Kibana - Log View
[](./kibana-logs.png)
---
# Logging & Monitoring
#### Kibana - Dashboard
[](./kibana-dashboard.png)
---
# Logging & Monitoring
#### Ergebnis
- Besseres Monitoring ohne Änderung des Programms!
- Auswertung in Echtzeit
- Frühere Reaktion auf Fehlersituationen möglich
- Neue Auswertungen einfach durch Scheiben zusätzlicher Daten ins Log
---
# Logging & Monitoring
#### Anti-Pattern
- Ausfall des zentralen Loggings darf nicht das System zum Stillstand bringen
---
# Funktionale Tests
#### Situation
- Black-Box-Tests
- Häufig manuell
- Wenn automatisiert, schwer zu verstehen da sehr implizit und technisch
---
# Funktionale Tests
#### Änderungen
- [Cucumber](https://cucumber.io)
- Gemeinsame Festlegung von Tests (PO, QS, Dev, Ops)
- Docker für den schnellen Aufbau der Anwendung
- Tests können sich nicht beeinflussen
- Notwendige Anpassungen an Konfiguration wird explizit
---
# Funktionale Tests
#### Beispiel für einen Cucumber-Test
[](./cucumber.jpg)
???
Aufbau von Cucumber erklären:
- Oberer Layer: Natürlicher Text
- Mittlerer Layer: Mappen von Textanweisungen auf Programmfunktionen
- Unterer Layer: Code zur Interaktion mit der Anwendung
---
# Funktionale Tests
#### Ergebnis
- Nicht nur für Experten, sogar für Kunden geeignet
- Dient als Diskussionsgrundlage für neue Features
- Änderungen im System wirken sich nicht auf Beschreibung der Testfälle aus
- Trennung der Verantwortlichkeiten
- QS für Beschreibung der Testfälle
- Dev für Testcode
---
# Funktionale Tests
#### Anti-Pattern
- Eine (Programmier-)Sprache für alle
- Auf richtige Abstraktion der Beschreibungen achten
- Zu technische Beschreibungen vermeiden
Der Kunde muss es verstehen können
---
class:split-50
# Erfolg messen
#### Nur was messbar ist, kann man optimieren
.column[
- Produkt
Wächst die Kundenzufriedenheit?
- Interaktionen
Gibt es mehr Austausch zwischen Mitarbeitern und Teams?
]
.column[
- Prozesse
Wird der Prozess beschleunigt?
Wird er stabiler?
- Werkzeuge
Welche Probleme löst das Werkzeug?
Welche neuen Probleme kommen dazu?
]
???
Produkt:
- Direktes Feedback: Kundenumfragen
- Statistik über die gemeldeten Fehler
Interaktionen:
- Chat – private vs. öffentliche Nachrichten
- Neue Interessengruppen
Tools:
- Vor Einsatz eines Tools Ziel festlegen; Erreichen des Ziels prüfen
- Probleme erkennen: Z.B. Supportaufwand analysieren
Prozesse:
- z.B. Zeit der automatischen Tests
- z.B. Auswirkungen auf Fehlerhäufigkeit
---
# Erfolg messen
- Oft unterschiedliche Definitionen von Erfolg
- Notwendig:
- Gemeinsames Ziel
- Transparenz
---
# Blameless Post-Mortem
#### Umgang mit Misserfolg
- Fehler können nicht ausgeschlossen werden
- Basis für das Lernen aus Fehlern
- Stattdessen häufig:
- Suche nach einem Schuldigen
- Überhaupt keine Analyse
- Gewonnene Erkenntnisse müssen verbreitet werden
---
class: middle, center, tnw-intertitle
# Sharing
---
class:split-50
# Sharing
.column[
Intern:
- [Chat](https://get.slack.help/hc/article_attachments/115015069663/WHAT_IS_SLACK_Slack_overview.png) Channels
- Lightning Talks
- Open Space
- Interessengruppen
]
.column[
Extern:
- Usergruppen / [Meetups](https://meetup.com)
- Konferenzen
]
---
class: middle, center, tnw-intertitle
# DevOps in traditionellen Firmen
---
# DevOps in traditionellen Firmen
- Keine Start-ups oder Internetfirmen
- Aber trotzdem Veränderungen:
- Vorteile durch Nutzung neuer Technologien bei Erstellung und Betrieb von Software
- Kunden fangen an, die Cloud zu nutzen
- Beschleunigung von Prozessen und Erhöhung der Produktqualität
- Zeit nötig für Änderung der Kultur, gerade bei gefestigten Strukturen
---
# Zusammenfassung
- DevOps ist eine Unternehmenskultur der Zusammenarbeit und der konstanten Optimierung
- DevOps ermöglicht schnelle Reaktionen auf Veränderungen
- Nicht von Zahlen beeindrucken lassen: DevOps ist auch sinnvoll, wenn nicht alle paar Minuten deployed wird
- Cloud ist Herausforderung aber auch *die* Gelegenheit für Einführung von DevOps
- Auch jenseits davon: Schnelle Prozesse und hohe Produktqualität sind immer wichtige Ziele