Service Mesh -Microservices

What is Service Mesh & Why we need ?

Service mesh is an application that provides many services in the world of Microservices. Before we looking at the services that provided by Service Mesh, let us talk about what are the challenges?. When we move from Monolithic to Microservices we introduce many independently developed and deployable services with following challenges which we did not have when we are running monolithic app.

1.Service to Service Communication ( Endpoint URL need to know : When service A calls B)

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

Each microservices should have above mentioned logics / functionality added or backed into part of the application code to service a run successfully and when developers are working on Application /Business Logic they also need to add these complexity into their application. What if I say there is a Service or Tool which will offload these tasks from main application and makes developers to concentrate on only BL ( Business Logic ). Here comes a service or tool called Service Mesh.

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

Mostly all microservices workloads are deployed into Kubernetes(K8s) as a POD . POD is unit of deployment in K8s world. POD = Container Runtime(docker) + Application + Sidecar ( optional).
The below POD has Microservice as main and ISTIO envoy PROXY running as sidecar to take care the above mentioned cross cutting functionality

There are 3 service mesh applications ISTIO , Open Mesh and Linkerd among these three ISTIO is most popular one. ISTIO can be deployed in to AKS cluster and whenever any POD launched or created automatically ISTIO sidecar can be injected to take care of the cross cutting concerns .

ISTIO Architecture

Envoy : Envoy sidecar proxies serve as Istio’s data plane. Built -in features such as failure handling (for example, health checks and bounded retries), dynamic service discovery, and load balancing make Envoy a powerful tool. Envoy also provides information about service requests through attributes.
Mixer : Istio’s policy and telemetry hub gathers Envoy attributes about service requests within the mesh, and provides an API so DevOps teams can build plugins (or adapters) to repurpose those attributes within any number of third-party backends, including logging, authorization, or monitoring tools — such as New Relic (more on this 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. As with Mixer, you can include adapters so Pilot can communicate via API with your Kubernetes infrastructure about deployment
changes affecting 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.

Please refer the following URL for more Info https://istio.io/latest/docs/ops/deployment/architecture/
ISTIO PROXY has the following built in features

1. Dynamic service discovery
2. Load balancing
3. TLS termination
4. HTTP/2 and gRPC proxies
5. Circuit breakers
6. Health checks
7. Staged rollouts with %-based traffic split
8. Fault injection
9. Rich metrics

Thanks
Sreeni Ramadurai