Evolution of integration and microservices patterns with service mesh
Download as PPTX, PDF16 likes2,564 views
The document discusses the evolution of integration and microservice patterns within a service mesh, emphasizing the complexity of distributed systems and the importance of application safety and correctness. It introduces tools like Envoy and Istio for managing microservices communication, including features like service discovery, load balancing, and traffic management. The content highlights how service meshes offer resiliency, security, observability, and routing control, aiming to improve application networking infrastructure.
Evolution of integration and microservices patterns with service mesh
- 1. Evolution of integration and microservice patterns with 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â and âIntroducing Istio Service Meshâ âą Committer/contributor lots of open-source projects âą Blogger, speaker, mentor, leader
- 4. @christianposta Innovation is admitting we donât have all the answers Mark Schwartz â Former CIO USCIS
- 5. @christianposta Traditional user story ârequirementsâ âą As AâŠ. <role> âą I Want⊠<goal/desire> âą So That⊠<receive benefit> https://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/
- 6. @christianposta Scientific method anyone? âą Make observations âą Formulate hypothesis âą Design an experiment âą State the indicators you will evaluate âą Conduct the experiment âą Evaluate results âą Accept or reject hypothesis âą Make new hypothesis and continueâŠ
- 7. @christianposta Asking questions instead of requirements https://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/
- 9. @christianposta Application safety and correctness in a distributed system is the responsibility of the application.
- 10. @christianposta The end-to-end principle: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)
- 11. @christianposta
- 12. TCP adds reliable communication @christianposta
- 13. As we move to services architectures, we push the complexity to the space between our services. @christianposta
- 14. @christianposta
- 15. @christianposta
- 16. @christianposta
- 17. @christianposta
- 18. âą Orchestrate calls across multiple microservices âą Aggregate, combine, transform, split, on âmessagesâ âą Deal with atomicity / consistency issues âą Message idempotency / message de-dupe âą DDD anti-corruption layers / adapters / transformation âą Tie in with existing âbackend systemsâ âą Dynamic, responsive, programmable routing Application communication (app specific) @christianposta
- 19. âą Service discovery âą Retries âą Timeouts âą Load balancing âą Rate limiting âą Thread bulk heading âą Circuit breaking @christianposta Application networking (reliability)
- 20. Application networking (controlled deployment) âą Edge/DMZ routing âą Surgical / fine / per-request routing âą A/B rollout âą Traffic shaping âą Internal releases / dark launches âą Request shadowing âą Fault injection @christianposta
- 21. âą adaptive, zone-aware âą Deadlines âą Health checking âą Stats, metric, collection âą Logging âą Distributed tracing âą Security @christianposta Application networking (observability)
- 24. âą 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
- 26. 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
- 27. But Iâm using Vert.x! âą vertx-circuit-breaker âą vertx-service-discovery âą vertx-dropwizard-metrics âą vertx-zipkin? âą âŠ.. âą ...... @christianposta
- 28. Screw Java - Iâm using NodeJS! JavaScript is for rookies, I use Go! But python is so pretty! I prefer unreadability⊠Perl for me! @christianposta
- 29. âą 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 âą Inconsistent implementations âą Incorrect implementations Some drawbacks to this approach? @christianposta
- 30. In practice, operability of our services becomes a top priority very fast @christianposta
- 33. Envoy is⊠⹠service proxy ⹠written in C++, highly parallel, non-blocking ⹠L3/4 network filter ⹠out of the box L7 filters ⹠HTTP 2, including gRPC ⹠baked in service discovery/health checking ⹠advanced load balancing ⹠stats, metrics, tracing ⹠dynamic configuration through xDS
- 34. Envoy implements âą zone aware, least request load balancing âą circuit breaking âą outlier detection âą retries, retry policies âą timeout (including budgets) âą traffic shadowing âą rate limiting âą access logging, statistics collection âą Many other features!
- 35. @christianposta
- 36. Meet Istio.io http://istio.io A control plane for service proxies
- 38. As a service-instance proxy @christianposta
- 39. A service mesh is decentralized application- networking infrastructure between your services that provides resiliency, security, observability, and routing control. A service mesh is comprised of a data plane and control plane. @christianposta Time for definitions:
- 42. What higher-order clusters semantics does Istio enable? âą Request-level control âą Graduated deployment and release âą Service observability âą Cluster reliability âą Chaos testing âą Policy enforcement
- 43. Resilience with timeouts, retries, budgets, circuit breakers, service discovery, etc @christianposta
- 44. Zone aware, sophisticated client-side load balancing @christianposta
- 45. Fine-grained traffic control and routing @christianposta
- 47. Secure transport with mTLS @christianposta
- 48. Metrics, logs, distributed tracing out of the box http://bit.ly/application-networking
- 51. Thanks! BTW: Hand drawn diagrams 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://launch.openshift.io âą http://istio.io âą http://envoyproxy.io âą http://developers.redhat.com/blog âą http://blog.christianposta.com/istio-workshop/slides/ âą http://blog.openshift.com âą https://www.redhat.com/en/open-innovation-labs
Editor's Notes
- #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?
- #5: Inherently unknownâŠ.
- #10: âŠâŠ new challengeâŠ.. Letâs come back to thatâŠ..
- #11: âŠâŠ new challengeâŠ.. Letâs come back to thatâŠ..
- #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: 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
- #16: 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
- #17: 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
- #18: 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
- #19: Apache Camel can enable legacy backends to participate in a REST-based set of services by quickly exposing a REST service interface using its expressive DSL.. The DSL plugins right into the rest of the Apache Camel DSL allowing you to quickly expose a REST endpoint that can describe an API as well as integrate with backend services by mediating, routing, transforming and otherwise changing the shape of data or even content of a payload with enricher, resequence, and recipient list patterns.
- #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: 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.
- #27: 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.
- #28: 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.
- #29: Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #32: 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
- #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.
- #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.
- #43: Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- #51: Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.