Jeder Service für sich kann unabhängig deployed und skaliert werden. Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it. Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.

1. you BUILD it
OPEN THANX
you RUN it
you IMRPOVE it Mehr Sicherheit
durch Automatisierung
Lars Kölpin-Freese | @LarsKoelpin
Software als SERVICE

2. Software als SERVICE
you RUN it
Plattform der Software
Service Level Agreements der Software
festlegen
Monitoren der Software
Ausliefern und Betreiben der Software
in verschiedenen Zuständen

3. Software als SERVICE
Betreiben der Software
Master Keyfact Subthema EINS, welches
ganz toll ist.
Master Keyfact Subthema ZWEI, welches
auch ganz toll ist.
... Mit Hilfe von
Automatisierung

4. Warum entwickeln wir Software?
• Problem lösen für einen Endnutzer
• Automatisierung realer Prozesse
• Arbeit des Menschen abnehmen
• Erreichbarkeit der Software
• Verlässlichkeit der Software
• Je schneller Funktionen umgesetzt werden, desto weniger Arbeit hat ein
Mensch

5. Operations
End-User
Application A
Team A
Application B
Team B
Application C
Team C

6. Probleme
• Time to market
• Dev-Prod parity
• Personelle Abängigkeiten
• Textuelle Beschreibungen als menschliche Schnittstelle
• Konfigurationen Intransparent
• Neuinterpretation: Definition of Done

8. Team A Team B Team C
Kubernetes Engine, Serverless, Cloud SQL …
Operations

9. Code
CI-System
Operating
System
Dev
Dev
Dev
push webhook push
Artifact
Storage
change
Operator

10. Imperative Programmierung ist ein
Programmierparadigma, nach dem „ein
Programm aus einer Folge
von Anweisungen besteht, die
vorgeben, in welcher Reihenfolge was
vom Computer getan werden soll“
Mutationen am System

11. <git>
Code
CI-System
Operating
System
Dev
Dev
Dev
push webhook push
Artifact
Storage
change
configuration
Operator
Mutationen am System

12. CI-OPS
Zugriff auf
geschützte
Resourcen
Was ist wo zur Zeit
installiert?
Soll es installiert sein?
Dinge werden von hand
gemacht in verschiedenen
Reihenfolgen
Konfiguration + Secrets
CI-Server
Operating
System

13. <git>
Code
CI-System
Operating
System
Dev
Dev
Dev
push webhook push
Artifact
Storage
install
config
Verboten

14. Im Gegensatz zur imperativen
Programmierung, bei der das Wie im
Vordergrund steht, fragt man in der
deklarativen Programmierung nach
dem Was …

15. Deklaratives System
• Keine aktiven Mutationen
• Kein KubeCTL
• Kein Helm
• Kein SSH
• Keine Rechte
• Konfigurationzustand als Grundlage
• Passive Mutationen durch drittes System
Hands-Off deployment

16. <git>
Code
CI-System
Operation
System
Dev
Dev
Dev
push webhook push
Artifact
Storage
configuration
Bin ich im richtigen Zustand?
Operator
install

17. <git>
Code
CI-System
Operation
System
Dev
Dev
Dev
push webhook push
Artifact
Storage
configuration
Bin ich im richtigen Zustand?
Operator
install
Git
Mutationen am
System

18. Idee: GitOps
• Eine Idee, kein Tool
• Systemabbildung durch Code
• Bereitstellen des SOLL-Zustands
• Configuration Management

19. Idee: GitOps (2)
• Git als Grundlage
• Configuration als Single Source of Truth
• Jede Änderung am Gesamtsystem versionieren
• Rechte und Cluster Access: None
• Git Workflows für Infrastruktur

20. Principles of GitOps
1. Das gesamte System wird deklarativ beschrieben
2. Der gewünschte Zustand des Systems ist versioniert im Git.
3. Grprüfte Änderungen werden automatisch am System angewandt.
4. Software agents Gleichen den Zustand des Systems ab und
benachrichtigen bei Problemen
https://www.weave.works/blog/practical-guide-gitops

21. Implementierung einer GitOps Architektur
• Das System liegt als Code vor
• Divergenzmechanismus
• Konvergenzmechanismus
• Automatisierter Operator
Es hat sich was verändert! Was ist
zu tun?
Wie merke ich, ob sich etwas
verändert hat?

22. Kubernetes
FluxCD
Applikation A
Applikation B
production
dev
Cluster-configuration
Sync
Java Helm
Java Helm
YAML
YAML YAML

23. CI-System Registry Cluster Configuration CD-System
Publish
Deploy Feature A
Detect Changes of Version 0.0.0-FeatureA
Set Version 0.0.1-FeatureA
Delete Branch
Delete Deployment

24. Umgang mit Secrets
…
FluxCD
Applikation A
production
Cluster-Configuration
KubeSeal
Public key
Sync
Secret
Postgres

25. Slack, Telegram
Was, wenn was falsch läuft?
FluxCD
Applikation A
production
Provider &
Events
Cluster-Configuration
notify
Slack
Telegram

26. Was, wenn was WIRKLICH falsch läuft?
git revert b0e1a7752acd39fbb67c6613e87df3

27. Aber …
DB Version Cluster App
Version
Datenbankzustand
1 V1 V1 PERSONS

28. DB Version Cluster App
Version
Datenbankzustand
1 V1 V1 PERSONS
2 V2 V2 <NO_TABLES>

29. DB Version Cluster App
Version
Datenbankzustand
1 V1 V1 PERSONS
2 V2 V2 <NO_TABLES>
REVERT REVERT REVERT

30. DB Version Cluster App
Version
Datenbankzustand
1 V1 V1 PERSONS
2 V2 V2 <NO_TABLES>
REVERT REVERT REVERT
4 V2 V1 <NO_TABLES>

31. DB Version Cluster App
Version
Datenbankzustand
1 V1 V1 PERSONS
2 V2 V2 <NO_TABLES>
REVERT REVERT REVERT
4 V2 V1 <NO_TABLES>
OOPS
Abwärtskompatibilität

32. Software als SERVICE
you RUN it
CI-Ops mutiert das Zielsystem und macht ein
Rollbacks des Gesamtsystems schwieriger
Deklarative Systeme beschreiben den
Soll Zustand
GitOps als neuer Ansatz Systeme zu
konfigurieren

33. Lars Kölpin-Freese, @LarsKoelpin
Kontakt:
lars.koelpin-freese@openknowledge.de
kontakt@openknowledge.de
Besten Dank! #WISSENTEILEN

34. © xxx – iStockphoto.com (Folie 1)
© yyy – iStockphoto.com (Folie 5)
Alle weiteren Bilder der Präsentation sind entweder von pexels.com,
pixabay.com oder von mir selbst erstellt.
Bildernachweis