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.

3353b76e1480888ea7a482ebaa883dcb?s=128

Rob Crowley

May 30, 2018
Tweet

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
  39. None
  40. So, how you approach introducing a service mesh into your

    architecture? @robdcrowley
  41. None
  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