What is Istio?

How Istio works

A network of microservices and the interactions between them is called a service mesh. A service mesh allows insight into service communication layers and provides better control of microservice communication logic. However, as a service mesh grows, it becomes more difficult to understand how each microservice is interacting with the others. This is what Istio tries to resolve. Istio moves logic out of the application code and into the service mesh so that developers can scale and deploy services for each microservice independently with few or no code changes.

The elements of Istio include:

• Envoy -- Istio uses an extended version of Envoy -- an application layer proxy and communication bus designed for large service oriented architecture (SOA). Istio deploys an Envoy sidecar next to each application instance. Originally built for Lyft, Envoy allows Istio to access detailed information about traffic behavior.
• Pilot -- Pilot drives the Istio service mesh, providing service discovery for Envoy sidecars, and traffic management for functions including A/B testing, canary deployments and timeouts.
• Citadel -- This is the security aspect of the Istio service mesh. Citadel allows services to talk to each other and developers to upgrade unencrypted traffic through the service mesh to make sure it is encrypted as it travels back and forth. Citadel provides secure service-to-service authentication with built-in identity and credential management.
• Mixer -- Mixer is the platform-independent, central point where telemetry is collected from each Envoy proxy and where access control policies are enforced. Mixer is pluggable, allowing for the addition of third-party applications.

An Istio service mesh is split into two planes: the data plane (DP) and the control plane (CP). The DP is a set of intelligent proxies deployed as sidecars to control network communication among microservices alongside the Mixer.

The CP is Istio's core. It secures the DP and manages and configures proxies to route traffic and enforce policies at runtime. The CP also configures Mixers to collect telemetry and apply policies. It possesses a Layer 7 understanding and can train the DP to settle on complex steering choices depending on security stances, constant telemetry data and arrangements.

Istio functionality includes:

• Automatic load balancing -- Load balancing allows HTTP, gRPC, WebSocket, and TCP trafficking control of how communication happens between microservices. Istio currently supports three Envoy load balancing modes: round robin, random, and weighted least request.
• Fine-grain control of traffic behavior -- Fine-grain control enables developers to apply routing rules, retries, failovers, and fault injection, while controlling how each microservice works, as opposed to making code changes that affect all microservices at once.
• Access control -- Istio’s security architecture includes transparent TLS encryption, as well as strong identity-based, authentication, authorization and accounting (AAA) for each microservice.
• Visibility -- Istio offers visibility into cluster traffic through logging, graphing, automatic metrics, and tracing capabilities.

Why use Istio?

The services provided by Istio -- such as load balancing, monitoring and managing -- reduce the complexity of microservice deployments. While all of the features and functions can be found in various libraries, Istio alleviates the strain this by providing the benefits, in one place, without changing the source code, allowing developers to more efficiently and effectively monitor, set and enforce service-level objects (SLOs) on services as well as increasing the speed in issue detection and remediation.

Istio's traffic management simplifies configuration of service-level properties and provides improved visibility into traffic flow and out-of-box failure recovery features. This allows developers to catch issues before they turn into problems, making calls more reliable and the network more secure.

Istio continues to improve security by managing authentication, authorization and encryption of service communication. Policies can be enforced across different runtimes and protocols since Istio secures service communications by default. This allows developers to focus on security at the application level.

In addition, the increased visibility provided by Istio's tracing, monitoring and logging features creates a greater understanding of how service performance impacts elements throughout the system. The custom dashboards provide a look at how a specific performance is affecting other processes, increasing visibility into the performance of all services.

Istio and Kubernetes

While Istio is platform independent, its benefits are greater when used with the Kubernetes engine. Using the two together creates the ability to secure service-to-service and pod-to-pod communications at the application and network levels.

Kubernetes also benefits from a partnership with Istio. The Kubernetes container orchestration software can deal with multi-container workloads, like microservices, but it cannot handle features such as traffic management and failure handling. Istio fills these gaps, creating a more efficient and secure system.

Istio vs. Linkerd

 Linkerd is another open-source service mesh that is in competition with Istio. One immediate difference between the two is the proxying technology used in the data plane. While Istio uses Envoy as its proxy, Linkerd uses a built-for-purpose proxy called linkerd-proxy. Istio's Envoy proxy is written in C++ and the linkerd-proxy is built in the Rust programming language. In addition, Istio builds on top of Envoy, providing the included advantage of essential capabilities like subset routing. Linkerd has to rely on separate, external sources to maintain these functions.

Another major difference is that the Linkerd 2 service mesh is being built with a Kubernetes mindset while Istio is built to run on both Kubernetes and non-Kubernetes environments. Therefore, Linkerd is limited to performing only in Kubernetes environments while Istio is completely independent and can run in various environments.

Istio has more features than Linkerd, but it also doesn't run as fast. The Envoy proxy employed in Istio uses over 50% more CRU than Linkerd. However, Istio's greater number of features means increased configuration options and potentially more resource utilization. In the end, deciding between Istio and Linkerd must be based on the goals of the development team.