Downloaded 70 times
Uploaded byChristian Posta
An evolution of application networking: service mesh
The document discusses the evolution of application networking, focusing on service mesh and microservices architecture. It outlines the complexity introduced by services and emphasizes the need for solutions for distributed systems, including service discovery and load balancing. Christian Posta introduces Envoy Proxy and Istio Service Mesh as tools to address these challenges, enabling a consistent approach across heterogeneous architectures.
An evolution of application networking: service mesh
- 1. An evolution ofapplication networking: service mesh @christianposta
- 2. Christian Posta Chief Architect,cloud application development Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta • Author “Microservices for Java developers” • Committer on Apache Camel, Apache ActiveMQ, Fabric8, others • Worked with large Microservices, web-scale, unicorn company • Blogger, speaker about DevOps, integration, and microservices
- 4. Microservices is aboutoptimizing… for speed. @christianposta
- 5. • Single, self-contained,autonomous • Isolated and Resilient to faults • Faster software delivery • Own their own data • Easier to understand individually • Scalability • Right technology for the problem • Test individual services • Individual deployments Microservices? @christianposta
- 6.
- 7. As we moveto services architectures, we push the complexity to the space between our services. @christianposta
- 8.
- 9.
- 10. This is nota new problem, right? @christianposta
- 11.
- 12.
- 13.
- 14. • 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 @christianposta
- 15.
- 16. 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
- 17. But I’m usingVert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ......
- 18. But I’m usingNodeJS!
- 19.
- 20.
- 21.
- 22. Things you mustsolve for because… distributed systems • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking
- 23. …continued • Routing betweenservices (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing
- 24. …continued • Edge/DMZ routing •Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
- 25. These are allhorizontal concerns and apply to all services regardless of implementation.
- 26. 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
- 27.
- 30. Meet Istio ServiceMesh https://istio.io
- 31. Meet Istio ServiceMesh https://istio.io
- 32. Meet Istio ServiceMesh https://istio.io
- 33. Meet Istio ServiceMesh https://istio.io
- 34. Meet Istio ServiceMesh https://istio.io
- 36. Thanks! BTW: Hand drawndiagrams made with Paper by FiftyThree.com @christianposta Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta Follow up links: • http://openshift.io • http://launch.openshift.io • http://blog.openshift.com • http://developers.redhat.com/blog • https://www.redhat.com/en/open-innovation-labs • https://www.redhat.com/en/technologies/jboss-middleware/3scale • https://www.redhat.com/en/technologies/jboss-middleware/fuse
Editor's Notes
- #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.
- #19 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #20 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #21 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #22 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #23 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.
- #24 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.
- #25 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.
- #26 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.
- #29 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #30 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #31 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 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #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.
- #36 Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.