Why Istio

In our introduction to Istio Service Mesh, we will cover basic points as below

• What is a Service Mesh ?
• Why do we need Service Mesh ?
• Types of Service Mesh Available and Why Istio ?
• Istio — Architecture & Implementations
• Istio Components
• Istio Features

In any MicroService based architecture, whenever there is a Service call from one microservice to another. We are not able to infer or debug what is happening inside the Networked Service Calls.

This might lead to serious problems when we are not able to diagnose properly what is the problem if unwanted situation arises. For example: Performance issues, Security, Load balancing problems, Tracing the Service calls or Proper Observability of the Service calls.

Severity of the Issue gets multiplied when you have to cater to many microservices for any application to work properly.

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.

There are three leading contenders in the Cluster ecosystem for Service Mesh. All of these solutions are open source.

•Consul Connect: Consul Connect uses an agent installed on every node as a Daemon Set which communicates with the Envoy sidecar proxies that handles routing & forwarding of traffic. It emphasizes service discovery and service identity management. Like Istio, it uses the Envoy proxy and the sidecar pattern.

•Linkerd : Linkerd is designed to be a lightweight service mesh that can be placed on top of any existing platform. It has very simple installation and CLI tools and doesn’t require a platform admin to be used. It uses RUST as a Proxy. It works with Kubernetes only.

• Istio: Istio is a Kubernetes-native solution that was initially released by Lyft. Its features include automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic. It offers fine-grained control of traffic behaviour, offering rich routing rules, retries, failovers, and fault injection. Istio was the first to include additional features that developers really wanted, like deep-dive analytics.

Istio has the most features and flexibility of any of these three service meshes by far..

•Cascading failure prevention (circuit breaking)

•Authentication and authorization. The service mesh can authorize and authenticate requests made from both outside and within the app, sending only validated requests to instances.

•Resiliency features (retries, timeouts, deadlines, etc)

•Robust load balancing algorithms

•Control over request routing (useful for things like CI/CD release patterns)

•The ability to introduce and manage TLS termination between communication endpoints

•Rich sets of metrics to provide instrumentation at the service-to-service layer

•Service discovery. When an instance needs to interact with a different service, it needs to find — discover — a healthy, available instance of the other service.

• Container orchestration framework

The Traffic around Istio service mesh is divided into two parts as

Data Plane Traffic

Control Plane Traffic

DATA PLANE

Envoy: high-performance proxy developed in C++ provides Dynamic service discovery, Load balancing, TLS termination, HTTP/2 and gRPC proxies, Circuit breakers, Health checks, Staged rollouts with %-based traffic split, Fault injection, Rich metrics

CONTROL PLANE

Pilot: The core component used for traffic management in Istio is Pilot, which manages and configures all the Envoy proxy instances deployed in a particular Istio service mesh

Mixer: Mixer is a platform-independent component. Mixer enforces access control and usage policies across the service mesh, and collects telemetry data from the Envoy proxy and other services. The proxy extracts request level attributes, and sends them to Mixer for evaluation

Citadel: Citadel provides strong service-to-service and end-user authentication with built-in identity and credential management. You can use Citadel to upgrade unencrypted traffic in the service mesh. Using Citadel, operators can enforce policies based on service identity rather than on network controls.

Some of the Core Use Cases of using Istio are

-Performance Debugging

-Traffic Management (Load Balancing & Weighted Balance)

-Circuit Breaker

-Security

Istio has the most features and flexibility of any of these three service meshes by far, but with flexibility. ..Complexity too arises. It’s better to manage Istio manually rather than depending on Cloud provider Implementations. It reduces cost and complexity.

For a minimalistic approach supporting just Kubernetes, Linkerd may be the best choice.

If a heterogeneous environment that includes both Kubernetes and VMs and do not need the complexity of Istio, then Consul would probably be your best bet.