The document provides an overview of microservices and service meshes, and uses Istio as an example service mesh implementation. It discusses how Istio allows microservices to be developed independently while providing capabilities like discovery, load balancing, resilience, metrics and tracing through lightweight proxies. The document then demonstrates what happens at each step of a request's lifecycle as it travels through an application protected by Istio's service mesh. Specifically, it shows how Istio components like Pilot, Envoy, Mixer and Citadel work together to provide control, observability and security for microservices.

1. Public usage
Version
0.9999
API &
Service Mesh
Plus microservices tooling

2. Public usage
Version
0.9999
TOC
Overview
Evolution
Microservices
(in a lab)
Microservices
(in wild life)
Hunting microservices
in wild life
Service Mesh
Istio
A day in the life of
Istio
Complete
picture
Lab setup
Demo
(possibly)

3. Overview
We are moving away from a monolith epoch because of cool examples and because of companies and developer
team fractioning and getting more and more dispersed geographically (not to mention opinionated developers).
Microservices is on everybody’s mouth but the fact that Netflix successfully applies it, doesn’t mean it is easy to
implement. This framework also comes with its own challenges, we will see which are those and we’ll examine
tools to help tackle them.

4. Current architecture
evolution
(or involution?)

5. Monolith
MyApp

6. The Application

7. Modules

8. Microservices

9. Microservices

10. Microservices

11. Microservices

12. Network of Services

13. Microservices own their Data

14. Multiple Points of Entry

15. #miniservices
#μservices
…
...
#nanoservices ?
#picoservices ?

16. 1. Deployment Independence - updates to an individual microservice have no
negative impact to any other component of the system. Optimized for
Replacement
2. Organized around business capabilities
3. Products not Projects
4. API Focused
5. Smart endpoints and dumb pipes
6. Decentralized Governance
7. Decentralized Data Management
8. Infrastructure Automation (infrastructure as code)
9. Design for failure
10. Evolutionary Design
Microservices guiding Principles

17. Old School
New School

18. Back to earth

19. OS
JVM
Service C
Microservices == Distributed Computing
OS
JVM
Service B
OS
JVM
Service A

20. • The Network is Reliable
• Latency is zero
• Bandwidth is infinite
• Topology does not change
• There is one administrator
• Transport cost is zero
• The network is homogeneous
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Fallacies of Distributed Computing

21. Failure of a Service
X

22. Cascading Failure
X
X
X
X
X
X
X

23. I see just more nails,
where is the hammer?

24. Microservices embedding capabilities
Container
JVM
Service B
Discovery
Load-balancer
Resiliency
Metrics
Tracing
Container
JVM
Service A
Discovery
Load-balancer
Resiliency
Metrics
Tracing
Container
JVM
Service C
Discovery
Load-balancer
Resiliency
Metrics
Tracing

25. Java Only
Adds a lot of libraries to YOUR code
What's Wrong with Netflix OSS?

26. MyService
Monitoring
Tracing
API
Discovery
Invocation
Resilience
Pipeline
Authentication
Logging Elasticity
Microservices utilities

27. MyService
Monitoring
Tracing
API
Discovery
Invocation
Resilience
Pipeline
Authentication
Logging Elasticity
Microservices utilities + Kubernetes

28. MyService
Monitoring
Tracing
API
Discovery
Invocation
Resilience
Pipeline
Authentication
Logging Elasticity
Microservices utilities + OpenShift

29. Something is missing, right?

30. Why are you showing me
this?

31. Microservices developer: Virtual plumber … ?
Source:
http://peterskastner.wordpress.com/2011/02/23/cisco-the-lion-king-fights-for- data-
center-fabric-leadership/

32. What is a
service
mesh?
A service mesh provides a
transparent and
language-independent
way to flexibly and easily
automate application
network functions.

33. A service mesh is a dedicated infrastructure layer for handling service-to-
service communication. It’s responsible for the reliable delivery of requests
through the complex topology of services that comprise a modern, cloud
native application. In practice, the service mesh is typically implemented as
an array of lightweight network proxies that are deployed alongside
application code, without the application needing to be aware
https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
Service Mesh defined

34. Separate
applications from
infrastructure

35. Distributed
world
The trends of containerization, microservices
and hybrid/multi-cloud deployments have
created more distributed applications than ever.
Developers, devops and secops personnel need
modern tools to secure, manage and monitor
distributed applications.

36. Decouple operations from
development
Separation of concerns

37. Ok, so then what’s Istio?

38. What Is Istio?
An open services platform to manage
service interactions across container-
and VM-based workloads

39. Istio Value Proposition
Observability
Control
Security

40. Istio Observability
● Transparently collect golden signals (traffic, error rates, latency)
● Monitor uniform service level indicators for every service
● Collect logs and traces for deep understanding of service behavior
● Clearly map service interdependencies
● Improved understanding of applications at the service (not
network) level

41. Istio Control
● Change retry, circuit-breaking and routing behavior without changing
code
● Roll out new versions to canary without worrying about ops
challenges
● Apply access control and rate limiting policies to protect services
from bad behavior

42. Istio Security
● Secure by default - new and existing applications.
● Meet compliance obligations by encrypting data in transit.
● mTLS assures a secure, proven service-based identity for every call
● With strong identity, authorization can be explicitly required

43. Istio Architecture
Pilot: Control plane to configure and push service
communication policies.
Envoy: Network proxy to intercept communication
and apply policies.
Mixer: Policy enforcement with a flexible plugin model
for providers for a policy.
Citadel: Service-to-service auth[n,z] using mutual TLS,
with built-in identity and credential management.
Control Plane API
Mixer
Service A Service B
proxy proxy
HTTP/1.1,
HTTP/2, gRPC or
TCP -- with or
without mTLS
Pilot Citadel
Config data
to Envoys
TLS certs to
Envoys
Policy checks,
telemetry

