Tweet
Tweet

Slide 1

Slide 1 text

@robdcrowley | robdcrowley Service Meshes Powering the next wave of microservice architectures

Slide 2

Slide 2 text

So who has heard of the Service Mesh pattern? @robdcrowley

Slide 3

Slide 3 text

Is anyone using a Service Mesh in production? @robdcrowley

Slide 4

Slide 4 text

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 Sydney technical community about the potential value of Service Meshes. @robdcrowley

Slide 5

Slide 5 text

A smart person once told me that every good presentation has a story… @robdcrowley

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Distributed computing is easy, right? @robdcrowley

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Reliability (not anti-fragility! ) ▪ Health checks ▪ Circuit breakers ▪ Retry policies (your services are idempotent right?) ▪ Timeouts @robdcrowley

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

centralised architecture == single point of failure @robdcrowley

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Continuous Delivery Microservices Cloud Native DevOps Containers @robdcrowley

Slide 25

Slide 25 text

Life in a microservices world… @robdcrowley

Slide 26

Slide 26 text

Smart endpoints, dumb pipes @robdcrowley

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Life in a better microservices world… @robdcrowley

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Decentralised management of your services Service Mesh Control Plane @robdcrowley

Slide 35

Slide 35 text

Decentralised management of your services Service Mesh Control Plane @robdcrowley

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

@robdcrowley

Slide 38

Slide 38 text

Istio @robdcrowley

Slide 39

Slide 39 text

A high level view of Istio Service A Sidecar @robdcrowley Service B Sidecar HTTP/1.1, HTTP/2, gRPC or TCP . mTLS is optional Pilot Citadel Mixer

Slide 40

Slide 40 text

A high level view of Istio Service A Sidecar @robdcrowley Service B Sidecar HTTP/1.1, HTTP/2, gRPC or TCP . mTLS is optional Pilot Citadel Mixer

Slide 41

Slide 41 text

A high level view of Istio Service A Sidecar @robdcrowley Service B Sidecar HTTP/1.1, HTTP/2, gRPC or TCP . mTLS is optional Pilot Citadel Mixer Policy checks & telemetry

Slide 42

Slide 42 text

A high level view of Istio Service A Sidecar @robdcrowley Service B Sidecar HTTP/1.1, HTTP/2, gRPC or TCP . mTLS is optional Pilot Citadel Mixer

Slide 43

Slide 43 text

Istio in Action @robdcrowley

Slide 44

Slide 44 text

Family dynamics Service A @robdcrowley Service B Service C V2 Service C V3 Service C V1 Service D

Slide 45

Slide 45 text

Testing in production is not just for hipsters… …the trick is doing it safely

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

Traffic Mirroring @robdcrowley

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Canary Releases @robdcrowley

Slide 50

Slide 50 text

@robdcrowley Service A Service B V1 Service B V2 Envoy Envoy Envoy Service meshes simplify some advanced use cases Pilot Push traffic routing rules to sidecar proxy

Slide 51

Slide 51 text

Circuit Breakers @robdcrowley

Slide 52

Slide 52 text

@robdcrowley Service A Envoy Service meshes simplify some advanced use cases Service C V1 Envoy Service C V2 Envoy Service C V3 Envoy

Slide 53

Slide 53 text

@robdcrowley Service A Envoy Service meshes simplify some advanced use cases Eject host from connection pool Service C V1 Envoy Service C V2 Envoy Service C V3 Envoy X

Slide 54

Slide 54 text

Chaos Engineering @robdcrowley

Slide 55

Slide 55 text

@robdcrowley Service A Envoy Service C V1 Envoy Service C V2 Envoy Service D Envoy

Slide 56

Slide 56 text

@robdcrowley Service A Envoy Service C V1 Envoy Service C V2 Envoy X Service D Envoy Inject faults for 25% traffic to D

Slide 57

Slide 57 text

Per Request Overrides @robdcrowley

Slide 58

Slide 58 text

@robdcrowley Service meshes decouple traffic management from infrastructure scaling

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

@robdcrowley

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

@robdcrowley

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

Takeaways @robdcrowley

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Service Meshes afford gradual adoption. Start with single use case. @robdcrowley

Slide 69

Slide 69 text

Questions @robdcrowley

Slide 70

Slide 70 text

Thank You! @robdcrowley | robdcrowley

Slide 71

Slide 71 text

Resources ▪ 8 Fallacies of Distributed Computing: ▪ Overview: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing ▪ 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 ▪ InfoQ Podcast: https://www.infoq.com/podcasts/Oliver-Gould-microservices-linkerd-service-mesh ▪ Istio: ▪ Overview: https://istio.io/docs/concepts/what-is-istio/ ▪ Kelsey Hightower Velocity Talk: https://www.youtube.com/watch?v=6BYq6hNhceI ▪ Istio Demo Application: https://github.com/robcrowley/istio-demo @robdcrowley

Slide 72

Slide 72 text

Slides are available at bit.ly/ndcsydney-mesh @robdcrowley

Slide 73

Slide 73 text

Appendices @robdcrowley

Slide 74

Slide 74 text

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