Service Meshes: Why Istio? An Introduction
There are 3 leading contenders in the cluster ecosystem for service mesh, all open source. We compare and discuss why Istio is the best choice in most scenarios.
Join the DZone community and get the full member experience.Join For Free
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 and Implementations.
- Istio Components.
- Istio Features.
What Is a Service Mesh?
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 an unwanted situation arises. For example; performance issues, security, load balancing problems, tracing the service calls, or proper observability of the service calls.
The 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.
Available Service Meshes
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 handle routing and 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 behavior, 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.
Why Istio Over Linkered and Consul Connect?
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.
Architecture and Implementations
The traffic around the Istio service mesh is divided into two parts as:
- Data Plane Traffic
- Control Plane Traffic
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.
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 and Weighted Balance).
- Circuit Breaker.
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 does not need the complexity of Istio, then Consul would probably be your best bet.
Opinions expressed by DZone contributors are their own.