Making a right Mesh of your Service architecture (DevOps Perth)

Microservices and containers have transformed application design and deployment patterns. Modern cloud native architectures - which underpin many of the world's groundbreaking tech companies such as Uber, Netflix and Airbnb - afford unparalleled levels of agility and scale but are not without trade-offs. In applications comprising hundreds of services (and thousands of service instances), concerns such as security, operability and observability pose significant challenges. Supporting compensating capabilities such as circuit breakers, retry policies and service discovery in each microservice adds undesirable code bloat and impacts our ability to choose the best language for the problem at hand should the required libraries not be available.

In this talk, Rob will explore the service mesh pattern; the benefits that a decentralized microservice management approach brings; the best practices that have evolved; and most importantly what you need to know to get started leveraging a service mesh in your architecture.

Transcript

1. Making a right Mesh of your Service architecture @robdcrowley | robdcrowley
2. Goals for the session -Explore the motivation behind the Service Mesh Pattern and the category of problems it helps to solve. -Contrast Service Meshes with API Gateways and our old favourite the Enterprise Service Bus. -Investigate some of the advanced capabilities Service Meshes provide to enable low friction releases at scale. -Starting a conversation in the Perth technical community about the potential value of Service Meshes @robdcrowley
3. Service A Service B A ♥ story of when service A met service B…. Host A @robdcrowley
4. Service A Service B As part of a Digital Transformation Service B is rehosted Host A Host B @robdcrowley
5. Distributed computing is easy, right? @robdcrowley
6. Service A Service B Long distance relationships are complicated Host A Host B @robdcrowley
7. The 8 Fallacies of Distributed Computing highlight common false assumptions we programmers make when starting out with distributed systems @robdcrowley
8. Service A Service B Long distance relationships are complicated Host A Host B Flow Control Flow Control Networking Networking @robdcrowley
9. Hmmm, maybe this distributed computing thing is a little harder than we thought @robdcrowley
10. Traffic Management Observability Reliability Wait, there’s more… @robdcrowley
11. Traffic Management ▪ Load balancing (bonus points for being latency based) ▪ Service discovery (DNS alone is often insufficient) ▪ Access control ▪ Per request routing ▪ Shadowing ▪ Fault injection @robdcrowley
12. Observability ▪ Success rates ▪ Latency logs ▪ Request volumes ▪ Distributed tracing (ala Open Tracing) @robdcrowley
13. Reliability (or anti-fragility is you must! ) ▪ Health checks ▪ Circuit breakers ▪ Retries policies ( your services are idempotent right? ) ▪ Timeouts @robdcrowley
14. Service A Service B Making long distance relationships work Host A Host B Networking Networking Flow Control Flow Control @robdcrowley
15. Hmmm, maybe this distributed computing thing is a lot harder than we thought @robdcrowley
16. TCP/IP as applied to OSI 7. Application 6. Presentation 5. Session 4. Transport 3. Network 2. Data Link 1. Physical Network Access Internet (IP) Transport (TCP) Application (HTTP) OSI TCP/IP @robdcrowley
17. As application requirements became more sophisticated, we again looked to abstract these capabilities @robdcrowley
18. Centralised management of your services Enterprise Service Bus Service E Service H Service F Service G Service A Service D Service B Service C @robdcrowley
19. centralised architecture == single point of failure @robdcrowley
20. Over time these centralised architectures tend to become complex and atrophy change @robdcrowley
21. Continuous Delivery Microservices Cloud Native DevOps Containers @robdcrowley
22. Life in a microservices world… @robdcrowley
23. Smart endpoints, dumb pipes @robdcrowley
24. Service A Service B Very long distance relationships are even worse Host A Host B Networking Networking Service Discovery Flow Control Flow Control Circuit Breakers Service Discovery Circuit Breakers @robdcrowley
25. Wait, I thought one of the benefits of microservices is the ability to match the language to the specific problem domain? @robdcrowley
26. Sidecar Proxy Service A Making very long distance relationships work Host A Networking Flow Control Service B Host B Networking Flow Control Sidecar Proxy Service Discovery Circuit Breakers Service Discovery Circuit Breakers @robdcrowley
27. Life in a better microservices world… @robdcrowley
28. “A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.” - William Morgan @robdcrowley
29. The goal of service meshes is not to introduce new functionality, but rather to enable a shift in where functionality is located. @robdcrowley
30. Service meshes comprise both a data plane and a control plane @robdcrowley
31. Decentralised management of your services Service Mesh Control Plane @robdcrowley
32. Decentralised management of your services Service Mesh Control Plane @robdcrowley
33. The control plane provides the same authoritative source of policies and routing decisions as with an ESB, without being on the critical path of every request @robdcrowley
34. So would the deployment model look like in Kubernetes? @robdcrowley
35. Linkerd as daemon set on Kubernetes Linkerd Service A Service B Service C Service E Service D Service F Linkerd Service G Service H Service I Service K Service J Service L Host A Host B Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod
36. Service meshes simplify some advanced use cases Service Service B V1 Service B V2 Envoy Envoy Envoy @robdcrowley
37. Service meshes are typically supported by a platform team within an enterprise @robdcrowley
38. Pop Quiz: So do application service developers even need to be aware of the service mesh? @robdcrowley
40. So, how you approach introducing a service mesh into your architecture? @robdcrowley
42. Start with a single capability, say instrumentation, and support that via the service mesh @robdcrowley
43. Takeaways @robdcrowley
44. A service mesh is a dedicated infrastructure layer for making service-to-service communication safe @robdcrowley
45. If the operability of your services is posing a significant challenge, then a Service Mesh will help @robdcrowley
46. Service Meshes afford gradual adoption. Take advantage of this and start with single use case. @robdcrowley
47. Thank You! @robdcrowley | robdcrowley
48. Resources - 8 Fallacies of Distributed Computing: - Overview: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing - Book: https://www.amazon.com/Dr-Harvey-Fallacies-Distributed-Computing/dp/1367251796 - Service Mesh: - Overview: https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ - InfoQ Panel: https://www.infoq.com/articles/vp-microservices-communication-governance-using- service-mesh - Linkerd: - Overview: https://linkerd.io/getting-started/ - InfoQ Podcast: https://www.infoq.com/podcasts/Oliver-Gould-microservices-linkerd-service-mesh @robdcrowley