SlideShare ist ein Scribd-Unternehmen logo
Service Mesh
Kilometer 30
im
Microservice Marathon
Michael Hofmann
Hofmann IT-Consulting
info@hofmann-itconsulting.de
beim Marathon: ab km 30 ...
●
Fettverbrennung, drastische Ermüdung
●
Oft Entscheidung über Marathon-Finish
●
Richtiges Training
●
Spaghetti Party, Essen und Trinken während Lauf
●
Mentale Vorbereitung
Was tun dagegen?
„Der Mann mit dem Hammer“
km 30 bei Microservices?
●
Microservice Projekte starten klein (Greenfield, Zerlegung Monolith)
●
Anfangs ohne Versionierungs-Probleme
●
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 wen in welcher
Version?
Schon angekommen?
Quelle: https://twitter.com/Werner/status/741673514567143424
(Werner Vogels, CTO Amazon)
Quelle: Adrian Cockcroft (Netflix) / Martin Fowler
Was kommt noch bei km 30?
●
Komplexität auch zwischen den Services
●
Fallacies of Distritubed Systems
●
Wer kümmert sich darum?
– Container-Systeme?
– Resilienz-Frameworks?
Anwendung sollte nichts davon wissen!
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.
Wohin mit der Resilience?
●
Frameworks (Hystrix, Failsafe, MicroProfile Fault Tolerance)
●
Probleme:
– richtiges Pattern wird erst in Produktion erkannt (neues Deployment!)
– Abhängigkeit Bibliothek zur Programmiersprache
– Versionsmix der Bibliotheken über alle Services hinweg
– Abhängigkeiten zu anderen Frameworks (Service-Call → LoadBalancing → Service
Registry)
– Service Registry für andere Services verwendbar? Doppelte Service Registry? (hohe
Kopplung der Services an Infrastruktur-Komponenen!)
– Lernkurve bzgl. vieler Frameworks bei jedem Entwickler-Team
●
Alternative: Service Mesh Tool
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!
Anforderungen an Werkzeug:
●
Verwaltung der Aufrufe auf Layer 7 (Application Layer)
●
Resilienz, Routing-, Security- und Telemetrie-Funktionalitäten
●
Dezentral u. transparent für Services (implementation-independant)
Service Mesh Functions
●
Service Discovery
●
Load Balancing
●
Resilience
●
Dynamic Routing (Blue/Green Deployments, Canary Releasing, Traffic
Shadowing)
●
Observability (Metrics, Tracing)
●
End-to-End Authentication, Access Control
●
Rate Limiting
Service Mesh Tool ab wann?
●
Hohe Anzahl verschiedener Services
●
Aufruf-Tiefe der Services > 1
●
Einheitliche Umsetzung der Resilienz gewünscht
●
Contemporary testing strategies: Test in Produktionsumgebung
(notwendig?)
Service Mesh womit?
Vergleich Istio und Linkerd: https://abhishek-tiwari.com/a-sidecar-for-your-service-mesh/
Istio
IBM (Amalgam8)
content-based routing
(extended)
service discovery
resilience
load balancing
Google (Istio)
content-based routing
rate limiting
ACLs
telemetry
Kubernetes integration
Lyft (Envoy)
proxy (sidecar)
Istio Architektur
Quelle: istio.io
Data Plane
Control Plane
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)
Mixer
Quelle: istio.io
Pilot
Quelle: istio.io
Citadel
Quelle: istio.io
Automatic Sidecar Injection
Herzstück von Istio:
Sidecar (Envoy Proxy) automatisch bereitzustellen
●
IPTables Modifikation im Pod
●
Health-Checks durch Sidecar zum Service
●
Restart Pod wenn einer der beiden Container abstürzt
kubectl label
namespace my-namespace
istio-injection=enabled
helm install
install/kubernetes/helm/istio
--name istio --namespace
istio-system
Traffic Management
Quelle: istio.io
Traffic Management
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 95
- destination:
host: reviews
subset: v2
weight: 5
●
95%: reviews v1
●
5%: reviews v2
kubectl apply
-f reviews-v1-95-v2-5.yaml
Traffic Management
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
x-canary:
exact: „v2“
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
Mit HTTP Header:
●
x-canary=v2:
– reviews v2
●
Ohne Header:
– v1
●
Reihenfolge wichtig:
-match vor -route
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
trafficPolicy:
connectionPool:
http:
http1MaxPendingRequests: 2
tcp:
maxConnections: 5
outlierDetection:
http:
baseEjectionTime: 15m
consecutiveErrors: 3
interval: 1m
Circuit Breaker
●
max. 5 Connections auf
reviews v1 und max. 2
pending requests
●
Alles darüber: HTTP Status
Code 503
●
Bei 3 aufeinanderfolgenden
Fehlern (5xx) innerhalb 1
min.: upstream-host wird für
15 min. aus Pool entfernt
Retry - Timeout
●
Max. 3 Versuche mit jeweils
2s Timeout pro Versuch
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
Fault Injection apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- fault:
delay:
fixedDelay: 7s
percent: 90
abort:
httpStatus: 500
percent: 10
route:
- destination:
host: reviews
subset: v1
- route:
- destination:
host: reviews
subset: v1
●
90%: 7s delay
●
10%: HTTP Status Code 500
Traffic Shadowing
●
Zweck: paralleler Test der
neuen Version v2
●
100% der Requests auf
reviews v1 wird auf reviews
v2 gespiegelt
●
Antwort von reviews v2 wird
von Istio verworfen (aber im
Service ausgeführt!)
...
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
...
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 100
mirror:
host: reviews
subset: v2
Monitoring
Quelle: istio.io
Tracing
Quelle: istio.io
Service Graph
Quelle: istio.io
Kleiner „Big Ball of Mud“
Recommendations
●
Marathon-Training: frühzeitig im Projekt mit Werkzeug für
Service Mesh starten
●
Integration in CI/CD (Zero-Downtime Deployments!)
●
Resilienz besser im Sidecar als in Anwendung
●
Integration Tracing/Monitoring in vorhandene
Infrastruktur
●
Neue Testansätze etablieren

