Successfully reported this slideshow.
Your SlideShare is downloading. ×

Atlanta Microservices Day: Istio Service Mesh

Loading in …3
×

Check these out next

1 of 52 Ad
1 of 52 Ad
Advertisement

More Related Content

Similar to Atlanta Microservices Day: Istio Service Mesh (20)

Advertisement
Advertisement

Atlanta Microservices Day: Istio Service Mesh

  1. 1. Microservices: from Netflix OSS to Istio Service Mesh Christian Posta (@christianposta) Senior Principal Solutions Architect
  2. 2. Christian Posta Senior Principal Solutions Architect Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta • Author “Microservices for Java developers” • Committer/contributor lots of open-source projects • Worked with large Microservices, web-scale, unicorn company • Blogger, speaker
  3. 3. Microservices are distributed systems @christianposta
  4. 4. The network… does what it wants. @christianposta
  5. 5. As we move to services architectures, we push the complexity to the space between our services. @christianposta
  6. 6. Have we had to solve for this in the past? @christianposta
  7. 7. http://bit.ly/application-networking@christianposta
  8. 8. http://bit.ly/application-networking@christianposta
  9. 9. http://bit.ly/application-networking@christianposta
  10. 10. Microservices libraries
  11. 11. http://bit.ly/application-networking@christianposta
  12. 12. • 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. 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. But I’m using Vert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ...... @christianposta
  15. 15. 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
  16. 16. Get the point? @christianposta
  17. 17. Things you must solve for because… distributed systems • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking @christianposta
  18. 18. …continued • Routing between services (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing @christianposta
  19. 19. …continued • Edge/DMZ routing • Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
  20. 20. These are all horizontal concerns and apply to all services regardless of implementation. @christianposta
  21. 21. Drawbacks to library approach • need one for each combination language/framework • need to maintain, upgrade, retire • classpath/namespace pollution • increases operational complexity • force specific languages • inconsistency • correctness
  22. 22. Let’s abstract this functionality 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
  23. 23. @christianposta
  24. 24. Evolution of application networking
  25. 25. Meet Envoy Proxy http://envoyproxy.io
  26. 26. 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
  27. 27. @christianposta
  28. 28. 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!
  29. 29. As an edge proxy
  30. 30. As an shared proxy
  31. 31. As a service-instance proxy
  32. 32. Service instance proxy AKA Sidecar
  33. 33. Quick demo? @christianposta https://vimeo.com/252272973
  34. 34. Service mesh
  35. 35. “2018 is the year of the service mesh” Clayton Coleman (@smarterclayton) Red Hat OpenShift Platform Architect @christianposta
  36. 36. How do we reason about a fleet of these service proxies in a large cluster? @christianposta
  37. 37. 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:
  38. 38. All traffic between our applications flows through these proxies. The proxies make up the “data plane” @christianposta
  39. 39. Meet Istio.io http://istio.io A control plane for service proxies
  40. 40. What higher-order clusters semantics does Istio enable? • Service observability • Graduated deployment and release • Policy enforcement • Cluster reliability • Chaos testing
  41. 41. http://bit.ly/like-a-unicorn
  42. 42. Demo! @christianposta https://vimeo.com/252272433
  43. 43. 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://envoyproxy.io • http://istio.io • http://blog.christianposta.com/istio-workshop/slides/ • http://launch.openshift.io • http://blog.openshift.com • http://developers.redhat.com/blog • https://www.redhat.com/en/open-innovation-labs
  44. 44. @christianposta
  45. 45. @christianposta Basic netflix OSS jars take up ~24MB

Editor's Notes

  • https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

    The network is reliable.
    Latency is zero.
    Bandwidth is infinite.
    The network is secure.
    Topology doesn't change.
    There is one administrator.
    Transport cost is zero.
    The network is homogeneous.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

×