Building useful services across our collection of existing applications, microservices, and now functions, we see a common theme: services must be able to communicate with each other, and solve problems like data mediation, routing, policy enforcement, security, and others. Service mesh is a technology that has emerged in container-based environments to help solve some of these problems; however, not all of them can be solved by pushing the problems to a different abstraction. Understanding the role and responsibility of service mesh and application-integration frameworks can help you successfully build useful business services on a cloud native platform. This talk will help you understand those roles and responsibilities and how service mesh and application integration co-exist to build cloud native applications.

1. Role of Integration and Service Mesh
in Cloud-Native Architecture
@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

3. https://www.manning.com/books/istio-in-action

5. @christianposta
Innovation is admitting we don’t
have all the answers
Mark Schwartz – Former CIO USCIS

6. @christianposta
https://puppet.com/resources/whitepaper/state-of-devops-report

7. @christianposta
Application safety and correctness in a
distributed system is the responsibility of
the application teams.

8. @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.)

9. @christianposta

10. TCP adds reliable communication
@christianposta

11. As we move to services architectures,
we push the complexity to the space
between our services.
@christianposta

12. @christianposta

13. @christianposta

14. @christianposta

15. @christianposta

16. • 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 integration (done in the app)
@christianposta

17. • Service discovery
• Retries
• Timeouts
• Load balancing
• Rate limiting
• Thread bulk heading
• Circuit breaking
@christianposta
Application networking (in the app? outside?)

18. 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

19. • adaptive, zone-aware
• Deadlines
• Health checking
• Stats, metric, collection
• Logging
• Distributed tracing
• Security
@christianposta
Application networking (observability)

22. • 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

23. http://bit.ly/application-networking@christianposta

24. 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

25. But I’m using Vert.x!
• vertx-circuit-breaker
• vertx-service-discovery
• vertx-dropwizard-metrics
• vertx-zipkin?
• …..
• ......
@christianposta

26. 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

27. • 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

28. In practice, operability of our services
becomes a top priority very fast
@christianposta

29. Let’s optimize for operability
@christianposta

31. Meet Envoy Proxy
http://envoyproxy.io

32. 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

33. 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!

34. @christianposta

35. As a service-instance proxy
@christianposta

36. Service instance proxy AKA
Sidecar
@christianposta

38. A service mesh is a distributed application infrastructure
that is responsible for handling network trafIic on behalf
of the application in a transparent, out of process manner.
A service mesh helps to solve problems related to
resiliency, security, observability, and routing control.
@christianposta
Time for deIinitions:

39. Service mesh technologies typically provide:
• Service discovery / Load balancing
• Secure service-to-service communication
• Traffic control / shaping / shifting
• Policy / Intention based access control
• Traffic metric collection
• Service resilience
@christianposta

45. Meet Istio.io
http://istio.io
A control plane for service proxies

47. What higher-order clusters semantics
does Istio enable?
• Request-level control
• Graduated deployment and release
• Service observability
• Cluster reliability
• Chaos testing
• Policy enforcement

48. Resilience with timeouts, retries, budgets,
circuit breakers, service discovery, etc
@christianposta

49. Zone aware, sophisticated
client-side load balancing
@christianposta

50. Fine-grained trafIic control and routing
@christianposta

51. http://bit.ly/application-networking
TrafIic shadowing
@christianposta

52. Secure transport with mTLS
@christianposta

53. Metrics, logs, distributed tracing out of the box
http://bit.ly/application-networking

54. Istio and service mesh don’t allow
you to offload responsibility to the
infrastructure; they just add some level
of reliability and optimize for operability
@christianposta

56. Demo!
http://bit.ly/istio-tutorial

57. 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