More Related Content Similar to Service-mesh options with Linkerd, Consul, Istio and AWS AppMesh (20) More from Christian Posta (20) Service-mesh options with Linkerd, Consul, Istio and AWS AppMesh1. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
Editor's Notes …… new challenge….. Let’s come back to that….. One large database!
We should focus on how we design our data models so that they can be sharded and distributed…. Focus on transactions, etc not 2PC One large database!
We should focus on how we design our data models so that they can be sharded and distributed…. Focus on transactions, etc not 2PC Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools. Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.