Das Dokument behandelt die Herausforderungen und Lösungen bei der Modernisierung von Monolithen zu Microservices, einschließlich der Probleme wie geringe Deployment-Frequenz und starre Architektur. Es beschreibt den Ansatz von Strangler-Apps und die Notwendigkeit eines Service Mesh, um Komplexität und Interaktionen zwischen Microservices zu verwalten. Neben Funktionen wie Service Discovery und Load Balancing wird die Bedeutung von Observability und Resilienz in modernen Anwendungsarchitekturen hervorgehoben.

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. 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. 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. 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. Big Ball of Mud.
Quelle: https://twitter.com/Werner/status/741673514567143424
(Werner Vogels, CTO Amazon)
Quelle: Adrian Cockcroft (Netflix) / Martin Fowler

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. 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. 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. 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. Istio Architektur.
Data Plane
Control Plane

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. 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. Zusätzlich…