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.
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.
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
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
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
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.
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
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
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
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.
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
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.
74. Thank you.
(I know today is El Clasico so extra thank you!)
See you soon!
Hinweis der Redaktion
Okey. I am a developer. What do I need ?
How can I connect microservices ?
Where do I know all microservices available ?
How are going to be configured and by whom ? At which level ? Infrastructure / Business ?
Now I need to protect the logic of my service with more:
“What happens if a microservice call
Is slow ?
Is not available ?
Fails ?
Do I need to add more and more try/catch blocks in my code ?
Who will orchestrate all of this ?
Not just a service mesh, but a service mesh with published APIs for every interaction, allowing integration at any point.
Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement and telemetry recording/reporting functions.