Weitere ähnliche Inhalte

Was ist angesagt?

Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)
Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)
Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)
akira6592
 
Vue入門
Vue入門Vue入門
Vue入門
Takeo Noda
 
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
NGINX, Inc.
 
自宅サーバラックの勧め ~In osc nagoya~
自宅サーバラックの勧め ~In osc nagoya~自宅サーバラックの勧め ~In osc nagoya~
自宅サーバラックの勧め ~In osc nagoya~
h-otter
 
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...
Insight Technology, Inc.
 
APIとは
APIとはAPIとは
APIとは
moonfactory Inc.
 
Ansible2.9 ネットワーク対応のアップデート #ansiblejp
Ansible2.9 ネットワーク対応のアップデート #ansiblejpAnsible2.9 ネットワーク対応のアップデート #ansiblejp
Ansible2.9 ネットワーク対応のアップデート #ansiblejp
akira6592
 
2011年度 新3年生向け
2011年度 新3年生向け2011年度 新3年生向け
2011年度 新3年生向け
Yuki Takahashi
 
WebSocketのキホン
WebSocketのキホンWebSocketのキホン
WebSocketのキホン
You_Kinjoh
 
Ansible でお世話になっている機能と拡張
Ansible でお世話になっている機能と拡張Ansible でお世話になっている機能と拡張
Ansible でお世話になっている機能と拡張
akira6592
 
知っておいて損はない AWS法務関連
知っておいて損はない AWS法務関連知っておいて損はない AWS法務関連
知っておいて損はない AWS法務関連
Kieko Sakurai
 
IoT用途で簡単に使えるWebRTC Engineを作った話
IoT用途で簡単に使えるWebRTC Engineを作った話IoT用途で簡単に使えるWebRTC Engineを作った話
IoT用途で簡単に使えるWebRTC Engineを作った話
ToshiyaNakakura1
 
本当は楽しいインターネット
本当は楽しいインターネット本当は楽しいインターネット
本当は楽しいインターネット
Yuya Rin
 
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
Masahito Zembutsu
 
フリーでできるセキュリティ インフラ(Nessus)編
フリーでできるセキュリティ インフラ(Nessus)編フリーでできるセキュリティ インフラ(Nessus)編
フリーでできるセキュリティ インフラ(Nessus)編
abend_cve_9999_0001
 
ストリーミングのげんざい
ストリーミングのげんざいストリーミングのげんざい
ストリーミングのげんざい
Tetsuya Morimoto
 
