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
Tweet

More Decks by Rob Crowley

Other Decks in Programming

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