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.

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…