VyOSの開発とか運用の話
VyOSの開発とか運用の話VyOSの開発とか運用の話
VyOSの開発とか運用の話
Shintaro Hasunuma
 
なんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来いなんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来い
Ryo Ito
 
ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy
ネットワークの自動化・監視の取り組みについて #netopscoding #npstudyネットワークの自動化・監視の取り組みについて #netopscoding #npstudy
ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy
Yahoo!デベロッパーネットワーク
 

Was ist angesagt? (20)

Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)
Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)
Ansible とネットワーク自動化の概要(SmartCS と Ansible の連携による自動化の可能性を体験!)
 
Vue入門
Vue入門Vue入門
Vue入門
 
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
 
自宅サーバラックの勧め ~In osc nagoya~
自宅サーバラックの勧め ~In osc nagoya~自宅サーバラックの勧め ~In osc nagoya~
自宅サーバラックの勧め ~In osc nagoya~
 
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...
 
APIとは
APIとはAPIとは
APIとは
 
Ansible2.9 ネットワーク対応のアップデート #ansiblejp
Ansible2.9 ネットワーク対応のアップデート #ansiblejpAnsible2.9 ネットワーク対応のアップデート #ansiblejp
Ansible2.9 ネットワーク対応のアップデート #ansiblejp
 
2011年度 新3年生向け
2011年度 新3年生向け2011年度 新3年生向け
2011年度 新3年生向け
 
WebSocketのキホン
WebSocketのキホンWebSocketのキホン
WebSocketのキホン
 
Nginx lua
Nginx luaNginx lua
Nginx lua
 
Ansible でお世話になっている機能と拡張
Ansible でお世話になっている機能と拡張Ansible でお世話になっている機能と拡張
Ansible でお世話になっている機能と拡張
 
知っておいて損はない AWS法務関連
知っておいて損はない AWS法務関連知っておいて損はない AWS法務関連
知っておいて損はない AWS法務関連
 
IoT用途で簡単に使えるWebRTC Engineを作った話
IoT用途で簡単に使えるWebRTC Engineを作った話IoT用途で簡単に使えるWebRTC Engineを作った話
IoT用途で簡単に使えるWebRTC Engineを作った話
 
本当は楽しいインターネット
本当は楽しいインターネット本当は楽しいインターネット
本当は楽しいインターネット
 
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
 
フリーでできるセキュリティ インフラ(Nessus)編
フリーでできるセキュリティ インフラ(Nessus)編フリーでできるセキュリティ インフラ(Nessus)編
フリーでできるセキュリティ インフラ(Nessus)編
 
ストリーミングのげんざい
ストリーミングのげんざいストリーミングのげんざい
ストリーミングのげんざい
 
VyOSの開発とか運用の話
VyOSの開発とか運用の話VyOSの開発とか運用の話
VyOSの開発とか運用の話
 
なんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来いなんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来い
 
ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy
ネットワークの自動化・監視の取り組みについて #netopscoding #npstudyネットワークの自動化・監視の取り組みについて #netopscoding #npstudy
ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy
 

Ähnlich wie Service Mesh - Kilometer 30 im Microservices-Marathon

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Ramon Anger
 
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaCloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
QAware GmbH
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
Ramon Anger
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
QAware GmbH
 
Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...
Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...
Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...
Michael Hofmann
 
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
engelschall
 
micro services
micro servicesmicro services
micro services
smancke
 
Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?
Christian Baranowski
 
OSMC 2012 | Performance graphing mit inGraph by Eric Lippmann
OSMC 2012 | Performance graphing mit inGraph by Eric LippmannOSMC 2012 | Performance graphing mit inGraph by Eric Lippmann
OSMC 2012 | Performance graphing mit inGraph by Eric Lippmann
NETWAYS
 
On the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a ServiceOn the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a Service
Stefan Kolb
 
JavaFX Real-World Apps
JavaFX Real-World AppsJavaFX Real-World Apps
JavaFX Real-World Apps
Alexander Casall
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
QAware GmbH
 
SignalR
SignalRSignalR
Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?
Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?
Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?
Michael Hofmann
 
Camunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM OffensiveCamunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM Offensive
camunda services GmbH
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
OPEN KNOWLEDGE GmbH
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudFrom Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
OPEN KNOWLEDGE GmbH
 
Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?
QAware GmbH
 

Ähnlich wie Service Mesh - Kilometer 30 im Microservices-Marathon (20)

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
 
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaCloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...
Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...
Servicierung von Monolithen - Der Weg zu neuen Technologien bis hin zum Servi...
 
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
 
