Problem: Fat Microservices:

In a typical microservices architecture, each service should ideally focus on a single responsibility. However, in practice, we often encounter "fat microservices"—services that take on more than just their core business logic.

Take the Book Info application example shown in the image. We have four services:

1. Product Page (Python)

2. Details (Ruby)

3. Reviews (Java)

4. Ratings (NodeJS)

At first glance, each of these services seems independently developed using different languages, which is great for polyglot microservices. However, if we look closer at what's inside each service, they all include:

1. Authentication

2. Authorization

3. Networking

4. Logging

5. Monitoring

6. Tracing

This leads to duplication of effort and bloated microservices, as each service independently implements these non-functional capabilities.

How Service Mesh Helps Here

Definition:

It is a dedicated and configurable infrastructure layer that handles the communication between the services without having to change the code in Microservice architecture.

A Service Mesh (like Istio, Linkerd, or Consul) helps by offloading these repeated functionalities from the microservices into a dedicated infrastructure layer. Let’s break this down with respect to the image:

What a Service Mesh Does:

Sidecar Proxies:

• Each microservice gets a sidecar proxy (like Envoy) injected alongside it.

• The proxy handles networking concerns routing, retries, timeouts, service discovery instead of the service itself.

Centralized Authentication & Authorization:

• Security policies (mTLS, JWT validation, RBAC) are enforced by the mesh, so services don’t need to implement these repeatedly.

Consistent Logging, Monitoring, and Tracing:

• Mesh automatically collects telemetry (metrics, logs, traces) from the sidecar proxies and sends it to observability tools like Prometheus, Grafana, Jaeger, etc.

Responsibilities:

• Traffic Management

• Security

• Observability

• Service Discovery

Istio Service Mesh:

As microservices grow in scale and complexity, managing cross-cutting concerns like traffic control, security, observability, and policy enforcement becomes a massive challenge. Traditionally, each service had to implement these features individually, resulting in bloated or "fat microservices".

This is where a Service Mesh, and more specifically Istio, comes into play. Istio is an Open source Service Mesh which provides an efficient way to secure connect and monitor services.

These proxies and the communication between them from the Data Plane. Istio uses High performance open source proxy called Envoy.

These proxies that talks to the server side component called Control Plane.

Architecture:

Istio introduces a dedicated infrastructure layer that transparently handles many of the operational tasks involved in running distributed applications. The architecture shown in the diagram is divided into two main components:

Control Plane:

The Control Plane is responsible for the management and configuration of the mesh.

• Istiod: The core Istio component that integrates the following:

  • Pilot: Manages service discovery and traffic rules.

  • Citadel: Handles certificates and mTLS (mutual TLS) for secure service-to-service communication.

  • Galley: (deprecated in newer versions) was used for configuration validation and distribution.

• The Control Plane does not directly touch the traffic but pushes configurations to the Data Plane.

Data Plane:

The Data Plane consists of a set of sidecar proxies (Envoy) deployed alongside each service instance. These proxies intercept all network traffic to and from the service and apply policies defined by the control plane.

• Each microservice in the diagram — Product Page (Python), Details (Ruby), Reviews (Java), and Ratings (Node.js) — is paired with:

• Envoy Proxy: Handles all incoming/outgoing traffic.

• Istio Agent: Manages communication with Istiod, certificate rotation, telemetry, and bootstrap of the Envoy proxy.

• Together, they form the Service Mesh, where:

• All communication is encrypted (mTLS).

• Traffic routing (e.g., canary deployments, fault injection) is policy-driven.

• Observability features like logging, metrics, and tracing are built-in.

• Authentication and authorization are centralized and consistent.

Benefits of Istio in This Architecture:

• Service Decoupling: Developers can focus on business logic, offloading networking/security concerns to Istio.

• Zero-Trust Security: Enforces mTLS and fine-grained access controls without modifying application code.

• Observability: Unified telemetry collection without developer intervention.

• Resilient Traffic Management: Retry logic, load balancing, and failover configured via simple YAML files.

Conclusion:

With Istio, you transform fat, self-contained microservices into thin, efficient, and maintainable units that rely on the mesh for everything else. The diagram illustrates how Istio enables a clear separation of concerns a major architectural win for any cloud-native application.