Service Mesh – Microservices – DEV Community

What is Service Mesh and why do we need it?

Service mesh is an application that provides many services in the world of Microservices. Before we look at the services provided by Service Mesh, let’s talk about what are the challenges. When we go from Monolithic to Microservices, we introduce many independently developed and deployable services with the following challenges that we didn’t have when we were running a monolithic app.

1. Service to service communication (endpoint URL must be known: when service calls AB)

1. mTLS Secure communication between microservices. 3. Retry logic (when transient errors occur)
2. Distributed tracing (end-to-end call flow)
3. Logging, Metrics

Every microservice needs to have the above mentioned logic/functionality added or supported in some part of the application code to serve a run successfully and when developers are working on application/business logic they also need to add this complexity to their application. What if I say there is a service or tool which offloads these tasks from the main application and makes sure that developers focus only on BL (business logic)? This is where a service or tool called Service Mesh comes in.

ISTIO is an open-source service mesh application. It helps manage communication between microservices, by adding observability, security, and reliability features to the application by embedding these features at the platform layer instead of the application layer.
Service mesh is typically implemented as a scalable set of network proxies that are deployed alongside application code (a pattern sometimes called a sidecar). These proxies handle communication between the microservices and also act as a point at which service mesh features can be introduced.

Most microservices workloads are deployed in Kubernetes (K8s) as a POD. POD is a deployment unit in the K8s world. POD = Container Runtime (docker) + Application + Sidecar (optional).
The POD below has Microservice as main and ISTIO Envoy PROXY as sidecar to provide the cross-cutting functionality mentioned above

There are 3 service mesh applications: ISTIO, Open Mesh and Linkerd. Of these three, ISTIO is the most popular. ISTIO can be deployed in an AKS cluster and when a POD is automatically started or created, the ISTIO sidecar can be injected to solve the cross-cutting issues.

ISTIO architecture

Envoy: Envoy sidecar proxies serve as Istio’s data plane. Built-in features like failure handling (e.g. health checks and bounded retries), dynamic service discovery, and load balancing make Envoy a powerful tool. Envoy also provides service request intelligence via attributes.
Mixer: Istio’s policy and telemetry hub collects Envoy attributes about service requests across the mesh, and provides an API so DevOps teams can build plugins (or adapters) to reuse those attributes across any number of third-party backends, including logging, authorization, or monitoring tools like New Relic (more on that below). Mixer also handles authorization between proxies using mutual TLS.
Pilot: Istio uses Pilot to manage load balancing traffic controls based on your Envoy configurations. Similar to Mixer, you can add adapters so Pilot can communicate with your Kubernetes infrastructure via API over deployment
changes that affect traffic. Pilot also distributes authentication rules to proxies.
Citadel: With Citadel, Istio provides a robust, policy-driven security layer for authentication and credential management between Envoy proxies. Citadel manages keys and certifications across the mesh.

For more information, please refer to the following URL: https://istio.io/latest/docs/ops/deployment/architecture/
ISTIO PROXY has the following built-in features

1. Dynamic service discovery
2. Load distribution
3. TLS Termination
4. HTTP/2 and gRPC proxies
5. Circuit breakers
6. Health checks
7. Phased rollout with % based traffic distribution
8. Fault injection
9. Rich statistics

Thank you
Sreeni Ramadurai