Istio (https://istio.io/) is an open source platform providing a unique way to connect, secure, manage, and monitor microservices. It supports traffic shaping between microservices, while providing rich telemetry. It ensures fine-grained control of traffic with routing rules, retries, failover, and fault injection. Istio supports access control, rate limiting (throttling), and quota provisioning shown as follows:

Istio is built upon a battle tested sidecar (Envoy). Envoy is coded using the C++ language shown as follows:

The pilot, Mixer, and CA are the key modules in the control plane. These facilitate all the configuration requirement, policy establishment and enforcement, and control flows. The data plane is empowered by Envoy proxies. The data plane mediates all service requests and data communications. Envoy proxy collects and publishes various metric details to a Mixer and there are few popular monitoring tools out of which one is Prometheus. The following diagram can help in better understanding:

The Envoy contributes as a layer-4 and layer-7 reverse proxy. It can do complicated traffic management based on rules. This makes the infrastructure extremely nimble for the operations team. For example, the next diagram shows how 1% of the traffic can be routed to an alternate route for A/B testing:

This can be made possible by pushing out the policy change to the Envoy. The Envoy can also perform layer-7 routing for traffic steering based on HTTP headers, as shown in the following diagram:

The Envoy also takes care of generating spans and integrating with tools such as Zipkin that provide distributed tracing capabilities, which make observing a complicated distributed interaction and correlating causality a feature of the service mesh.

In these kinds of deployments, there is an adjacent container for every application container as illustrated in the following diagram. The sidecar container handles all the network traffic in and out of the application container:

Sidecar is a novel way of providing services to applications. It is especially well adapted for containers and Kubernetes. The sidecar deployment model is bound to the same trust domain as the individual service, and this reduces the attack surface drastically. This type allows services to implement fine-grained policies around inter-service communication that uses cryptographically verifiable identities. For example, Service A can be configured to only be allowed to invoke Service B, and the interaction will be governed and mandated by the proxy, through the use of mTLS certificates with the Istio CA:

The following table shows the differences between ingress and egress:

Apart from these features, ingress also provides annotation, which can be used to redirect the traffic to the service on Kubernetes. 

The Istio solution is to address the issues developers and operators face while they move from monolithic applications toward microservice-centric applications. With the surging popularity of the multi-cloud strategy being vociferously adopted by enterprises worldwide, service discovery, load balancing, and failure recovery are becoming more complicated. Istio is also being deployed in multi-cloud environments.