The document discusses the role of integration and service mesh in cloud-native architecture, emphasizing the responsibilities of application teams in ensuring safety and correctness within distributed systems. It highlights the complexities introduced by service architectures and the necessity of application networking for orchestration, observability, and operational priority. The document introduces technologies like Envoy Proxy and Istio, detailing their functions in managing network traffic, enhancing service resilience, and providing secure communications.

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