I'm a developer; should I care about a service mesh?
Download as PPTX, PDF3 likes612 views
The document discusses the relevance of service meshes for developers, emphasizing their role in managing communication between microservices to allow developers to focus on business logic. It outlines considerations for using service meshes, including telemetry, security, and the need for potential application changes. Additionally, real-life use case scenarios demonstrate how service meshes can facilitate zero downtime migration for services.
I'm a developer; should I care about a service mesh?
- 1. I’m A Developer; Should I Care About A Service Mesh? Neeraj Poddar Engineering Lead, Aspen Mesh
- 2. Developers Are The New Kingmakers
- 3. Companies want developers to focus more on business logic
- 4. Monolith vs Microservices ~ https://martinfowler.com/articles/microservices.html
- 5. Introducing Service Mesh A service mesh is… a transparent infrastructure layer that manages communication between microservices so that developers can focus on business logic while operators work independent of dev cycles to provide a more resilient environment
- 6. Sidecar Proxy Architecture Service Mesh Control Plane App A Proxy App B Proxy Service A Service B Observability Security Traffic Management
- 7. What Should Developers Care About? • What functionality can I offload? • Do I need to change my applications? Considerations when using a service mesh?
- 8. What functionality can I offload?
- 9. Telemetry App A Proxy App B Proxy Service A Service B
- 10. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B
- 11. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics
- 12. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics SLO Dashboards
- 13. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics SLO Dashboards Application level metrics
- 14. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics SLO Dashboards Application level metrics SLI Measurements
- 15. Mutual TLS App A Proxy App B Proxy Service A Service B
- 16. Mutual TLS Certificate Manager App A Proxy App B Proxy Service A Service B Certificate Provisioning/Rotation
- 17. Mutual TLS Certificate Manager App A Proxy App B Proxy Service A Service B Certificate Provisioning/Rotation Workload Identity Workload Identity
- 18. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C
- 19. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1
- 20. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T2 x-b3-parentSpanId: T1
- 21. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T2 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 Context Propagation
- 22. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T2 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 Context Propagation Async Reporting
- 23. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T2 x-b3-parentSpanId: T1 x-b3-traceId: T1 x-b3-spanId: T1 x-b3-parentSpanId: T1 Context Propagation Async Reporting Application Spans
- 24. • Do I need to change my applications?
- 25. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB
- 26. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB
- 27. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB Stats Adapter TCP Metrics
- 28. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB Stats Adapter TCP Metrics
- 29. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB Stats Adapter TCP Metrics
- 30. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB Stats Adapter
- 31. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB Stats Adapter HTTP Metrics
- 32. Considerations when using a service mesh?
- 33. Application Requirements Purely event driven architectures Customized load-balancing/persistence requirements Highly latency sensitive
- 34. How To Make A Service Mesh Work…
- 35. Real Life Use Case! AUTH SERVICE Service B Service C Service A Service B Service C ISTIO INGRESS Namespace: user-1 Service A Namespace: user-2 https://my.aspenmesh.io/serviceA/<cluster-id> DB
- 36. AUTH SERVICE Service B Service C Service A Service B Service C ISTIO INGRESS Namespace: user-1 Service A Namespace: user-2 https://my.aspenmesh.io/serviceA/<cluster-id> DB
- 37. AUTH SERVICE Service B Service C Service A Service B Service C ISTIO INGRESS Namespace: user-1 Service A Namespace: user-2 Zero Downtime Migration https://my.aspenmesh.io/serviceA/<cluster-id> DB
- 38. AUTH SERVICE Service B Service C Service A Service B Service C ISTIO INGRESS Service A Zero Downtime Migration https://my.aspenmesh.io/serviceA/<cluster-id> DB
- 39. AUTH SERVICE Service B Service C Service A Service B Service C ISTIO INGRESS Service A Zero Downtime Migration Namespace: org-2 https://my.aspenmesh.io/serviceA/<cluster-id> Namespace: org-1 DB
- 40. Service A Service B Service C ISTIO INGRESS Zero Downtime Migration: Option 1 Namespace: user-2 AUTH SERVICE OLD Sends traffic to user namespaces https://my.aspenmesh.io/serviceA/<cluster-id>
- 41. AUTH SERVICE NEW Service B Service C Service A Service B Service C ISTIO INGRESS Namespace: org-1 Service A Zero Downtime Migration: Option 1 Namespace: user-2 AUTH SERVICE OLD Sends traffic to user namespaces Sends traffic to org namespaces https://my.aspenmesh.io/serviceA/<cluster-id>
- 42. AUTH SERVICE NEW Service B Service C Service A Service B Service C ISTIO INGRESS Namespace: org-1 Service A Zero Downtime Migration: Option 1 Namespace: user-2 AUTH SERVICE OLD Sends traffic to user namespaces Sends traffic to org namespaces host: my.aspenmesh.io port: 443 path: serviceA/cluster-1 route: destination: auth-service-new default: route: destination: auth-service-old https://my.aspenmesh.io/serviceA/<cluster-id>
- 43. Service A Service B Service C ISTIO INGRESS Zero Downtime Migration: Option 2 Namespace: user-2 AUTH SERVICE https://my.aspenmesh.io/serviceA/<cluster-id>
- 44. Service A Service B Service C ISTIO INGRESS Zero Downtime Migration: Option 2 Namespace: user-2 AUTH SERVICE https://my.aspenmesh.io/serviceA/<cluster-id>
- 45. Service A Service B Service C ISTIO INGRESS Zero Downtime Migration: Option 2 Namespace: user-2 AUTH SERVICE ENVOY PROXY https://my.aspenmesh.io/serviceA/<cluster-id>
- 46. Service B Service C Service A Service B Service C ISTIO INGRESS Namespace: org-1 Service A Zero Downtime Migration: Option 2 Namespace: user-2 AUTH SERVICE ENVOY PROXY host:serviceA.user-1.svc.cluster.local route: destination: serviceA.org-1.svc.cluster.local ---- host:serviceB.user-1.svc.cluster.local route: destination: serviceB.org-1.svc.cluster.local ….. https://my.aspenmesh.io/serviceA/<cluster-id>