Service mesh abstracts the network from developers to solve three main pain points: How do services communicate securely with one another How can services implement network resilience When things go wrong, can we identify what and why Service mesh implementations usually follow a similar architecture: traffic flows through control points between services (usually service proxies deployed as sidecar processes) while an out-of-band set of nodes is responsible for defining the behavior and management of the control points. This loosely breaks out into an architecture of a "data plane" through which requests flow and a "control plane" for managing a service mesh. Different service mesh implementations use different data planes depending on their use cases and familiarity with particular technology. The control plane implementations vary between service-mesh implementations as well. In this talk, we'll take a look at three different control plane implementations with Istio, Linkerd and Consul, their strengths, and their specific tradeoffs to see how they chose to solve each of the three pain points from above. We can use this information to make choices about a service mesh or to inform our journey if we choose to build a control plane ourselves.

1. 1 | Copyright © 2019
Service-mesh options with Linkerd,
Consul, Istio and AppMesh
Christian Posta
Global Field CTO, Solo.io
Craft Conf 2019

2. 2 | Copyright © 2019
CHRISTIAN POSTA
• Field CTO @ solo.io
• Author of a few books
• Contributor to many open-source projects
• Architect, blogger, speaker, mentor, leader
https://bit.ly/istio-in-action
@christianposta
christian@solo.io
https://blog.christianposta.com
https://slideshare.net/ceposta

3. 3 | Copyright © 2019
Flow of talk
• What’s the problem we’re addressing with a service mesh?
• What is a service mesh? Previous approaches / pros / cons
• Generic service-mesh architecture
• Explore service-mesh implementations
• Guidance for service-mesh adoption

4. 4 | Copyright © 2019
Move fast, safely
https://puppet.com/resources/whitepaper/state-of-devops-report

5. 5 | Copyright © 2019
Come on… how hard can it be!?

6. 6 | Copyright © 2019

7. 7 | Copyright © 2019

8. 8 | Copyright © 2019
As we move to services architectures,
we push the complexity to the space
between our services.

9. 9 | Copyright © 2019
Challenges in a cloudy world
• Service discovery
• Retries
• Timeouts
• Load balancing
• Rate limiting
• Thread bulk heading
• Circuit breaking
• Security

10. 10 | Copyright © 2019
…Continued…
• Routing between services (adaptive, zone-aware)
• Deadlines
• Back pressure
• Outlier detection
• Health checking
• Traffic shaping
• Request shadowing

11. 11 | Copyright © 2019
…Continued…
• Edge/DMZ routing
• Surgical / fine / per-request routing
• A/B rollout
• Internal releases / dark launches
• Fault injection
• Stats, metric, collection
• Logging
• Tracing

12. 12 | Copyright © 2019
• Netflix Hystrix (circuit breaking / bulk heading)
• Netflix Zuul (edge router)
• Netflix Ribbon (client-side service discovery / load balance)
• Netflix Eureka (service discovery registry)
• Brave / Zipkin (tracing)
• Netflix spectator / atlas (metrics)
Microservices Patterns

13. 13 | Copyright © 2019
But I’m using Spring!
• spring-cloud-netflix-hystrix
• spring-cloud-netflix-zuul
• spring-cloud-netflix-eureka-client
• spring-cloud-netflix-ribbon
• spring-cloud-netflix-atlas
• spring-cloud-netflix-spectator
• spring-cloud-netflix-hystrix-stream
• …..
• @Enable....150differentThings

14. 14 | Copyright © 2019
But I’m using Vert.x!
• vertx-circuit-breaker
• vertx-service-discovery
• vertx-dropwizard-metrics
• vertx-zipkin?
• …..
• ......

15. 15 | Copyright © 2019
Screw Java - I’m using NodeJS!
JavaScript is for rookies, I use Go!
But python is so pretty!
I prefer unreadability… Perl for me!

16. 16 | Copyright © 2019
• Require specific language to bring in new services
• A single language doesn’t fit for all use cases
• How do you patch/upgrade/manage lifecycle?
• Need strict control over application library choices
Some drawbacks to this approach?

