O slideshow foi denunciado.

Service Mesh vs. Frameworks: Where to put the resilience?

0

Compartilhar

Carregando em…3
×
1 de 19
1 de 19

Service Mesh vs. Frameworks: Where to put the resilience?

0

Compartilhar

Baixar para ler offline

Descrição

Distributed systems should definitely no longer be developed and operated without resilience. The responsible developer or architect must first consider which resilience patterns are necessary. The next question is how the implementation of these patterns in the individual services should take place. One can distinguish between two basic alternatives. On the one hand an implementation with the classic resilience frameworks such as Resilience4J, Failsafe or MicroProfile Fault Tolerance. On the other hand, it is also possible to establish resilience with a service mesh tool like Istio.

In this session, after a brief introduction to Istio, the two basic alternatives are compared. The respective advantages and disadvantages are listed and compared in a final evaluation. Additional possibilities of Istio to explicitly test resilience will also be introduced.

Transcrição

  1. 1. Service Mesh vs. Frameworks: Where to put the resilience? Michael Hofmann https://hofmann-itconsulting.de
  2. 2. (1) Distributed Systems and Resilience (2) Framework (3) Service Mesh (4) Framework and Service Mesh Characteristics (5) Thoughts about Resilience (6) Essential Requirements (7) Conclusion Agenda
  3. 3. Distributed Systems ➔ degree of distribution raises failure rate! ➔ compensation strategy: resilience! slow response timeout aborted network connection ... Typical Communication Errors Fallacies of Distributed Computing 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.
  4. 4. Hystrix Alternative: Service Mesh?! Resilience Resilience4J Failsafe MicroProfile Fault Tolerance … Framework „DEATH“ Framework ACTIVE
  5. 5. Resilience Patterns ─ Timeout ─ Retry ─ Fallback ─ Circuit Breaker ─ Bulkhead many more: Uwe Friedrichsen: “Patterns of resilience” https://www.slideshare.net/ufried/patterns-of-resilience
  6. 6. @CircuitBreaker(successThreshold = 10, requestVolumeThreshold = 4, failureRatio=0.5, delay = 1000) public Connection serviceA() { Connection conn = null; counterForInvokingServiceA++; conn = connectionService(); return conn; } MicroProfile Fault Tolerance @Retry(maxRetries = 3) @Fallback(fallbackMethod = "doFallback") public Result doWork() { return callServiceA(); // fallback on RuntimeException } private Result doFallback() { return ...; }
  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) Don’t manage a Service Mesh without tooling! Requirements: (1) manage calls on layer 7 (application layer, L7) (2) resilience, routing, security and telemetry (3) decentralized & transparent for services (implementation independent)
  8. 8. Istio Architecture
  9. 9. Resilience Patterns in Istio ✔ Timeout ✔ Retry ✔ CircuitBreaker ✔ Bulkhead ✗ Fallback? ✗ is a Fallback possible? ✗ less technical, more business driven https://dzone.com/articles/fallbacks-are-overrated-architecting-for-resilienc
  10. 10. Resilience in Istio $ kubectl apply -f - <<EOF 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 EOF $ kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutiveErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF
  11. 11. Resilience in Istio Apply to sidecar Resilience rules — transparent for service — act global on all sidecars Fault Injection MicroProfile with Istio setting apiVersion:networking.istio.io/ v1alpha3 kind: VirtualService metadata: name: ratings ... spec: hosts: - ratings http: - fault: delay: fixedDelay: 7s percent: 100 MP_Fault_Tolerance_NonFallback_Enabled = false
  12. 12. Frameworks Characteristics — Java: a lot of different frameworks — Team decides framework?!? — Learning curve for every framework — Different frameworks behave different — Same framework in different version behave different — Same framework in different versions parallel in use
  13. 13. Frameworks Characteristics ➔ Change of framework: ➔ Replace all positions in code ➔ New behavior ➔ New deployment ➔ New tests ➔ Risk of chain reaction: framework ➔ load balancing ➔ service registry ➔ Multiple service registries for every different framework?
  14. 14. Service Mesh Characteristics — Define new rule — Same behavior (… no framework change) — unchanged deployed service — new tests only for new rules — Client-side load balancing in sidecar — Service Registry based on endpoints in K8S $ kubectl apply -f ...
  15. 15. Thoughts about Resilience Resilience pattern still correct if communication behavior changes? — Modified behavior of partner — Modified communication partner — Modified infrastructure — Load changes during day — Side effects from other systems — Anticipate problems of tomorrow?
  16. 16. Thoughts about Resilience — Main problem: choose the right resilience pattern — Correct parameters for pattern? — Measure resilience — Mostly: try & error for suitable pattern/params (main reason for end of life in hystrix) — Often: retry storm — Often: missing musketeer principle (black sheep)
  17. 17. Essential Requirements — Modification: Quick and easy change of (1) params for chosen pattern (2) resilience pattern — Test — Monitoring — No black sheep
  18. 18. Essential Requirements Istio Framework Modification + Modify Params - Change Pattern: Lifecycle Test Fault Injection complicated Monitoring + + Black Sheep No: rule in all sidecars $ kubectl apply -f ...
  19. 19. Conclusion — Comparable resilience patterns — Missing fallback in service mesh (but overrated) — Higher flexibility in service mesh — Fault injection easy in service mesh Solve problems where they arise! Service Mesh for L4-L7 Developer for L8 (original profession)

