Service Mesh for micro services.

1. Service Mesh
Make Microservices great again

2. What happened when we first started with microservices

3. “The 8 Fallacies of Distributed Computing”
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

5. Next Logical Step- Sidecar

6. The Service Mesh
In such model, each of your services will have a companion proxy sidecar. Given that services communicate with each
other only through the sidecar proxy, we end up with a deployment similar to the diagram below:

7. Another type of service mesh -One with a
Control Plane-Istio

8. What is a Service Mesh
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. (But there are variations to this idea, as we’ll see.)

9. Why Service Mesh
● Discovery
● Load balancing
● Failure recovery
● Metrics
● Monitoring and often more complex operational requirements such as A/B testing
● Canary releases
● Rate limiting
● Access control
● End-to-end authentication

10. What Service Mesh Provides
● Traffic Management. Control the flow of traffic and API calls between services, make calls more reliable, and
make the network more robust in the face of adverse conditions.
● Observability. Gain understanding of the dependencies between services and the nature and flow of traffic
between them, providing the ability to quickly identify issues.
● Policy Enforcement. Apply organizational policy to the interaction between services, ensure access policies
are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring
the mesh, not by changing application code.
● Service Identity and Security. Provide services in the mesh with a verifiable identity and provide the ability to
protect service traffic as it flows over networks of varying degrees of trustability.

11. Is a Service Mesh a Networking Layer
● The service mesh is a networking model that sits at a layer of abstraction above TCP/IP. It assumes that the
underlying L3/L4 network is present and capable of delivering bytes from point to point. (It also assumes that this
network, as with every other aspect of the environment, is unreliable; the service mesh must therefore also be
capable of handling network failures.)
● In some ways, the service mesh is analogous to TCP/IP. Just as the TCP stack abstracts the mechanics of reliably
delivering bytes between network endpoints, the service mesh abstracts the mechanics of reliably delivering requests
between services. Like TCP, the service mesh doesn’t care about the actual payload or how it’s encoded. The
application has a high-level goal (“send something from A to B”), and the job of the service mesh, like that of TCP, is
to accomplish this goal while handling any failures along the way.

12. Popular Service Meshes
● Linkerd
● Istio
Linkerd
Linkerd is an open source service mesh by Buoyant developed primarily using Finagle and netty. It can run on Kubernetes,
DC/OS and also a simple set of machines.
Linkerd service mesh, offers a number of features like:
● Load Balancing
● Circuit Breaking
● Retries and Deadlines
● Request Routing
It instruments top line service metrics like Request Volume, Success Rates and Latency Distribution. With its Dynamic
Request Routing, it enables Staging Services, Canaries, Blue Green Deploys with minimal configuration with a powerful
language called DTABs.

13. Istio
Istio (Greek for Sail) is an open platform sponsored by IBM, Google and Lyft that provides a uniform way to connect,
secure, manage and monitor Microservices. It supports Traffic Shaping between micro services while providing rich
telemetry.
Of note:
● Fine grained control of traffic behavior with routing rules, retires, failover and fault injection
● Access Control, Rate Limits and Quota provisioning
● Metrics and Telemetry
At this point, Istio currently supports only Kubernetes An Istio service mesh can be considered of logically consisting of:
● A Data Plane of Envoy Sidecars that mediate all traffic between services
● A Control Plane whose purpose is to manage and configure proxies to route and enforce traffic policies.

14. Service Mesh(Istio)

15. Deploying Linkerd
https://linkerd.io/advanced/deployment/