Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Service Mesh - Was die neue Infrastruktur für Microservices taugt 1 5 . 0 1 . 2 0 2 0 I N N O Q Te c h n o l o g y N i g h t 2 Jörg Müller Hanna Prinz

Slide 3

Slide 3 text

Warum Service Meshes? @JoergM @HannaPrinz

Slide 4

Slide 4 text

Monolith Microservices @JoergM @HannaPrinz

Slide 5

Slide 5 text

Microservices @JoergM @HannaPrinz

Slide 6

Slide 6 text

Timeout Circuit Breaking Verschlüsselung Retry Metriken erzeugen & bereitstellen Entschlüsselung Autorisierung prüfen Routing @JoergM @HannaPrinz

Slide 7

Slide 7 text

Service Mesh Metriken Konfiguration Retry Timeout Circuit Breaker Routing Verschlüsseln Entschlüsseln Autorisierung Metriken ... } @JoergM @HannaPrinz

Slide 8

Slide 8 text

Microservices mit Service Mesh Service Mesh Evolution Monolith Microservices Theorie Microservices Praxis @JoergM @HannaPrinz

Slide 9

Slide 9 text

Infrastruktur-Service Y Service Mesh Architektur Microservice 1 Microservice 2 Proxy Proxy Control Plane App Infrastruktur-Service X Anwendung Data Plane Control Plane Infrastruktur @JoergM @HannaPrinz

Slide 10

Slide 10 text

Was kann ein Service Mesh? @JoergM @HannaPrinz

Slide 11

Slide 11 text

Service Mesh Features Observability Resilience Routing Security Beispiele mit dem Istio Service Mesh @JoergM @HannaPrinz

Slide 12

Slide 12 text

Monitoring Ein Service Mesh kann automatisch Daten für alle 4 "Golden Signals" liefern: Latenz Requests/Sekunde Status Codes (Fehler) Auslastung ... es hat aber keinen Einblick in die Microservices https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals @JoergM @HannaPrinz

Slide 13

Slide 13 text

Monitoring mit Service Mesh Microservice 1 Microservice 2 Proxy Proxy Control Plane App Dashboard Monitoring-System Anwendung Data Plane Control Plane Infrastruktur 13

Slide 14

Slide 14 text

Monitoring mit Service Mesh Metriken zum Netzwerkverkehr generieren -> Latenz / Antwortzeit -> HTTP Status Codes -> Anfragen pro Sekunde Metriken an ein Monitoring- System senden Metriken mit Dashboards aufbereiten 14 @JoergM @HannaPrinz

Slide 15

Slide 15 text

Monitoring mit Istio @JoergM @HannaPrinz

Slide 16

Slide 16 text

Monitoring mit Istio basiert auf... Prometheus Grafana 16 Kiali Jaeger @JoergM @HannaPrinz

Slide 17

Slide 17 text

Monitoring mit Istio Microservice 1 Microservice 2 Envoy Proxy Envoy Proxy Anwendung Data Plane Control Plane Mixer Infrastruktur Grafana Prometheus 17 Kiali @JoergM @HannaPrinz

Slide 18

Slide 18 text

18 •Fachlich: •Online-Shop für Hipsterbedarf •Technologisch: •10 Microservices mit verschiedenen Technologien •Aufruf einer externen API für Währungsumrechnungen •Redis für Warenkorb •Kommunikation über gRPC Beispielanwendung: Hipstershop @JoergM @HannaPrinz

Slide 19

Slide 19 text

User Frontend Go AdService Java CheckoutService Go CurrencyService Node.js CartService C# EmailService Python RecommendationServ. Python ProductCatalogServ. Go PaymentService Node.js ShippingService Go Redis Cache Load Generator Python EZB API Hipstershop Services @JoergM @HannaPrinz

Slide 20

Slide 20 text

Demo @JoergM @HannaPrinz

Slide 21

Slide 21 text

@JoergM @HannaPrinz

Slide 22

Slide 22 text

Tracing •Beantwortet... •Welcher Aufruf erzeugt welchen Folgeaufruf? •Welchen Anteil hat jeder Teilaufruf an der Latenz? •Wo ist ein Fehler entstanden? •Umsetzung: Tracing- Backend B C A 3s Latenz #42 #42 #42 Trace von Aufruf #42 A B C 22 @JoergM @HannaPrinz

Slide 23

Slide 23 text

Tracing mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Tracing-Backend Anwendung Data Plane Control Plane Infrastruktur 23 @JoergM @HannaPrinz

Slide 24

Slide 24 text

