Service Mesh Quick Notes

What is Service Mesh?

A layer that handles communication operations between microservices.
Provides Monitoring, logging, tracing, and traffic control. Its operational layer between the services.

There are two main reasons for using service mesh.

Service-level Observability. To figure out, how services are interacting with each other. Upstream and Downstream dependency detail.
Service-level Control. Enforcement of how services interact with each other. They can define behavior, policies, and interactions of services.

Benefits

Service Discovery: Uses Service Registry to do so. You don't have to manage service endpoints, and it's a reference that refers to service registry
Load Balancing:
Traffic management: Rules for request routing and traffic behavior.
- Traffic Splitting: Divide incoming traffic into different service versions. Maybe create rules for different countries/locations(geographic rules). Also, may be used for feature rollouts
Request mirroring - This is very interesting use case. Where one can mirror production traffic to get insights how system is handling, it without affecting the original source - say production.
Canary Deployments - Traffic management for subsection to hit the latest greatest deployments.
Security - communicates using mutual Transport Layer Security (mTLS) encryption. Built-in features for authentication and authorization.
- Can control endpoint access specification.
- Can control action specification.
Monitoring - For health, performance, and behavior.
- Metrics like latency, error rates, and resource utilization
- Perform distributed tracing to see requests' complete path and timing across multiple services
- Capture service events in logs for auditing, debugging, and compliance purposes

How does service mesh work?

Abstracts logic of service-to-service communication to its infra layer. External traffic always hits the Proxy server and then the Microservice container. Also, there can be individual proxy next to the Microservice Container - A sidecar pattern.

Service mesh has two main components:

Data Plane: Low-level implementation of communication between services. Includes, all sidecar proxies and thier functions. Sidecar does the following things:
- Request Interception.
- Encapsulation of request.
- Establishing secure connections with other proxies

Sidecar Proxy has capabilities - circuit breaking, and request retries. Load balancing, service discovery, and traffic routing are also implemented in Data Plane*

Control Plane: Implements Central management and configuration layer of service mesh. Features like:
- Service Registry: Defining Service endpoints etc.
- Automatic discovery of new services and removal of inactive services.
- Aggregation of telemetry data - metrics, logs, distributed tracing
- Routing Rules
- Load balancing 'Policies'
- Security settings.

What is ISTIO

It's an implementation of Service Mesh. All the features described above, are implemented by ISTIO. Other players in market are:Linkerd and Consul. Google took the ISTIO project and offered it as Anthos. In the software world, individuals and companies go hand in hand. Sometimes a passionate developer starts a project and other people and companies join them. They give their contributions and sometimes take away their thought process and fork into a different branch. Sometimes companies start offering their rendition as totally separate solutions, befitting to their goals, in this case, Google Anthos would be that example. AWS App Mesh would be Amazon's offering.

Works on existing platform. Basic needs for that will be: Container orchestration platform, networking solutions, and other tools in the tech stack. One can see that doing all these adds a lot of work and complexity to implement a scalable system. Not only that, it adds to the team load.

Next blog reading would be Implementing Envoy, for the proxy needs of a service mesh.

Reading References :