Downloaded 84 times
Uploaded byChristian Posta
Evolution of integration and microservices patterns with service mesh
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.
SoftwareâŚ
More Related Content
Similar to Evolution of integration and microservices patterns with service mesh
![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)
Evolution of integration and microservices patterns with service mesh
- 1. Evolution of integrationand 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 admittingwe 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 insteadof requirements https://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/
- 8.
- 9. @christianposta Application safety andcorrectness 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 Thefunction 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.
- 12. TCP adds reliablecommunication @christianposta
- 13. As we moveto services architectures, we push the complexity to the space between our services. @christianposta
- 14.
- 15.
- 16.
- 17.
- 18. ⢠Orchestrate callsacross 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 (controlleddeployment) ⢠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
- 25.
- 26. 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
- 27. But Iâm usingVert.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 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
- 30. In practice, operabilityof our services becomes a top priority very fast @christianposta
- 32.
- 33. Envoy is⌠⢠serviceproxy ⢠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 ⢠zoneaware, 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.
- 36. Meet Istio.io http://istio.io A controlplane for service proxies
- 38. As a service-instanceproxy @christianposta
- 39. A service meshis 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 clusterssemantics 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-sideload balancing @christianposta
- 45. Fine-grained traffic controland routing @christianposta
- 46.
- 47. Secure transport withmTLS @christianposta
- 48. Metrics, logs, distributedtracing out of the box http://bit.ly/application-networking
- 50.
- 51. 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://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.