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.
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
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
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
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
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
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