17. 17 | Copyright © 2019
Let’s abstract this functionality and apply to all
services out of process
• Allow heterogeneous architectures
• Remove application-specific implementations of this
functionality
• Consistently enforce these properties
• Correctly enforce these properties
• Opt-in as well as safety nets

18. 18 | Copyright © 201918 | Copyright © 2019
Foundation for a solution

19. 19 | Copyright © 2019
Meet Envoy Proxy
http://envoyproxy.io

20. 20 | Copyright © 2019
Envoy Proxy:
• written in C++, highly parallel, non-blocking
• L4 / L7 service proxy (HTTP1, HTTP2, gRPC, Kafka, Redis, Mongo, Dynamo, etc)
• zone aware, least request load balancing
• circuit breaking / outlier detection
• retries, retry policies
• timeout (including budgets)
• traffic shadowing
• rate limiting
• access logging, statistics collection
• dynamic configuration through standard interfaces

21. 21 | Copyright © 2019

22. 22 | Copyright © 2019

23. 23 | Copyright © 2019
Deployed as a service proxy:

24. 24 | Copyright © 2019
A service mesh is decentralized application-
networking infrastructure between your services
that provides resiliency, security, observability,
and routing control.

25. 25 | Copyright © 201925 | Copyright © 2019
Service-mesh architecture

26. 26 | Copyright © 2019

27. 27 | Copyright © 2019

28. 28 | Copyright © 2019

29. 29 | Copyright © 2019
Service mesh technologies typically provide:
• Service discovery / Load balancing
• Secure service-to-service communication
• Traffic control / shaping / shifting
• Policy / Intention based access control
• Traffic metric collection
• Service resilience
• API / programmable interface

30. 30 | Copyright © 201930 | Copyright © 2019
Exploring service-mesh implementations

31. 31 | Copyright © 2019
Meet Linkerd
http://linkerd.io

32. 32 | Copyright © 2019
Linkerd2
• Backed by Buoyant / CNCF
• Kubernetes specific
• Control plane (go) / custom data plane (rust)
• Latest release 2.3
• Strong focus on observing top-level network metrics
• Resilience, timeouts, retry budgets
• Always-on mTLS

33. 33 | Copyright © 2019

34. 34 | Copyright © 2019
Linkerd2
• Purpose built, Kubernetes only
• Uses CRD for configurations
• High performance characteristics
• Great user/getting-started experience
• Open, welcoming community
• Observability, basic resilience
• Secure by default
• Deployed transparently to app
Strengths
• Limited feature set (at the moment…
more to come)
• Missing traffic routing, policy
enforcement, circuit breakers
• Kubernetes-only
• Relatively new, evolving networking
stack
• Multi-cluster support
Opportunities

35. 35 | Copyright © 2019
Meet Consul Connect
http://consul.io

36. 36 | Copyright © 2019
Consul Connect
• Backed by HashiCorp
• Control plane (consul server) / data plane (proxies/app)
• Part of Consul 1.2 release, June 2018 (latest is 1.4)
• Strong focus on L4 Identity (SPIFFE)
• Easy to configure transport encryption (mTLS)
• Service segmentation, intention-based ACL policy
• Optional use of Envoy Proxy
• Native app integration for latency/performance sensitive apps

37. 37 | Copyright © 2019

38. 38 | Copyright © 2019
Consul Connect
• Built on Consul: stable, critical piece
of software
• Solves the identity management
challenges in dynamic applications
• Hybrid environment support
• Optional Envoy Proxy
• Multi-cluster/site foundations
• Vault support for certificate
management
Strengths
• Application config/code impact (not
transparent to app, cannot use k8s dns)
• No L7 (routing, matching, observability,
policy, traffic control)..yet
• Have to manage separate CP data
store
• does not use CRDs on k8s
• No distributed tracing
Opportunities

39. 39 | Copyright © 2019
Meet Istio.io
http://istio.io

40. 40 | Copyright © 2019
Istio
• Control plane / data plane (Envoy Proxy)
• 1.1 March 2019
• Collaboration between Google, IBM, Lyft, VMWare, Red Hat, et al.
• Based on Envoy proxy
• mTLS, policy based ACL, resilience, observability, traffic control
• Kubernetes native with other platform support
• Large community

