Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OSCON 2019 - I'm a Developer, should I care about a service mesh?

210 views

Published on

A disruptive technology pattern like a service mesh is exciting, but it can also be confusing as it straddles various concerns and responsibilities ranging from SecOps to application developers.

Neeraj Poddar dissects service mesh capabilities using Istio as an example, focusing on the pieces you should care about, and explores how you can offload some of the logic traditionally baked into the applications—distributed tracing and telemetry, request retries and timeouts, mutual transport layer security (TLS) and end user validation, and service decomposition—into a common infrastructure layer. Neeraj then walks you through some of the questions you should be asking your platform team, such as if you need to update your applications to use service mesh and whether or not the sidecars will downgrade your application performance, as you adopt a service mesh environment.

Published in: Software
  • Login to see the comments

  • Be the first to like this

OSCON 2019 - I'm a Developer, should I care about a service mesh?

  1. 1. I’m A Developer; Should I Care About A Service Mesh? Neeraj Poddar Engineering Lead, Aspen Mesh
  2. 2. Developers Are The New Kingmakers
  3. 3. Companies want developers to focus more on business logic
  4. 4. Monolith vs Microservices ~ https://martinfowler.com/articles/microservices.html
  5. 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. 6. Sidecar Proxy Architecture Service Mesh Control Plane App A Proxy App B Proxy Service A Service B Observability Security Traffic Management
  7. 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. 8. What functionality can I offload?
  9. 9. Telemetry App A Proxy App B Proxy Service A Service B
  10. 10. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B
  11. 11. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics
  12. 12. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics SLO Dashboards
  13. 13. Telemetry Stats Adapter App A Proxy App B Proxy Service A Service B Service level metrics SLO Dashboards Application level metrics
  14. 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. 15. Mutual TLS App A Proxy App B Proxy Service A Service B
  16. 16. Mutual TLS Certificate Manager App A Proxy App B Proxy Service A Service B Certificate Provisioning/Rotation
  17. 17. Mutual TLS Certificate Manager App A Proxy App B Proxy Service A Service B Certificate Provisioning/Rotation Workload Identity Workload Identity
  18. 18. Distributed Tracing App A Proxy App B Proxy Service A Service B App C Proxy Service C
  19. 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. 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. 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. 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. 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. 24. • Do I need to change my applications?
  25. 25. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB
  26. 26. Well…it depends • Are you using distributed tracing? • • Are you talking to external services? App A Proxy Service A External DB
  27. 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. 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. 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. 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. 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. 32. Considerations when using a service mesh?
  33. 33. Application Requirements Purely event driven architectures Customized load-balancing/persistence requirements Highly latency sensitive
  34. 34. How To Make A Service Mesh Work…
  35. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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>
  47. 47. Questions? Neeraj Poddar @nrjpoddar neeraj@aspenmesh.io

×