Tracing mit Service Mesh Tracing-Header an ausgehende Anfragen kopieren Tracing-Daten an ein Tracing-Backend senden Tracing-Daten in Dashboard aufbereiten 24 @JoergM @HannaPrinz

Slide 25

Slide 25 text

Demo @JoergM @HannaPrinz

Slide 26

Slide 26 text

@JoergM @HannaPrinz

Slide 27

Slide 27 text

Service Mesh Features Observability Resilience Routing Security @JoergM @HannaPrinz

Slide 28

Slide 28 text

Routing Typischerweise im Edge Router / API- Gateway implementiert z.B. NGINX, Kong, Ambassador, Traefik Instance A Instance B Load Balancing Instance A Instance B Pfad-basiertes Routing /a /b Instance A Instance B Blue/Green Deployment Instance A Instance B A/B-Testing 50% 50% Instance A Instance B Canary Releasing Berlin Welt 28 @JoergM @HannaPrinz

Slide 29

Slide 29 text

Routing mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Control Plane App Anwendung Data Plane Control Plane Routing- Regeln 29 @JoergM @HannaPrinz

Slide 30

Slide 30 text

Routing mit Service Mesh GET /neu GET / 90% 10% Service 1 Service 2A Proxy Proxy Service 2B Proxy Komplexe Routing-Regeln für A/B Testing und Canary Releasing Service 1 Service 2 Proxy Proxy Service 2 Proxy PRODUKTION STAGING Traffic Mirroring locality=mars locality=* 30 @JoergM @HannaPrinz

Slide 31

Slide 31 text

Routing mit Istio @JoergM @HannaPrinz

Slide 32

Slide 32 text

Beispiel-Routing mit Istio GET /neu GET / Frontend v1 Ingress Proxy Proxy Frontend v2 Proxy 32 @JoergM @HannaPrinz

Slide 33

Slide 33 text

33 Routing Config apiVersion: networking.istio.io/… kind: DestinationRule metadata: name: frontend apiVersion: networking.istio.io/… kind: VirtualService metadata: name: frontend-ingress spec: hosts: - "*" Regel 1: Wenn die URI "/neu" enthält, dann leite an frontend v2 weiter Regel 2: Ansonsten leite an frontend v1 weiter http: - match: - uri: prefix: "/neu" route: - destination: host: frontend subset: v2 - route: - destination: host: frontend subset: v1 Subset “v2”: Alle Pods mit Label version: "2" Subset “v1”: Alle Pods mit Label version: "1" spec: host: frontend subsets: - name: v2 labels: version: "2" - name: v1 labels: version: "1" @JoergM @HannaPrinz

Slide 34

Slide 34 text

Demo @JoergM @HannaPrinz

Slide 35

Slide 35 text

@JoergM @HannaPrinz

Slide 36

Slide 36 text

Service Mesh Features Observability Resilience Routing Security @JoergM @HannaPrinz

Slide 37

Slide 37 text

Resilience Was wenn ein Service nicht wie erwartet zur Verfügung steht? Ziel: Gesamtsystem funktioniert weiter ... ggf. mit Einschränkungen Maßnahmen: Retry, Timeout, Circuit Breaking 37 500 @JoergM @HannaPrinz

Slide 38

Slide 38 text

Resilience mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Control Plane App Anwendung Data Plane Control Plane Resilienz- Regeln 38 @JoergM @HannaPrinz

Slide 39

Slide 39 text

Resilience mit Service Mesh Fault Injection Delay Injection Service 1 Service 2 Proxy Proxy Timeout Retry Service 1 Service 2 Proxy Proxy 4s 502 39 @JoergM @HannaPrinz

Slide 40

Slide 40 text

Resilience mit Istio Retry & Timeout @JoergM @HannaPrinz

Slide 41

Slide 41 text

Timeout & Retry hosts: Zieladresse des Client-Requests destination: Wo der Request tatsächlich hingeht max. Anzahl der Retrys Timeout pro Retry Bedingungen für ein Retry Timeout für alle Retrys zusammen apiVersion: networking.istio.io/... kind: VirtualService metadata: name: recommendationservice spec: hosts: - recommendationservice route: - destination: host: recommendationservice http: - retries: attempts: 3 perTryTimeout: 1s retryOn: connect-failure,5xx timeout: 2s @JoergM @HannaPrinz

Slide 42

Slide 42 text

Service Mesh Features Observability Resilience Routing Security @JoergM @HannaPrinz

Slide 43

Slide 43 text

Security mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Anwendung Data Plane Control Plane Control Plane App Autorisierungs- Regeln TLS-Zertifikat 43 @JoergM @HannaPrinz

Slide 44

Slide 44 text