Vortrag linux tag
Vortrag linux tagVortrag linux tag
Vortrag linux tag
 
micro services
micro servicesmicro services
micro services
 
Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?
 
OSMC 2012 | Performance graphing mit inGraph by Eric Lippmann
OSMC 2012 | Performance graphing mit inGraph by Eric LippmannOSMC 2012 | Performance graphing mit inGraph by Eric Lippmann
OSMC 2012 | Performance graphing mit inGraph by Eric Lippmann
 
On the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a ServiceOn the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a Service
 
JavaFX Real-World Apps
JavaFX Real-World AppsJavaFX Real-World Apps
JavaFX Real-World Apps
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
SignalR
SignalRSignalR
SignalR
 
Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?
Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?
Service Mesh mit Istio und MicroProfile - eine harmonische Kombination?
 
Camunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM OffensiveCamunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM Offensive
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudFrom Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
 
Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?
 

Mehr von Michael Hofmann

Service Specific AuthZ In The Cloud Infrastructure
Service Specific AuthZ In The Cloud InfrastructureService Specific AuthZ In The Cloud Infrastructure
Service Specific AuthZ In The Cloud Infrastructure
Michael Hofmann
 
New Ways To Production - Stress-Free Evolution Of Your Cloud Applications
New Ways To Production - Stress-Free Evolution Of Your Cloud ApplicationsNew Ways To Production - Stress-Free Evolution Of Your Cloud Applications
New Ways To Production - Stress-Free Evolution Of Your Cloud Applications
Michael Hofmann
 
Developer Experience Cloud Native - Become Efficient and Achieve Parity
Developer Experience Cloud Native - Become Efficient and Achieve ParityDeveloper Experience Cloud Native - Become Efficient and Achieve Parity
Developer Experience Cloud Native - Become Efficient and Achieve Parity
Michael Hofmann
 
The Easy Way to Secure Microservices
The Easy Way to Secure MicroservicesThe Easy Way to Secure Microservices
The Easy Way to Secure Microservices
Michael Hofmann
 
Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?
Michael Hofmann
 
Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?
Michael Hofmann
 
Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...
Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...
Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...
Michael Hofmann
 
Service Mesh - kilometer 30 in a microservice marathon
Service Mesh - kilometer 30 in a microservice marathonService Mesh - kilometer 30 in a microservice marathon
Service Mesh - kilometer 30 in a microservice marathon
Michael Hofmann
 
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderenAPI-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
Michael Hofmann
 
Microprofile.io - Cloud Native mit Java EE
Microprofile.io - Cloud Native mit Java EEMicroprofile.io - Cloud Native mit Java EE
Microprofile.io - Cloud Native mit Java EE
Michael Hofmann
 
Microservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM LibertyMicroservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM Liberty
Michael Hofmann
 

Mehr von Michael Hofmann (11)

Service Specific AuthZ In The Cloud Infrastructure
Service Specific AuthZ In The Cloud InfrastructureService Specific AuthZ In The Cloud Infrastructure
Service Specific AuthZ In The Cloud Infrastructure
 
New Ways To Production - Stress-Free Evolution Of Your Cloud Applications
New Ways To Production - Stress-Free Evolution Of Your Cloud ApplicationsNew Ways To Production - Stress-Free Evolution Of Your Cloud Applications
New Ways To Production - Stress-Free Evolution Of Your Cloud Applications
 
Developer Experience Cloud Native - Become Efficient and Achieve Parity
Developer Experience Cloud Native - Become Efficient and Achieve ParityDeveloper Experience Cloud Native - Become Efficient and Achieve Parity
Developer Experience Cloud Native - Become Efficient and Achieve Parity
 
The Easy Way to Secure Microservices
The Easy Way to Secure MicroservicesThe Easy Way to Secure Microservices
The Easy Way to Secure Microservices
 
Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?
 
Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?Service Mesh vs. Frameworks: Where to put the resilience?
Service Mesh vs. Frameworks: Where to put the resilience?
 
Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...
Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...
Developer Experience Cloud Native - From Code Gen to Git Commit without a CI/...
 
Service Mesh - kilometer 30 in a microservice marathon
Service Mesh - kilometer 30 in a microservice marathonService Mesh - kilometer 30 in a microservice marathon
Service Mesh - kilometer 30 in a microservice marathon
 
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderenAPI-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
 