44. What’s the life of a
request like in the Mesh?

45. Life of a request in the mesh
Service A comes up. Envoy is deployed with it and
fetches service information, routing and
configuration policy from Pilot. If Citadel is being
used, TLS certs are securely distributed as well.
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Routing and
load
balancing
config to
Envoys
TLS certs to
Envoys

46. Life of a request in the mesh
Service A places a call to service B.
Client-side Envoy intercepts the call.
Envoy consults config to know how/where to route
call to service B (including any dynamic routing
rules).
Mixer
Service A Service B
proxy proxy
Pilot Citadel

47. Life of a request in the mesh
Envoy forwards request to appropriate instance of
service B. There, the Envoy proxy deployed with the
service intercepts the call.
Mixer
Service A Service B
proxy proxy
Pilot Citadel
HTTP/1.1,
HTTP/2, gRPC or
TCP -- with or
without mTLS

48. Life of a request in the mesh
Server-side Envoy checks with Mixer to validate that
call should be allowed (ACL check, quota check,
etc).
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Policy checks,
telemetry

49. Life of a request in the mesh
Mixer checks with appropriate adaptors (policy
engine, quota adaptor) to verify that the call can
proceed and returns true/false to Envoy
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Policy checks,
telemetryPolicyEngine
Quota
Adapter

50. Life of a request in the mesh
Server-side Envoy forwards request to service B,
which process request and returns response
Mixer
Service A Service B
proxy proxy
Pilot Citadel

51. Life of a request in the mesh
Envoy forwards response to the original caller, where
response is intercepted by Envoy on the caller side.
Mixer
Service A Service B
proxy proxy
Pilot Citadel

52. Life of a request in the mesh
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Logging
adapter
Monitoring
adapter
Envoy reports telemetry to Mixer, which in turn
notifies appropriate plugins

53. Life of a request in the mesh
Client-side Envoy forwards response to original
caller.
Mixer
Service A Service B
proxy proxy
Pilot Citadel

54. Life of a request in the mesh
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Logging
plugin
Monitoring
plugin
Client-side Envoy reports telemetry to Mixer
(including client-perceived latency), which in turn
notifies appropriate plugins

55. Completing the puzzle

56. MyService
Monitoring
Tracing
API
Discovery
Invocation
Resilience
Pipeline
Authentication
Logging Elasticity
Microservices utilities + Istio

57. Microservices embedding Capabilities
Container
JVM
Service B
Discovery
Load-balancer
Resiliency
Metrics
Tracing
Container
JVM
Service A
Discovery
Load-balancer
Resiliency
Metrics
Tracing
Container
JVM
Service C
Discovery
Load-balancer
Resiliency
Metrics
Tracing
Before Istio

58. Microservices externalizing Capabilities
Pod
Container
JVM
Service A
Sidecar Container
Pod
Container
JVM
Service C
Sidecar Container
Pod
Container
JVM
Service B
Sidecar Container
After Istio

59. Microservices externalizing Capabilities
Pod
Container
JVM
Service A
Sidecar Container
Pod
Container
JVM
Service C
Sidecar Container
Pod
Container
JVM
Service B
Sidecar Container
After IstioThe sidecar intercepts all network traffic

60. https://www.imz-ural.com/blog/waffles-the-sidecar-dog
Sidecar

61. Back to the lab

62. Setting up an Istio demo
You can find the setup instructions here:
http://bit.ly/2GaRXhs
Picked up from
https://maistra.io/docs/custom-install/

63. Short break to allow to download the internet
0
1
Just some random cliparts ...
0
2
… to make sure everybody is
working ...
0
3
… if you are reading this, it means
you are done!

64. Installing a demo application environment
You can find the setup instructions here:
http://bit.ly/2TxpKUU
Picked up from
https://maistra.io/docs/bookinfo/

65. What is BookInfo anyway?
Sample application composed of four separate microservices used to demonstrate various Istio
features. The application displays information about a book, similar to a single catalog entry of an
online book store.
The Bookinfo application is broken into four separate microservices:
1. productpage. The productpage microservice calls the details and reviews microservices to
populate the page.
2. details. The details microservice contains book information.
3. reviews. The reviews microservice contains book reviews. It also calls the ratings
microservice.
4. ratings. The ratings microservice contains book ranking information that accompanies a
book review.

66. What is BookInfo anyway?
There are 3 versions of the reviews microservice:
1. Version v1 doesn’t call the ratings service.
2. Version v2 calls the ratings service, and displays each rating as 1 to 5 black stars.
3. Version v3 calls the ratings service, and displays each rating as 1 to 5 red stars.

67. What is BookInfo anyway?

68. Making good use of everything we installed
Let’s put the service mesh to work!
There are 4 main areas we will explore:
Traffic management
Policies
Security
Telemetry

69. If you wanna cheat
http://bit.ly/2DWquhb

70. Traffic management
Route based on user identity
Let’s change the route configuration so that all traffic from a specific user is routed to a specific service
version. In this case, all traffic from a user named Jason will be routed to the service reviews:v2.
Note that Istio doesn’t have any special, built-in understanding of user identity. This example is enabled by
the fact that the productpage service adds a custom end-user header to all outbound HTTP requests to the
reviews service.

71. Traffic management
http://bit.ly/2DUOotd

72. Q&A

73. Extra: Istio adapters
https://istio.io/docs/reference/config/policy-
and-telemetry/adapters/

74. Thank you.
(I know today is El Clasico so extra thank you!)
See you soon!