Descrição

Distributed systems should definitely no longer be developed and operated without resilience. The responsible developer or architect must first consider which resilience patterns are necessary. The next question is how the implementation of these patterns in the individual services should take place. One can distinguish between two basic alternatives. On the one hand an implementation with the classic resilience frameworks such as Resilience4J, Failsafe or MicroProfile Fault Tolerance. On the other hand, it is also possible to establish resilience with a service mesh tool like Istio.

In this session, after a brief introduction to Istio, the two basic alternatives are compared. The respective advantages and disadvantages are listed and compared in a final evaluation. Additional possibilities of Istio to explicitly test resilience will also be introduced.

Transcrição

  1. 1. Service Mesh vs. Frameworks: Where to put the resilience? Michael Hofmann https://hofmann-itconsulting.de
  2. 2. (1) Distributed Systems and Resilience (2) Framework (3) Service Mesh (4) Framework and Service Mesh Characteristics (5) Thoughts about Resilience (6) Essential Requirements (7) Conclusion Agenda
  3. 3. Distributed Systems ➔ degree of distribution raises failure rate! ➔ compensation strategy: resilience! slow response timeout aborted network connection ... Typical Communication Errors Fallacies of Distributed Computing 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.
  4. 4. Hystrix Alternative: Service Mesh?! Resilience Resilience4J Failsafe MicroProfile Fault Tolerance … Framework „DEATH“ Framework ACTIVE
  5. 5. Resilience Patterns ─ Timeout ─ Retry ─ Fallback ─ Circuit Breaker ─ Bulkhead many more: Uwe Friedrichsen: “Patterns of resilience” https://www.slideshare.net/ufried/patterns-of-resilience
  6. 6. @CircuitBreaker(successThreshold = 10, requestVolumeThreshold = 4, failureRatio=0.5, delay = 1000) public Connection serviceA() { Connection conn = null; counterForInvokingServiceA++; conn = connectionService(); return conn; } MicroProfile Fault Tolerance @Retry(maxRetries = 3) @Fallback(fallbackMethod = "doFallback") public Result doWork() { return callServiceA(); // fallback on RuntimeException } private Result doFallback() { return ...; }
  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) Don’t manage a Service Mesh without tooling! Requirements: (1) manage calls on layer 7 (application layer, L7) (2) resilience, routing, security and telemetry (3) decentralized & transparent for services (implementation independent)
  8. 8. Istio Architecture
  9. 9. Resilience Patterns in Istio ✔ Timeout ✔ Retry ✔ CircuitBreaker ✔ Bulkhead ✗ Fallback? ✗ is a Fallback possible? ✗ less technical, more business driven https://dzone.com/articles/fallbacks-are-overrated-architecting-for-resilienc
  10. 10. Resilience in Istio $ kubectl apply -f - <<EOF 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 EOF $ kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutiveErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF
  11. 11. Resilience in Istio Apply to sidecar Resilience rules — transparent for service — act global on all sidecars Fault Injection MicroProfile with Istio setting apiVersion:networking.istio.io/ v1alpha3 kind: VirtualService metadata: name: ratings ... spec: hosts: - ratings http: - fault: delay: fixedDelay: 7s percent: 100 MP_Fault_Tolerance_NonFallback_Enabled = false
  12. 12. Frameworks Characteristics — Java: a lot of different frameworks — Team decides framework?!? — Learning curve for every framework — Different frameworks behave different — Same framework in different version behave different — Same framework in different versions parallel in use
  13. 13. Frameworks Characteristics ➔ Change of framework: ➔ Replace all positions in code ➔ New behavior ➔ New deployment ➔ New tests ➔ Risk of chain reaction: framework ➔ load balancing ➔ service registry ➔ Multiple service registries for every different framework?
  14. 14. Service Mesh Characteristics — Define new rule — Same behavior (… no framework change) — unchanged deployed service — new tests only for new rules — Client-side load balancing in sidecar — Service Registry based on endpoints in K8S $ kubectl apply -f ...
  15. 15. Thoughts about Resilience Resilience pattern still correct if communication behavior changes? — Modified behavior of partner — Modified communication partner — Modified infrastructure — Load changes during day — Side effects from other systems — Anticipate problems of tomorrow?
  16. 16. Thoughts about Resilience — Main problem: choose the right resilience pattern — Correct parameters for pattern? — Measure resilience — Mostly: try & error for suitable pattern/params (main reason for end of life in hystrix) — Often: retry storm — Often: missing musketeer principle (black sheep)
  17. 17. Essential Requirements — Modification: Quick and easy change of (1) params for chosen pattern (2) resilience pattern — Test — Monitoring — No black sheep
  18. 18. Essential Requirements Istio Framework Modification + Modify Params - Change Pattern: Lifecycle Test Fault Injection complicated Monitoring + + Black Sheep No: rule in all sidecars $ kubectl apply -f ...
  19. 19. Conclusion — Comparable resilience patterns — Missing fallback in service mesh (but overrated) — Higher flexibility in service mesh — Fault injection easy in service mesh Solve problems where they arise! Service Mesh for L4-L7 Developer for L8 (original profession)

Mais Conteúdo rRelacionado

Livros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

Audiolivros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

×