Microprofile.io - Cloud Native mit Java EE
Microprofile.io - Cloud Native mit Java EEMicroprofile.io - Cloud Native mit Java EE
Microprofile.io - Cloud Native mit Java EE
 
Microservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM LibertyMicroservices mit Java EE - am Beispiel von IBM Liberty
Microservices mit Java EE - am Beispiel von IBM Liberty
 

Kürzlich hochgeladen

dachnug51 - Sametime 12 Deployment .pdf
dachnug51 - Sametime 12 Deployment  .pdfdachnug51 - Sametime 12 Deployment  .pdf
dachnug51 - Sametime 12 Deployment .pdf
DNUG e.V.
 
dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...
dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...
dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...
DNUG e.V.
 
dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...
dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...
dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...
DNUG e.V.
 
Headless WordPress beim WordPress Meetup Potsdam im Mai 2024
Headless WordPress beim WordPress Meetup Potsdam im Mai 2024Headless WordPress beim WordPress Meetup Potsdam im Mai 2024
Headless WordPress beim WordPress Meetup Potsdam im Mai 2024
VCAT Consulting GmbH
 
dachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdf
dachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdfdachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdf
dachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdf
DNUG e.V.
 
dachnug51 - HCL Volt MX Go Services in Domino Apps.pdf
dachnug51 - HCL Volt MX Go Services in Domino Apps.pdfdachnug51 - HCL Volt MX Go Services in Domino Apps.pdf
dachnug51 - HCL Volt MX Go Services in Domino Apps.pdf
DNUG e.V.
 

Kürzlich hochgeladen (6)

dachnug51 - Sametime 12 Deployment .pdf
dachnug51 - Sametime 12 Deployment  .pdfdachnug51 - Sametime 12 Deployment  .pdf
dachnug51 - Sametime 12 Deployment .pdf
 
dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...
dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...
dachnug51 - Keynote Airbus Defence and Space - Service Management and Collabo...
 
dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...
dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...
dachnug51 - Keynote A1 Austria AG - HCL Domino alias Business Notes verbindet...
 
Headless WordPress beim WordPress Meetup Potsdam im Mai 2024
Headless WordPress beim WordPress Meetup Potsdam im Mai 2024Headless WordPress beim WordPress Meetup Potsdam im Mai 2024
Headless WordPress beim WordPress Meetup Potsdam im Mai 2024
 
dachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdf
dachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdfdachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdf
dachnug51 - NIS2_DORA - Was steckt konkret dahinter.pdf
 
dachnug51 - HCL Volt MX Go Services in Domino Apps.pdf
dachnug51 - HCL Volt MX Go Services in Domino Apps.pdfdachnug51 - HCL Volt MX Go Services in Domino Apps.pdf
dachnug51 - HCL Volt MX Go Services in Domino Apps.pdf
 

