Kaps - Es muss nicht immer Kubernetes sein
0 gefällt mir7,145 aufrufe
Das Dokument behandelt den Einsatz von Microservices und modernen Technologien in der Softwareentwicklung innerhalb einer Behörde mit ca. 600 Mitarbeitern, die etwa 60 Fachanwendungen betreut. Es wird hervorgehoben, dass der Übergang von legacy Systemen zu Microservices eine bessere Modularität und Wartbarkeit ermöglicht, während praktische Schritte zur Implementierung von Containern und Automatisierung vorgestellt werden. Der Autor betont, dass das Erlernen neuer Technologien schrittweise erfolgen sollte und gibt Anregungen zur Nutzung von Open-Source-Tools zur Unterstützung des Entwicklungsprozesses.
Kaps - Es muss nicht immer Kubernetes sein
- 1. Es muss nicht immer Kubernetes sein
- 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
- 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
- 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
- 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
- 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
- 31. @kitenco1
- 32. @kitenco1
- 33. @kitenco1
- 34. @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
- 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
- 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
- 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
- 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