A disruptive technology pattern like a service mesh is exciting, but can also be confusing as it straddles various concerns and responsibilities ranging from SecOps to application developers. This talk will dissect service mesh capabilities using Istio as an example and focus on the pieces that developers should care about and how they can offload some of the logic traditionally baked into the applications - distributed tracing, telemetry, request retries and timeouts, mutual TLS and end user validation - into a common infrastructure layer. The session will also explore various questions developers should be asking their platform teams like “do I need to update my applications to use service mesh?” and “will the sidecars degrade my application performance?” as they adopt a service mesh in their environment.

2. I’m A Developer;
Should I Care About A Service Mesh?
Neeraj Poddar
Co-founder & Engineering Lead, Aspen Mesh

3. Monolith vs Microservices
~ https://martinfowler.com/articles/microservices.html

4. 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

5. Sidecar Proxy Architecture
Service Mesh Control Plane
App A
Proxy
App B
Proxy
Service A Service B
Observability
Security
Traffic
Management

6. What Should Developers Care About?
• What functionality can I offload?
• Do I need to change my applications?
Considerations when using a service mesh?

7. What functionality can I offload?

8. Telemetry
Stats Adapter
App A
Proxy
App B
Proxy
Service A Service B
Service level metrics
SLO Dashboards
Application level metrics
SLI
Measurements

9. Mutual TLS
Certificate Manager
App A
Proxy
App B
Proxy
Service A Service B
Certificate Provisioning/Rotation
Workload Identity Workload Identity

10. 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

11. • Do I need to change my applications?

12. Well…it depends
• Are you using distributed tracing?
•
• Are you talking to external services?
App A
Proxy
Service A
External
DB
Stats Adapter
TCP MetricsHTTP Metrics

13. Considerations when using a service mesh?

14. Application Requirements
Purely event driven architectures
Customized load-balancing/persistence requirements
Highly latency sensitive

15. How To Make A Service Mesh Work…

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