Solving Complexity at the Network Layer with Istio

Istio and the service mesh

Developed in collaboration between Google and IBM, Istio is an open source technology that provides operational control over and behavioural insight into the service mesh of an application as a whole. Sitting above the application layer, service meshes consist of a dedicated network layer abstracted away from microservices themselves. Monitoring the service mesh, Istio enables platform-independent communication between microservices that doesn’t require changes in service code. It seeks to relay requests from origination to destination microservices in a reliable, secure, and time-efficient manner by relying on the intelligence of independent proxies.

Within the service mesh, Istio provides a single control plane that monitors the underlying data plane. The data plane consists of the communication routes themselves between microservices, composed of Envoy proxies. Using the sidecar pattern, an Envoy proxy will conceptually attach itself to an origination container pod and route messages into the service mesh above. The message will then be picked up by the respective Envoy proxy of the destination microservice. In doing so, an Envoy proxy will include many built-in features, such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers, health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics. Envoy proxies are able to handle service discovery, health checking, routing, load balancing, authentication and authorization, and observability. Developed in C++, Envoys are nonetheless easily transportable proxies that permit robust communication both between distinct containers and virtual machines (VMs) across multiple cloud environments independent of the service’s awareness.

The behaviour of Envoy proxies within the data plane is directed by the control plane, an automated layer superimposed on top of the data plane. Istio’s control plane sets distinct policies that dictate how Envoy proxies should behave. The control plane is divided into three panels that each monitor a separate dimension of communication.

Pilot

Pilot manages traffic control. It provides rules for how proxies can attach themselves to and dictate containers in order to route traffic through rolling applications. Pilot provides monitors with failure recovery and fault injection allowing you to test for and easily mitigate failures. Additionally, it provides features, such as circuit breaking and retries that can be applied to each service without individually rewriting the code. Pilot essentially abstracts platform-specific service discovery mechanisms, synthesizing them into a standard format that is easily consumable by sidecars that conform to the Envoy data plane APIs.

Istio Auth

While Pilot directs the flow of traffic, Istio Auth builds the roads required by administering TLS certificates to ensure service-to-service communication and validate end-user authentication. It can upgrade unencrypted traffic and enforce policies based on service identity rather than network controls. Istio Auth ensures security without adding requirements for developers to override functionality.

Mixer

In the third panel, Mixer provides visibility of the microservices by collecting telemetry metrics, automated communications procedures that transmit measurements and other data from remote or inaccessible points to receiving equipment for monitoring and reporting. It collects this data in the form of level attributes using Envoy proxies, and then converts disparate microservices into the integrated service mesh by introducing programmable routing in a shared management layer. It distributes management by enforcing access control and usage policies. As a platform-independent component, Mixer includes a flexible plugin model that allows it to interact with various platform services, such as Prometheus and Google StackDriver.

Containers, Istio, and the Service Mesh

Containers have provided extremely strong mechanisms for managing application workloads. By abstracting the operating system away from the runtime and dependencies, containers allow applications to be quickly deployed, tested, and updated. As Docker and Kubernetes have become the standard for container orchestration, the resultant association between a container and a single application has increased the flexibility to deploy and scale microservices individually and in isolation from their surroundings. However, this flexibility comes at the cost of complexity that becomes increasingly apparent as an application scales.

The sheer number of microservices involved in an application has made container orchestration a complex affair, which results in limited scalability. Problems that could be solved once within monolithic applications must be solved individually within containers. The resultant inconsistency in problem-solving leads to solutions that have poor observability, and vary dramatically in both language and runtime. As container-based applications attempt to scale, network imperfections in areas, such as service discovery, load balancing, traffic control, fault tolerance, end-to-end monitoring, dynamic routing for feature experimentation, microservice visibility, compliance, and security are strongly magnified. Altogether, this makes for a chaotic network with severe enough limitations that have necessitated the emergence of service meshes.

Service meshes essentially provide a decentralized approach to microservice management by employing a dedicated abstraction layer for making service-to-service communication fast, secure, reliable, and observable. Istio automates this process turning a dispersed set of sidecar proxies into a distributed system that automatically configures systemic management. In doing so, Istio increases the predictability and visibility of microservice behaviour. It ultimately creates order out of the complexity of microservice architecture made evident by the ability of Kubernetes to fully leverage and deploy microservices at scale.

Macromesh your Microservices

Having only been announced at Gluecon this past May, Istio has already gained a fair amount of traction. While Kubernetes has proven itself to be both robust and reliable in offering application deployment flexibility, the realisation of microservice-based architectures are consequently limited by complexity at the network layer. Istio adds visibility to the chaos found in microservices at scale. If an application is only as good as its network, Istio promises to elevate the potential of microservice-based applications by orchestrating its network and transcending its limitations. As Kelsey Hightower said, “Kubernetes changed how we deploy applications, Istio is going to change how we connect, manage, and secure them.” In 2018, we can only expect more from Istio as it matures beyond infancy. To learn more about Kubernetes and cloud native technologies, sign up for our workshops and trainings.