Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

Rob Crowley

May 30, 2018

More Decks by Rob Crowley

Other Decks in Programming


  1. 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
  2. Service A Service B A ♥ story of when service

    A met service B…. Host A @robdcrowley
  3. Service A Service B As part of a Digital Transformation

    Service B is rehosted Host A Host B @robdcrowley
  4. The 8 Fallacies of Distributed Computing highlight common false assumptions

    we programmers make when starting out with distributed systems @robdcrowley
  5. Service A Service B Long distance relationships are complicated Host

    A Host B Flow Control Flow Control Networking Networking @robdcrowley
  6. 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
  7. Observability ▪ Success rates ▪ Latency logs ▪ Request volumes

    ▪ Distributed tracing (ala Open Tracing) @robdcrowley
  8. Reliability (or anti-fragility is you must! ) ▪ Health checks

    ▪ Circuit breakers ▪ Retries policies ( your services are idempotent right? ) ▪ Timeouts @robdcrowley
  9. Service A Service B Making long distance relationships work Host

    A Host B Networking Networking Flow Control Flow Control @robdcrowley
  10. 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
  11. 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
  12. 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
  13. Wait, I thought one of the benefits of microservices is

    the ability to match the language to the specific problem domain? @robdcrowley
  14. 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
  15. “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
  16. The goal of service meshes is not to introduce new

    functionality, but rather to enable a shift in where functionality is located. @robdcrowley
  17. 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
  18. 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
  19. Service meshes simplify some advanced use cases Service Service B

    V1 Service B V2 Envoy Envoy Envoy @robdcrowley
  20. Pop Quiz: So do application service developers even need to

    be aware of the service mesh? @robdcrowley
  21. A service mesh is a dedicated infrastructure layer for making

    service-to-service communication safe @robdcrowley
  22. If the operability of your services is posing a significant

    challenge, then a Service Mesh will help @robdcrowley
  23. 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