What is a service mesh and why we need Service Mesh?
Service Mesh is the infrastructure layer which allows to manage communication between micro-services. It provides an additional for application Microservice which will handle all non-functional activities like load balancing, security, Service Discovery, trace-ability, Circuit breaker pattern, it also provides centralized communication dashboard for services, health of the services.
Microservices: Microservice architecture enables way to deploy the services without impacting the other services. As using this approach, we will not deploy whole application once, instead we will split the monolithic application into smaller independent applications and deploy these smaller components. With this approach smaller application can be developed using any language, it can be updates independently, and easily scalable to any level.
Why we need Service Mesh:
- Efficient Communication between Services
- Capable of handling Network Failures using Circuit Breaker, Retry logic.
- Micro services Administration
- It abstracts the sending and receiving the request/response between any numbers of services.
- Provide telemetry info from proxy containers.
- End-to-end request tracing.
Service Mesh Architecture:
Service Mesh will connect to any number of Micro services, written in any language, exposing some rest endpoints. When consumers of these rest endpoints will call these endpoints, an API Gateway is added in front this service, which handle request, based on rules we configured it will route the request to service.
Service Mesh adds new functionality to app`s run-time environment, there will be some rules in each Microservice how serviceA will communicate with serviceB.
For communication between services, service mesh provides a proxy, like
front controller design pattern. These proxies are similar enterprise IT
proxies, where a request and response will be interpreted by proxy.
These service proxies will contain the information like authentication, authorization, ACL, routing rules, telemetry data (data sent for monitoring tools such as Prometheus) etc. these proxies will hide the communication between services, these proxies need to deploy along with service.
Envoy is an open source edge and service proxy for cloud native applications, which will be used mostly in-service mesh, which will support for majority used protocols like HTTP/1.1, HTTP/2, and gRPC protocols.
Service Layer consists of two layers:
- Business Logic: It implements the business functionalities, computation logic, integration logic applied between services.
- Network Functions: It will take care inter-service communication between services using service discovery, service invocation through a given protocol, resiliency etc.
Without using service mesh, we need to specify the ip-address of another service in service, the problem with this approach if we are using docker containers where ip-address of the container will change every time, if we restart the container, to overcome these types of situation we need the mapping between service and ipaddress of the host, which has to update dynamically, whenever a service is added, removed/ scaled-in/scaled-out of the service. Service Discovery is the one which maintains these mappings.
Whenever a serviceA, want to communicate with serviceB, then sericea will made a request to LoadBalancer, it internally call the service registry to get details, routes the request to serviceB instance based on algorithm (request handling). Service instances are registered and de-registered dynamically with service Registry.
Example: Kubernetes, one of the orchestration tools, will provide service Registry, when we create a service, all remaining services instances are available as environment variables.
How Service Mesh Works:
ServiceMesh provides a collection of proxies along with containers in kubernetes pod. Each proxy will act as gateway for interactions between kubernetes/docker containers. These proxies forward the request to load balancer through Service registry to get the target service container which will serve the request.
Control Panel orchestrate the connections between services, it will monitor all communications like requests/response between proxies, and it will collect metrics from each container proxy for telemetric observation.
Approaches to Service Mesh:
Proxy for each application instance/replica is implemented by popular service Mesh like Istio and Linkred.
Characteristics of Service Mesh Architecture:
- Managing/ administrating all services.
- Canary/full deployment of services
- Transparent communication between Services.
- Distributed tracing of requests, which help in debugging chain of microservices.
- Troubleshooting request between microservices.
Conclusion: Service Mesh is the way to implement communication between services, and monitoring, tracing the request in an easier way. Each Micro service is the independent component, which is will not depend directly. Istio and Linkred are most used implementations of service mesh approach.
Read more -