Istio is a Service Mesh
Microservices aren’t as new and hot as they used to be which is definitely a good thing. Instead of living in the days of bleeding edge container platforms, we’ve evolved to a state of leading edge where Kubernetes, Openshift and the various other container management systems are stable and reliable. The bleeding edge is now populated with services that run within these container orchestration realms that are relegated to core functions like load balancing, service discovery and security, creating what’s known as a service mesh atop the infrastructure. One such service mesh offering is Istio, and it was second only to Kubernetes on the tongues of the Google engineers presenting at the latest Google NEXT Conference. Calling Istio a hot topic is an understatement and for good reason. Powerful features for controlling and observing your application traffic over the network make Istio a tool you won’t want to go without. Did I mention it’s also “open source”
Istio is the Control Plane and Envoy is the Data Plane
A service mesh makes the core functions of distributed systems, like communication between services, easier to configure and manage. The common set of network functionality that all applications require (such as dealing with timeouts, retries, rate limits, routing and load balancing) can be centralized so those hard problems don’t have to be dealt with by each application individually.
This helps with keeping the business logic separate so developers can focus on delighting their users and not have to worry about the lower layers of the stack. Istio provides this suite of solutions via Envoy, the data plane handling all the traffic in the service mesh, and a handful of apps which make up the control plane that manage the policies and configuration, namely:
- Pilot - traffic control
- Mixer - backend integration
- Citadel - authentication and authorization
- Galley - configuration validation
If you’re in the mood for going deep on data and control planes then have a look at Matt Klein’s (creator of Envoy) blog post about what makes up a service mesh.
Envoy, the Microservices Proxy
Envoy is a proxy, similar to HAProxy and Nginx, but specifically designed for microservices architectures. With features such as:
- Dynamic Reconfiguration / Hot Restarts
- Staged / Canary Deploys
- Advanced Load Balancing
- Request Routing
- Health Checking
- Distributed Tracing
Envoy manages all the routing requirements for both internal and external service communication. External service connections benefit from failure recovery features such as timeouts, retries, and circuit breakers. Envoy is deployed as a sidecar container within an application pod and receives all of its configuration from the Istio control plane via gRPC. Packets going to and from the application are intercepted by Envoy using iptables which allows for powerful routing control and traffic visibility providing detailed metrics. Envoy was designed to simplify the difficulties with networking and observability in highly distributed, service oriented architectures. High performance and low latency are essential characteristics of any worthy proxy, therefore it makes perfect sense that Envoy was written in C++. The full list of features can be found on the official Envoy documentation website:
Traffic Control and Telemetry Via Pilot and Mixer
Mixer and Pilot are integral to leveraging the the most important features of the Istio service mesh, namely: traffic management and telemetry processing.
The Envoy sidecars receive policies from Pilot to enforce rules like allowing service A to speak with service B, but disallowing service A from speaking to service C. Pilot provides the configuration settings for request routing and load balancing for supporting staged releases, blue/green deployments and A/B testing.
Routing rules managed by Pilot allow Envoy to select a specific application version based on conditions such as HTTP headers and weights assigned to each version.
Cluster service registries are shared via Pilot to Envoy sidecars for dynamic service discovery.
Mixer has a set of supported adaptors allowing it to speak with infrastructure backends like Prometheus and Stackdriver for processing and storing metrics, tracing and logging. Envoy sends the telemetry data to Mixer and then Mixer sends those values to the configured backends.
The Arctiq View and Recommendation
Arctiq has been keeping busy architecting and deploying container orchestration clusters and building / improving development pipelines. We continue to see the need for traffic control and observability growing. Organizations moving towards microservices typically start with a handful of applications but as the benefit of the architecture is realized the number of applications starts to grow, as does the complexity. Managing staged deployments and application versions without a service mesh like Istio is non-trivial. Envoy and the Istio control plane components support an organization’s DevOps initiative by codefying request routing configurations and putting that control into the hands of developers.
Another great feature of the Istio mesh is that you don’t need to install or use all the components. We recommend leveraging Istio’s tracing features as a way to visualize how traffic is flowing between your services and across the network. This the perfect way to start using Istio since it’s quick and easy to configure and no changes to your microservices are required to start benefiting from this telemetry.
Our next blog in this Istio series will cover installing Istio, deploying Envoy to a set of service pods and drilling down into the flow of a request between components in the cluster. Stay tuned for more cool container tech…
If you have any questions regarding Istio and how it can help your business transform, please don’t hesitate to reach out…