In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.

1. Es muss nicht
immer Kubernetes
sein

2. Microservice-Architekturen
on-premise betreiben
@kitenco1

3. Stephan Kaps
Leiter Softwareentwicklung Bundesamt für Soziale Sicherung
Gründer Java User Group Bonn
Java Entwickler & Architekt seit 2002
Weitere Schwerpunkte:
- Softwareentwicklungsprozesse
- BizDevSecOps
- OpenSource
- Speaker & Autor
@kitenco1

4. Wer sind wir uns was machen wir?
(Aufsichts-) Behörde mit ca. 600 Mitarbeiter
ca. 60 Fachanwendungen (Produkte)
für interne Fachbereiche & Landesprüfdienste
10 Entwickler und 2 Product Owner
2 parallele Sprints
noch einige Legacy VB/.NET Apps
@kitenco1

5. @kitenco1

6. Was ist eigentlich Legacy
Monolithisch
Veraltete Technologien
Groß und komplex
Schwer zu warten
Innovationen schwierig
@kitenco1

7. JBoss Wildfly
Ausgangs-Situation
APP
APP APP
APP
- Konfig Hölle
- Technologie Zwang
- Abhängigkeiten
- Einfluss auf Verfügbarkeit
@kitenco1

8. “5 Spring Boot Hello-World Services in einem
Kubernetes deployed, das ich mit Minikube
hier auf meinem Laptop laufen habe”
@kitenco1

9. Brauchst du es
@kitenco1

10. Kennst du die Anzahl der
User, die deine Dienste
nutzen werden?
@kitenco1

11. Bist du überhaupt im
Internet mit deinen
Diensten?
@kitenco1

12. Wie sieht eure aktuelle
Infrastruktur aus?
@kitenco1

13. Wie viel Zeit und Motivation werden
vor allem die Betriebsmitarbeiter
haben, um viele neue Technologien
(auf einmal) zu lernen?
@kitenco1

14. OK, warte …
Noch mal einen
Schritt zurück
@kitenco1

15. Was wollen wir eigentlich?
@kitenco1

16. Microservices!
Lasst es! Aber...
@kitenco1

17. - Modularity
- Information Hiding
- Loosely coupled
- Highly maintainable and testable
- Independently deployable
- Enables the continuous delivery/deployment of large, complex applications
- Enables an organization to evolve its technology stack
- Organized around business capabilities
Why Microservices?
@kitenco1

18. APP
DMS-
System
Zahlungs-
System
Verteilte Architekturen existieren ohnehin schon
@kitenco1
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

19. Domain Driven Design
@kitenco1

20. DDD Subdomains
core subdomains: das Kerngeschäft
supporting subdomains: unterstützende Funktionalitäten, die zwar mit der Business Logik verknüpft sind, die
jedoch leicht ausgelagert werden könnten in separate Microservices, um die Domäne von nicht zum Kern
gehörenden Code zu befreien. Beispiele dafür sind Referenz- oder Stammdatenverwaltungen, Protokollierungs-
und Kommentarfunktionen
generic subdomains: bereits gelöste Probleme, die für diverse Systeme immer gleich umgesetzt werden,
gehören nicht zum Kerngeschäft und können im einfachsten Fall hinzugekauft werden oder es existieren
entsprechende Open-Source-Projekte.
@kitenco1

21. APP
DMS-
System
Zahlungs-
System
Plz-Service
DMS-Service
ZS-Service
Anticorruption Layer
TBS-Service
Report-Service
XY-Service
Generic / supporting Subdomains
@kitenco1

22. Container
@kitenco1

23. 1. Schritt: ein Node
@kitenco1

24. Docker Node
- Service A
- Service B
- Service C
- Service A = Port 30001
- Service B = Port 30002
- Service C = Port 30003
APP
@kitenco1

25. 2. Schritt: noch ein Node
@kitenco1

26. Docker Node Docker Node
Consul Service Discovery
APP
@kitenco1

27. @kitenco1

29. 3. Schritt: Übersicht
@kitenco1

30. DEV STAGE PROD
@kitenco1

31. @kitenco1

32. @kitenco1

33. @kitenco1

34. @kitenco1

35. 4. Schritt: Automatisierung
@kitenco1

36. @kitenco1

37. Requirements
● Version Control
● CI-Server
● Automated Tests
● Trunk-Based-Development
● Security Testing (SAST & DAST)
● Scripts for automating deployments
● Automate database changes
● Develop (scripted) Delivery Pipelines
● Unified Deployment
● Maybe organisational or cultural challenges
@kitenco1

38. Shared Responsibilities
Availability, Security and
Quality
&
@kitenco1

39. @kitenco1

41. 5. Schritt: Rund machen
@kitenco1

42. Alles in Container
Wildfly mit je einer Applikation
Infrastruktur
- Keycloak
- Jenkins
- ...
@kitenco1

43. Aktuelle Situation
Aufruf einer Anwendung mit
http://stage-docker-01.intern:12345/meine-app
Was stört hier? - kein https
- Servername muss bekannt sein
- Port muss bekannt sein
- URL muss auch so in Keycloak stehen
- bei Umzug muss alles angepasst werden
@kitenco1

44. Einheitliches Eingangstor
● Erzwingt https
● Versorgt die Aufrufe mit Zertifikaten
● Legt die erlaubten Routen fest
● Setzt automatisch alle Security Header an sämtliche Requests
● Macht ggf. Load-Balancing
● Kann den Consul Katalog auslesen
@kitenco1

45. https://portal.intern/meine-app

46. @kitenco1

47. Zusammenfassung
Neue Anwendung entwickeln:
- Projekt in Gitlab anlegen und Jenkinsfile erstellen
- Automatisches (einheitliches) Deployment
- Automatische Registrierung & Service-Discovery mit Consul
- Automatisches Routing & Load-Balancing in Traefik
- Automatische Observability
- Automatische Zertifikate, Policies und Micro-Segmentierung

48. Ausblick
@kitenco1

49. @kitenco1
Services erhalten Credentials aus Vault
Inter-Service-Kommunikation mit mTLS
Automatischer Austausch der
Zertifikate in kurzen Abständen
Einschränkung der Kommunikation
durch Policies
Layer-7-Observability & Traffic Mgmt.
Dynamisches Load-Balancing

50. Ausblick
leichtgewichtiger Orchestrator
- um Container zu verteilen
(dort wo Platz ist)
- der sich um das Port-Handling
kümmert
- Integration mit Consul & Vault
- (bedingtes) Skaling
@kitenco1

51. Neue Herausforderungen
Einführung einer Container Registry (Harbor inkl. Scans & Notary)
Regelmäßige Updates für Werkzeuge (Automatisierung)
Ressourcenverbrauch überwachen und ggf. optimieren
Container Security (CSVS und CIS-Benchmark)
@kitenco1

52. Key takeaways
@kitenco1

53. Aufbau einer “Private Cloud” aus einzelnen
(OpenSource) Komponenten ist möglich
@kitenco1

54. Evolving architecture verschafft Zeit
zum Lernen
@kitenco1

55. Je ein (OpenSource) Tool für jede
spezielle Aufgabe
@kitenco1

56. stay curious!
@kitenco1

57. Vielen Dank!
Kontakt:
Stephan Kaps
info@kitenco.de
www.kitenco.de
@kitenco1
https://www.xing.com/profile/Stephan_Kaps2
https://www.linkedin.com/in/stephan-kaps-b246b0ab/
http://de.slideshare.net/kitenco
Quelle aller Hintergrundgrafiken ist https://www.pixabay.com
https://open.spotify.com/album/2tHppzsY0ZPb57Xa7PRkEX