Service Mesh - Kilometer 30 im Microservices-Marathon

  • 1. Service Mesh Kilometer 30 im Microservice Marathon Michael Hofmann Hofmann IT-Consulting info@hofmann-itconsulting.de
  • 2. beim Marathon: ab km 30 ... ● Fettverbrennung, drastische Ermüdung ● Oft Entscheidung über Marathon-Finish ● Richtiges Training ● Spaghetti Party, Essen und Trinken während Lauf ● Mentale Vorbereitung Was tun dagegen? „Der Mann mit dem Hammer“
  • 3. km 30 bei Microservices? ● Microservice Projekte starten klein (Greenfield, Zerlegung Monolith) ● Anfangs ohne Versionierungs-Probleme ● 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 wen in welcher Version?
  • 4. Schon angekommen? Quelle: https://twitter.com/Werner/status/741673514567143424 (Werner Vogels, CTO Amazon) Quelle: Adrian Cockcroft (Netflix) / Martin Fowler
  • 5. Was kommt noch bei km 30? ● Komplexität auch zwischen den Services ● Fallacies of Distritubed Systems ● Wer kümmert sich darum? – Container-Systeme? – Resilienz-Frameworks? Anwendung sollte nichts davon wissen! 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.
  • 6. Wohin mit der Resilience? ● Frameworks (Hystrix, Failsafe, MicroProfile Fault Tolerance) ● Probleme: – richtiges Pattern wird erst in Produktion erkannt (neues Deployment!) – Abhängigkeit Bibliothek zur Programmiersprache – Versionsmix der Bibliotheken über alle Services hinweg – Abhängigkeiten zu anderen Frameworks (Service-Call → LoadBalancing → Service Registry) – Service Registry für andere Services verwendbar? Doppelte Service Registry? (hohe Kopplung der Services an Infrastruktur-Komponenen!) – Lernkurve bzgl. vieler Frameworks bei jedem Entwickler-Team ● Alternative: Service Mesh Tool
  • 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! Anforderungen an Werkzeug: ● Verwaltung der Aufrufe auf Layer 7 (Application Layer) ● Resilienz, Routing-, Security- und Telemetrie-Funktionalitäten ● Dezentral u. transparent für Services (implementation-independant)
  • 8. Service Mesh Functions ● Service Discovery ● Load Balancing ● Resilience ● Dynamic Routing (Blue/Green Deployments, Canary Releasing, Traffic Shadowing) ● Observability (Metrics, Tracing) ● End-to-End Authentication, Access Control ● Rate Limiting
  • 9. Service Mesh Tool ab wann? ● Hohe Anzahl verschiedener Services ● Aufruf-Tiefe der Services > 1 ● Einheitliche Umsetzung der Resilienz gewünscht ● Contemporary testing strategies: Test in Produktionsumgebung (notwendig?)
  • 10. Service Mesh womit? Vergleich Istio und Linkerd: https://abhishek-tiwari.com/a-sidecar-for-your-service-mesh/
  • 11. Istio IBM (Amalgam8) content-based routing (extended) service discovery resilience load balancing Google (Istio) content-based routing rate limiting ACLs telemetry Kubernetes integration Lyft (Envoy) proxy (sidecar)
  • 13. 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)
  • 17. Automatic Sidecar Injection Herzstück von Istio: Sidecar (Envoy Proxy) automatisch bereitzustellen ● IPTables Modifikation im Pod ● Health-Checks durch Sidecar zum Service ● Restart Pod wenn einer der beiden Container abstürzt kubectl label namespace my-namespace istio-injection=enabled helm install install/kubernetes/helm/istio --name istio --namespace istio-system
  • 19. Traffic Management apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 95 - destination: host: reviews subset: v2 weight: 5 ● 95%: reviews v1 ● 5%: reviews v2 kubectl apply -f reviews-v1-95-v2-5.yaml
  • 20. Traffic Management apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: x-canary: exact: „v2“ route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1 Mit HTTP Header: ● x-canary=v2: – reviews v2 ● Ohne Header: – v1 ● Reihenfolge wichtig: -match vor -route
  • 21. apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: http: http1MaxPendingRequests: 2 tcp: maxConnections: 5 outlierDetection: http: baseEjectionTime: 15m consecutiveErrors: 3 interval: 1m Circuit Breaker ● max. 5 Connections auf reviews v1 und max. 2 pending requests ● Alles darüber: HTTP Status Code 503 ● Bei 3 aufeinanderfolgenden Fehlern (5xx) innerhalb 1 min.: upstream-host wird für 15 min. aus Pool entfernt
  • 22. Retry - Timeout ● Max. 3 Versuche mit jeweils 2s Timeout pro Versuch apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 retries: attempts: 3 perTryTimeout: 2s
  • 23. Fault Injection apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - fault: delay: fixedDelay: 7s percent: 90 abort: httpStatus: 500 percent: 10 route: - destination: host: reviews subset: v1 - route: - destination: host: reviews subset: v1 ● 90%: 7s delay ● 10%: HTTP Status Code 500
  • 24. Traffic Shadowing ● Zweck: paralleler Test der neuen Version v2 ● 100% der Requests auf reviews v1 wird auf reviews v2 gespiegelt ● Antwort von reviews v2 wird von Istio verworfen (aber im Service ausgeführt!) ... kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 ... kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 100 mirror: host: reviews subset: v2
  • 27. Service Graph Quelle: istio.io Kleiner „Big Ball of Mud“
  • 28. Recommendations ● Marathon-Training: frühzeitig im Projekt mit Werkzeug für Service Mesh starten ● Integration in CI/CD (Zero-Downtime Deployments!) ● Resilienz besser im Sidecar als in Anwendung ● Integration Tracing/Monitoring in vorhandene Infrastruktur ● Neue Testansätze etablieren