Downloaded 28 times
Uploaded byChristian Posta
PHX DevOps Days: Service Mesh Landscape
The document discusses the complexities of microservices architecture and the challenges it presents, emphasizing the need for effective service communication. It outlines the concept of service meshes as a decentralized, application-agnostic infrastructure that enhances service-to-service communication through various functionalities like service discovery and traffic control. Additionally, it reviews several open-source service mesh projects, including Linkerd, Consul Connect, and Istio, highlighting their features and use cases.
More Related Content
Similar to PHX DevOps Days: Service Mesh Landscape
![Service Mesh in the Real World [Raleigh NC Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/service-mesh-real-world-191016164816-thumbnail.jpg?width=640&height=640&fit=bounds)
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
PHX DevOps Days: Service Mesh Landscape
- 1.
- 2. Christian Posta Chief Architect,cloud application development Twitter: @christianposta Blog: http://blog.christianposta.com Slides: http://slideshare.net/ceposta • Author multiple books, latest Istio in Action • Committer/contributor lots of open-source projects • Blogger, speaker, mentor, leader
- 3.
- 4. Microservice A highly distractingword that serves to confuse developers, architects, and IT leaders into believing that we can actually have a utopian application architecture. @christianposta
- 5. Microservice A highly distractingword that serves to confuse developers, architects, and IT leaders into believing that we can actually have a utopian application architecture. An architecture optimization that treats the modules of an application as independently owned and deployed services for the purposes of increasing an organization’s velocity @christianposta
- 6.
- 7. @christianposta Our services needto connect to each other to provide overall business value.
- 8.
- 9. @christianposta Come on… howhard can it be!?
- 10.
- 11.
- 12.
- 13. As we moveto services architectures, we push the complexity to the space between our services. @christianposta
- 14. New challenges ina cloudy, services world • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking @christianposta
- 15. …continued • Routing betweenservices (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing @christianposta
- 16. …continued • Edge/DMZ routing •Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
- 17.
- 18. • 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
- 19. But I’m usingSpring! • 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
- 20. But I’m usingVert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ......
- 21. Screw Java -I’m using NodeJS! JavaScript is for rookies, I use Go! But python is so pretty! I prefer unreadability… Perl for me!
- 22. • Require specificlanguage 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 • Inconsistent implementations • Incorrect implementations Some drawbacks to this approach? @christianposta
- 23. Let’s abstract thisfunctionality to a single binary and apply to all services. • 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 @christianposta
- 24.
- 25.
- 26. A service meshis decentralized, application-agnostic, networking infrastructure between your services that can be programmed to provide more resilient and observable service to service communication @christianposta Time for definitions:
- 31. Service mesh technologiestypically provide: • Service discovery / Load balancing • Secure service-to-service communication • Traffic control / shaping / shifting • Policy / Intention based access control • Traffic metric collection • Service resilience @christianposta
- 32.
- 33.
- 34. Linkerd2 • Kubernetes specific •Control plane / data plane constructs • Originally introduced in December 2017 as “Conduit” • Collect top-level metrics • Resilience, timeouts, retry budgets • Experimental TLS
- 36.
- 37. Consul Connect • Betastatus • Control plane (consul server) / data plane (proxies/app) • Part of Consul 1.2 release, June 2018 (latest is 1.3) • Secure, mTLS communication • Builds on Consul’s discovery and configuration capabilities • Service segmentation, intention-based ACL policy • Optional use of Envoy Proxy • Native app integration for latency/performance sensitive apps
- 39.
- 40. Istio • Control plane/ data plane (Envoy Proxy) • 1.0 GA July 2018 • Collaboration between Google, IBM, Lyft, VMWare, Red Hat, et al. • Based on Envoy proxy • mTLS, policy based ACL, resilience, observability, traffic control • Kubernetes native • Deployment platform agnostic (experimental)
- 42.
- 43. Thanks! BTW: Hand drawndiagrams made with Paper by FiftyThree.com Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/cepostaFollow up links: • http://blog.christianposta.com • http://istio.io • http://envoyproxy.io • http://linkerd.io • http://consul.io • http://bit.ly/istio-tutorial • http://blog.christianposta.com/istio-workshop/slides/
Editor's Notes
- #2 Service-mesh technology promises to deliver a lot of value to a cloud-native application, but it doesn't come without some hype. In this talk, we'll look at what is a "service mesh", how it compares to similar technology (Netflix OSS, API Management, ESBs, etc) and what options for service mesh exist today.
- #4 How many people are embarking on projects to drive innovation in their organizations? How many people think those projects will succeed? How many people can predict the future? How many people believe their organization’s executives can predict the future?
- #7 …… new challenge….. Let’s come back to that…..
- #8 …… new challenge….. Let’s come back to that…..
- #10 …… new challenge….. Let’s come back to that…..
- #11 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
- #12 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
- #13 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
- #15 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #16 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #17 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #18 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #20 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #21 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #22 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #24 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #25 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #27 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #32 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #33 This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- #34 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #35 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #37 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #38 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #39 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #40 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #41 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #43 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.