O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Service Mesh

47 visualizações

Publicada em

Die Migration von monolithischen Anwendungen hin zu einer service-basierenden Applikationslandschaft bringt nicht nur Vorteile mit sich. Neben dem notwendigen Einsatz neuer System-Komponenten, wie zum Beispiel OpenID Connect oder Cloud-Technologien wie Openshift gibt es noch andere Herausforderungen, die gemeistert werden müssen. Durch die Zerlegung des Monolithen in Microservices und der dabei entstehenden Kommunikations-Beziehungen zwischen diesen Services bildet sich ein sog. Service Mesh. Je nach Anzahl der Services und Kommunikations-Pfade entsteht dabei sehr schnell ein komplexes Geflecht das beherrscht werden muss. Istio ist eines der Werkzeuge das für den Betrieb und das Verwalten des Service Mesh eine große Hilfe sein kann.

Publicada em: Software
  • Login to see the comments

  • Seja a primeira pessoa a gostar disto

Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Service Mesh

  1. 1. „Servicierung“ von Monolithen Der Weg zu neuen Technologien bis hin zum Service Mesh Michael Hofmann www.hofmann-itconsulting.de Im Auftrag der DONAT group GmbH www.donat-group.de
  2. 2. Die Monolithen. > 10 Jahre EAR-File, Oracle Probleme: Geringe Deployment-Frequenz, lange Downtime Update Technologie Stack Starre Architektur Skalierung im Betrieb und in Entwicklung Single Point of Failure innerhalb des Monolithen (OutOfMemory)
  3. 3. Der Weg zur neuen Zielarchitektur. >> As Martin Fowler likes to say, the only thing a Big Bang rewrite guarantees is a Big Bang! << (Randy Shoup) Strangler Application Data Integration Glue (Chance Data Capture) Eventual Consistency
  4. 4. Microservices. Microservice-Projekte starten klein - Greenfield, Zerlegung Monolith Anfangs ohne Versionierungs-Problematik Mehrere Versionen parallel in Produktion Anzahl der Services steigt Service-Ketten werden etabliert Wie teste ich das Zusammenspiel versionsübergreifend? Schleichender Verlust des Überblicks: Wer mit wem in welcher Version?
  5. 5. Big Ball of Mud. Quelle: https://twitter.com/Werner/status/741673514567143424 (Werner Vogels, CTO Amazon) Quelle: Adrian Cockcroft (Netflix) / Martin Fowler
  6. 6. Was kommt noch? Komplexität auch zwischen den Services Fallacies of Distributed Systems Wer kümmert sich darum? Container-Systeme? Resilienz-Frameworks? The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn‘t change. There is one administrator. Transport cost is zero. The network is homogeneous. Anwendung sollte nichts davon wissen!
  7. 7. Service Mesh. >> The term service mesh is used to describe the network of microservices that make up such application and the interactions between them. << (istio.io) Ohne Werkzeug lässt sich Service Mesh (Big Ball of Mud) kaum beherrschen!
  8. 8. Service Mesh Functions. Service Discovery Load Balancing Resilience Dynamic Routing (Blue/Green Deployments, Canary Releasing, Traffic Mirroring) Observability (Metrics, Tracing) End-to-End Authentication, Access Control Rate Limiting
  9. 9. Istio. GOOGLE (ISTIO)  Content-based routing  Rate limiting  ACLs  Telemetry  Kubernetes integration LYFT (ENVOY)  Proxy (sidecar) IBM (AMALGAM8)  Content-based routing (extended)  Service discovery  Resilience  Load balancing
  10. 10. Istio Architektur. Data Plane Control Plane
  11. 11. Envoy Proxy. Design Goal: >> The network should be transparent to applications. When network and application problems do occur it should be easy to determine the source of the problem. << Als Container gemeinsam mit Service deployed „Man-in-the-Middle“ Als Sidecar transparent für Service Service-Discovery, Load Balancing, Resilience, Health-Checks, Metrics, Fault Injection Kommunikation mit Mixer (Telemetrie) und Pilot (Policies)
  12. 12. Istio Rules. TRAFFIC MANAGEMENT  Starre/dynamische (HTTP-Header)  95%-5% Verteilung (Canary)  Traffic Mirroring RESILIENZ  Timeout, Retry, CircuitBreaker, Bulkhead  Testen der Resilienz mit Fault Injection: x% mit Delay, y% mit HTTP-Status Code (5xx)
  13. 13. Zusätzlich…

×