Microservices and Service Mesh at A Glance

What Is a Service Mesh?

As enterprises are moving from monolithic to microservices/distributed microservices to achieve more resiliency and performance, service mesh has a key role in that kind of digital transformation.

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. Service mesh has mainly two major components — the control plane and the data plane, which decouples the business logic from technical complexities.

Service meshes abstract away how inter-process communications are handled. A service mesh allows you to separate the business logic of the application from observability, and network and security policies. 

Why Choose a Service Mesh?

As all the enterprises are moving towards microservices and cloud-native architectures, it is important to understand and act, when the monolithic legacy systems are broken into multiple services, where you will be having over 1,000+ microservices in place to make your enterprise systems as a whole.

To follow a microservice-based architecture with an API-first approach as well as resiliency and scalability on the other side, you also need service orchestration behind the scene in a distributed nature.

A service mesh is a pattern or solution you can choose for such scenarios where you want to manage and operate with a huge number of microservices. With the distributed nature of application landscape, service discovery and general application composition become extremely complex.

In the context of ESB/APIM for distributed microservices, most of the service orchestration falls on load balancers and the API gateway making them a bottleneck and which leads to a single point of failure.

When these kinds of problems amplify as service distribution span across different clouds (multi-cloud), containers, and on-premise platforms, service mesh becomes more significant.

Service Mesh Allows

• Management of all services, as and when they grow in a number of sizes.
• Provide efficient communication between them.
• Handling of network failures.
• It abstracts the mechanics of reliably delivering requests/responses between any number of services.
• To provide end-to-end performance and reliability.
• It provides a uniform, application-wide point introducing visibility and control into the application runtime.
• Provide telemetry info from proxy containers.

Capabilities and Characteristics of Service Mesh

 

Characteristics of Service Mesh

• Distributed in size.
• Controlled by the control plane.
• Provides all networking such as routing, monitoring through software components (Handled by APIs).
• Decrease operational complexity.
• Provides abstraction layer at the top of Microservices, distributed across various clusters,
• Multi data-centers or Multi-Cloud.
• Decentralized.
• Almost zero latency as the proxies is lightweight.
• Proxy sidecars injected dynamically inside the deployment.

Data Plane and Control Plane

Service mesh data plane: Touches every packet/request in the system. Responsible for service discovery, health checking, routing, load balancing, authentication/authorization, and observability.

Service mesh control plane: Provides policy and configuration for all of the running data planes in the mesh. It does not touch any packets/requests in the system. The control plane turns all of the data planes into a distributed system.

Data plane in service mesh is responsible for: 

Control plane in service mesh is responsible for:

Enterprises are moving from current SOA architecture-as is to MSA/CNA architecture base for future has to think of various aspects, where service mesh will be the best fit, we will see that in the next part like Service in the context of moving from SOA to Microservices, API gateway vs Service Mesh, ESB to ESM approach, etc.