Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Evolution of integration and microservices patterns with service mesh


Published on

Cloud-native describes a way of building applications on a cloud platform to iteratively discover and deliver business value. We now have access to a lot of similar technology that the large internet companies pioneered and used to their advantage to dominate their respective markets. What challenges arise when we start building applications to take advantage of this new technology?

In this mini-conference, we'll cover what it means to build applications with microservices, how cloud-native integration and concepts like service mesh have evolved to solve some of those problems, and how the next iteration of application development with Functions as a Service (FaaS) and serverless computing fit into this landscape.

You'll hear from industry experts Burr Sutter and Christian Posta who recently authored a book Introducing Istio Service Mesh for Microservices about these topics.

Attendees should come away from this mini-conference with the following:

Understanding of what cloud-native means and how to use it to influence positive business outcomes
How integration has evolved to create, connect and manage cloud-native APIs
How service-mesh technology like Istio can solve the challenges introduced with cloud-native applications
How the next iteration of applications deliver with FaaS and serverless computing fits in with a world of monoliths, microservices, and APIs
These talks will be of value for developers, architects, operators, platform directors, and technology leaders.

After the presentations, please stay and join Christian, Burr and your peers for networking, food and drinks. All attendees will also receive a copy of Christian and Burr's new book: Introducing Istio Service Mesh for Microservices.

Published in: Software

Evolution of integration and microservices patterns with service mesh

  1. 1. Evolution of integration and microservice patterns with service mesh @christianposta
  2. 2. Christian Posta Chief Architect, cloud application development Twitter: @christianposta Blog: Email: Slides: • Author “Microservices for Java developers” and “Introducing Istio Service Mesh” • Committer/contributor lots of open-source projects • Blogger, speaker, mentor, leader
  3. 3. @christianposta Innovation is admitting we don’t have all the answers Mark Schwartz – Former CIO USCIS
  4. 4. @christianposta Traditional user story “requirements” • As A…. <role> • I Want… <goal/desire> • So That… <receive benefit>
  5. 5. @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…
  6. 6. @christianposta Asking questions instead of requirements
  7. 7. @christianposta
  8. 8. @christianposta Application safety and correctness in a distributed system is the responsibility of the application.
  9. 9. @christianposta The end-to-end principle: 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.)
  10. 10. @christianposta
  11. 11. TCP adds reliable communication @christianposta
  12. 12. As we move to services architectures, we push the complexity to the space between our services. @christianposta
  13. 13. @christianposta
  14. 14. @christianposta
  15. 15. @christianposta
  16. 16. @christianposta
  17. 17. • 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
  18. 18. • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking @christianposta Application networking (reliability)
  19. 19. 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
  20. 20. • adaptive, zone-aware • Deadlines • Health checking • Stats, metric, collection • Logging • Distributed tracing • Security @christianposta Application networking (observability)
  21. 21. • 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
  22. 22.
  23. 23. 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
  24. 24. But I’m using Vert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ...... @christianposta
  25. 25. 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
  26. 26. • 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
  27. 27. In practice, operability of our services becomes a top priority very fast @christianposta
  28. 28. Meet Envoy Proxy
  29. 29. 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
  30. 30. 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!
  31. 31. @christianposta
  32. 32. Meet A control plane for service proxies
  33. 33. As a service-instance proxy @christianposta
  34. 34. 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:
  35. 35. What higher-order clusters semantics does Istio enable? • Request-level control • Graduated deployment and release • Service observability • Cluster reliability • Chaos testing • Policy enforcement
  36. 36. Resilience with timeouts, retries, budgets, circuit breakers, service discovery, etc @christianposta
  37. 37. Zone aware, sophisticated client-side load balancing @christianposta
  38. 38. Fine-grained traffic control and routing @christianposta
  39. 39. Traffic shadowing @christianposta
  40. 40. Secure transport with mTLS @christianposta
  41. 41. Metrics, logs, distributed tracing out of the box
  42. 42. Demo!
  43. 43. Thanks! BTW: Hand drawn diagrams made with Paper by  Twitter: @christianposta Blog: Email: Slides: up links: • • • • • • •