Security mit Service Mesh Service 1 Service 2 Proxy Proxy "Service 1" Authentifizierung mit mTLS Autorisierung Service 1 Service 2 Proxy Proxy GET /api GET / Autorisierungs-Regel TLS-Zertifikat 44 @JoergM @HannaPrinz

Slide 45

Slide 45 text

Service Mesh Features Netzwerk-Metriken und -Logs Daten an Tracing-Backend senden Automatische Timeouts & Retrys Automatisches Circuit Breaking Business-Metriken oder -Logs Weitergabe von Tracing-Headern Cache oder Standardantworten in Circuit Breaker nutzen Routing anhand von Request Body Automatisierung Canary Releasing Authentifizierung mit mTLS Autorisierung Komplexe Routing-Regeln Canary Releasing & A/B-Testing Observability Resilience Routing Security @JoergM @HannaPrinz

Slide 46

Slide 46 text

One Mesh to rule them all? @JoergM @HannaPrinz

Slide 47

Slide 47 text

Service Mesh Implementierungen Istio @JoergM @HannaPrinz Vergleich auf

Slide 48

Slide 48 text

48

Slide 49

Slide 49 text

Was ist wichtig für die Auswahl eines Service Mesh? Features Kompatibilität Performance Usability

Slide 50

Slide 50 text

Istio VS Linkerd 2 *2017 von Google & IBM optimiert auf Featureanzahl und Konfigurierbarkeit optimiert für Kubernetes, aber nicht exklusiv *2017 von Buoyant optimiert auf Usability und Performance Kubernetes only @JoergM @HannaPrinz

Slide 51

Slide 51 text

51 Features Istio 1.4 Linkerd 2.6 Generell Plattform Verschiedene Kubernetes Automatische Sidecar-Injektion ✓ ✓ Sicherheit Authentifizierung via mTLS ✓ ✓ Autorisierung ✓ ✘ Resilienz Timeouts & Retrys ✓ ✓ Circuit Breaker ✓ ✘ Routing Load Balancing ✓ ✓ Routing-Regeln ✓ ✓ Monitoring Metriken ✓ ✓ Tracing ✓ (✓) Dashboard mit Service Graph ✓ ✓ @JoergM @HannaPrinz

Slide 52

Slide 52 text

52 @JoergM @HannaPrinz

Slide 53

Slide 53 text

53 Performance & Ressourcen •Latenz •Istio: zusätzlich ca. 8ms Latenz - pro Aufruf zwischen Services! •Linkerd 2: ähnlich, mit weniger starken Schwankungen •Ressourcen •Zusätzliche Container für Control Plane & jedes Sidecar •→ Erhöhter CPU- & Arbeitsspeicher-Verbrauch Aber: Abhängig von konkretem Setting → eigenen Benchmark machen! @JoergM @HannaPrinz

Slide 54

Slide 54 text

54 Usability @JoergM @HannaPrinz

Slide 55

Slide 55 text

Service Mesh Fazit Löst viele wesentliche Probleme von Microservices + Eine weitere komplexe Technologie – ... ohne Codeänderungen! Latenz- und Ressourcen- Overhead 55 @JoergM @HannaPrinz

Slide 56

Slide 56 text

56 Entscheidungshilfe Mesh oder kein Mesh? Istio oder Linkerd 2? •Service Mesh wenn: •Großteil in Kubernetes läuft •Viele Microservices, viele synchrone Aufrufe •Viele ungelöste Probleme beim Monitoring, Routing, Resilienz und/oder Security •Istio nur wenn Komplexität und Flexibilität nötig ist: •Teilsystem bleibt außerhalb von Kubernetes •Circuit Breaking und Autorisierung unverzichtbar •Ausreichend zeitliche und kognitive Kapazität im Team @JoergM @HannaPrinz

Slide 57

Slide 57 text

Mehr Mesh • Artikel Brauchen asynchrone Microservices und Self-Contained-Systems ein Service Mesh? • Artikel Alle 11 Minuten verliebt sich ein Microservice in Linkerd • Service Mesh Vergleich auf servicemesh.es • Podcast zu Service Meshes • Beispiel-Anwendung auf GitHub • Tutorial von Linkerd • Tutorial von Istio @JoergM @HannaPrinz

Slide 58

Slide 58 text

Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com Danke! Fragen? Jörg Müller [email protected] @JoergM Hanna Prinz [email protected] @HannaPrinz Icons made by srip, Smashicons, Nikita Golubev, Freepik, surang and Darius Dan from www.flaticon.com and licensed by CC 3.0 BY Kostenloser Service Mesh Primer Auf leanpub.com/service-mesh-primer