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.

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>

47. Questions?
Neeraj Poddar
@nrjpoddar
neeraj@aspenmesh.io