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
   

   View Slide

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
   

   View Slide

3. Service A Service B
   A ♥ story of when service A met service B….
   Host A
   @robdcrowley
   

   View Slide

4. Service A Service B
   As part of a Digital Transformation Service B is rehosted
   Host A Host B
   @robdcrowley
   

   View Slide

5. Distributed computing is easy, right?
   @robdcrowley
   

   View Slide

6. Service A Service B
   Long distance relationships are complicated
   Host A Host B
   @robdcrowley
   

   View Slide

7. The 8 Fallacies of Distributed Computing highlight
   common false assumptions we programmers make
   when starting out with distributed systems
   @robdcrowley
   

   View Slide

8. Service A Service B
   Long distance relationships are complicated
   Host A Host B
   Flow Control Flow Control
   Networking Networking
   @robdcrowley
   

   View Slide

9. Hmmm, maybe this distributed computing thing is
   a little harder than we thought
   @robdcrowley
   

   View Slide

10. Traffic
    Management
    Observability
    Reliability
    Wait, there’s more…
    @robdcrowley
    

    View Slide

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
    

    View Slide

12. Observability
    ▪ Success rates
    ▪ Latency logs
    ▪ Request volumes
    ▪ Distributed tracing (ala Open Tracing)
    @robdcrowley
    

    View Slide

13. Reliability (or anti-fragility is you must! )
    ▪ Health checks
    ▪ Circuit breakers
    ▪ Retries policies ( your services are idempotent right? )
    ▪ Timeouts
    @robdcrowley
    

    View Slide

14. Service A Service B
    Making long distance relationships work
    Host A Host B
    Networking Networking
    Flow Control Flow Control
    @robdcrowley
    

    View Slide

15. Hmmm, maybe this distributed computing thing is
    a lot harder than we thought
    @robdcrowley
    

    View Slide

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
    

    View Slide

17. As application requirements became more
    sophisticated, we again looked to abstract these
    capabilities
    @robdcrowley
    

    View Slide

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
    

    View Slide

19. centralised architecture == single point of failure
    @robdcrowley
    

    View Slide

20. Over time these centralised architectures tend to
    become complex and atrophy change
    @robdcrowley
    

    View Slide

21. Continuous
    Delivery
    Microservices
    Cloud
    Native
    DevOps
    Containers
    @robdcrowley
    

    View Slide

22. Life in a microservices world…
    @robdcrowley
    

    View Slide

23. Smart endpoints, dumb pipes
    @robdcrowley
    

    View Slide

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
    

    View Slide

25. Wait, I thought one of the benefits of microservices is
    the ability to match the language to the specific
    problem domain?
    @robdcrowley
    

    View Slide

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
    

    View Slide

27. Life in a better microservices world…
    @robdcrowley
    

    View Slide

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
    

    View Slide

29. The goal of service meshes is not to introduce new
    functionality, but rather to enable a shift in where
    functionality is located.
    @robdcrowley
    

    View Slide

30. Service meshes comprise both a data plane and a
    control plane
    @robdcrowley
    

    View Slide

31. Decentralised management of your services
    Service Mesh Control Plane
    @robdcrowley
    

    View Slide

32. Decentralised management of your services
    Service Mesh Control Plane
    @robdcrowley
    

    View Slide

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
    

    View Slide

34. So would the deployment model look like in
    Kubernetes?
    @robdcrowley
    

    View Slide

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
    

    View Slide

36. Service meshes simplify some advanced use cases
    Service
    Service B
    V1
    Service B
    V2
    Envoy
    Envoy
    Envoy
    @robdcrowley
    

    View Slide

37. Service meshes are typically supported by a platform
    team within an enterprise
    @robdcrowley
    

    View Slide

38. Pop Quiz: So do application service developers even
    need to be aware of the service mesh?
    @robdcrowley
    

    View Slide

39. View Slide

40. So, how you approach introducing a service mesh into
    your architecture?
    @robdcrowley
    

    View Slide

41. View Slide

42. Start with a single capability, say instrumentation, and
    support that via the service mesh
    @robdcrowley
    

    View Slide

43. Takeaways
    @robdcrowley
    

    View Slide

44. A service mesh is a dedicated infrastructure layer for
    making service-to-service communication safe
    @robdcrowley
    

    View Slide

45. If the operability of your services is posing a significant
    challenge, then a Service Mesh will help
    @robdcrowley
    

    View Slide

46. Service Meshes afford gradual adoption.
    Take advantage of this and start with single use case.
    @robdcrowley
    

    View Slide

47. Thank You!
    @robdcrowley | robdcrowley
    

    View Slide

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
    

    View Slide