41. 41 | Copyright © 2019

42. 42 | Copyright © 2019
Istio
• Large, vibrant community
• Backed by Google, et. al.
• Large feature set
• Based on Envoy
• Flexible deployment options
• Out of the box Ingress
• Multi-cluster support
Strengths
• Performance / overhead improvements
• Architecture improvements
• Focus on iterative adoption
• Continue improvement to
documentation
• Reduce magic
Opportunities

43. 43 | Copyright © 2019
Meet AWS App Mesh
https://aws.amazon.com/app-mesh/

44. 44 | Copyright © 2019
AWS App Mesh
• Backed by AWS
• Control plane (managed) / data plane (Envoy Proxy)
• Announced Nov 2018, GA March 2019
• Main functionality is around weighted traffic routing
• Supported across deployment platforms
• Continuing to add more features

45. 45 | Copyright © 2019

46. 46 | Copyright © 2019
AWS App Mesh
• Managed control plane
• Built on Envoy Proxy
• Supports multiple deployment
platforms (EC2, ECS, EKS,
Kubernetes)
• Focus on basic traffic shifting
• Ties in with rest of AWS infrastructure
• Free to use on AWS
Strengths
• AWS Only
• Very limited control-plane capabilities
• No visibility to control plane behavior
• No mTLS, Policy, enforcement fine-
grained traffic control
• Manually configure Envoy for metrics-
collection/CloudWatch integration
Opportunities

47. 47 | Copyright © 201947 | Copyright © 2019
Comparisons

48. 48 | Copyright © 2019
Anecdotal comparisons:
Benchmarking Istio and Linkerd CPU:
https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781
Benchmarking Istio and Linkerd at Scale (follow up)
https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-at-scale-5f2cfc97c7fa

49. 49 | Copyright © 2019
Wrapping up - Ignore comparisons and anecdotes.
Focus on:
• Service mesh approach is the right approach, implementations still evolving
• Solve today’s pain with as little technology as you can
• Invest in the data plane (Envoy proxy)
• Ingress-first approach: API Gateways (like Gloo, built on Envoy) can give you service-
mesh-like capabilities with a fraction of the complexity and risk
• Iteratively adopt service-mesh capabilities (and commensurate deployment footprint)
• Abstract service-mesh implementation details, configuration, opinions

50. 50 | Copyright © 2019
Easiest way to get started with service mesh is with…
https://supergloo.solo.io

51. 51 | Copyright © 2019
https://supergloo.solo.io

52. 52 | Copyright © 2019
Exploring service mesh implementations
“I used SuperGloo because it was super simple to get both services meshes
bootstrapped quickly, with almost no effort on my part. We’re not using SuperGloo
in production, but it was perfect for a task like this. It was literally two commands
per mesh. I used two clusters for isolation— one for Istio, and one for Linkerd.”
https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781

53. 53 | Copyright © 2019
Additional reading
• Istio the easy way
https://medium.com/solo-io/istio-the-easy-way-de66e6eba4a1
• Linkerd vs Istio
https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42
• SuperGloo Open API and Service Mesh Orchestration
https://medium.com/solo-io/https-medium-com-solo-io-supergloo-ff2aae1fb96f
• Follow up: Benchmarking Istio and Linkerd at Scale
• https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-at-scale-
5f2cfc97c7fa
• Linkerd April 2019 Community Meeting
https://buoyant.io/resources/april-2019-linkerd-community-meeting-recap/
• AWS AppMesh FAQ
https://aws.amazon.com/app-mesh/faqs/
• Consul Connect Intro
https://www.hashicorp.com/resources/consul-connect-announcement-mitchell-hashimoto
• Consul Connect Roadmap
https://www.hashicorp.com/blog/roadmap-preview-what-s-next-for-consul-service-mesh

54. 54 | Copyright © 2019
CHRISTIAN POSTA
@christianposta
christian@solo.io
https://blog.christianposta.com
https://slideshare.net/ceposta

55. 55 | Copyright © 201955 | Copyright © 2019
@soloio_inc