What is a Service Mesh and how Istio fits in

We’re pleased to announce the release of a new IBM Code developer journey, Manage microservices traffic using Istio.

There’s been a lot of chatter in Silicon Valley recently around service mesh architecture. But what exactly is a service mesh? Why do we need one for microservices? Aren`t existing platforms like Kubernetes and Cloud Foundry enough to handle microservices?

Why service mesh?

Microservices and containers have changed application design and deployment patterns. They’ve also brought with them some new challenges, such as service discovery, routing, failure handling, and visibility to microservices. And while PaaS platforms like Cloud Foundry are great for deploying microservices, they were created with a view of simplifying application deployment across multiple runtimes. Similarly, Kubernetes can handle multiple container-based workloads, including microservices, but when it comes to more sophisticated features like traffic management, failure handling, and resiliency, both the platforms leave a lot to be desired.

Imagine an application that is broken down into multiple microservices; each microservice has multiple instances, and each deployed instance has multiple versions. Typically, even a simple application deployment with this kind of model can span hundreds of microservices. When an application deployment gets this large, distributed, and complex, the result is often failure. But you need to fail fast and recover quickly. You need a mechanism that is fault-tolerant, one that provides more visibility and control into the complex network of microservices and ensures reliable, secure, and timely communication between them.

For this deployment model, we need to keep track of the traffic flow between microservices, route traffic for microservices based on request content or traffic origination point, and handle failures in a graceful manner when a number of microservices are not reachable. We also need to enforce strong identity assertion between services and limit the entities that can access a service. Most importantly, we want to do all this without changing the application code.

Service mesh architecture was created to handle these requirements. Think of a service mesh as a network of interconnected devices with routers and switches, except in this case the network exists at the application layer (layer 7), nodes are services, and routing, delivery, and other tasks are off-loaded to the service mesh. The goal is to get a request in a reliable, secure and timely manner across this mesh of microservices from origination to destination microservice.

Typically, this is achieved by using “proxies” to intercept all incoming and outgoing network traffic. Proxies in a service mesh architecture are implemented using the sidecar pattern: a sidecar is conceptually attached to the main (or parent) application and complements that parent by providing platform features. With this kind of model, your microservice can use the sidecar either as a set of processes inside the same microservice container or as a sidecar in its own container to leverage platform capabilities such as routing, load balancing, resiliency, in-depth monitoring, and access control.

Istio: A service mesh architecture implementation

Istio is a service mesh created through a collaboration between IBM, Google and Lyft. It uses the sidecar pattern, where sidecars are enabled by the Envoy proxy and are based on containers. By injecting Envoy proxy servers into the network path between services, Istio provides sophisticated traffic management controls, such as load-balancing and fine-grained routing. This routing mesh also enables you to extract a wealth of metrics about traffic behavior, which can be used to enforce policy decisions such as fine-grained access control and rate limits that operators can configure. Those same metrics are also sent to monitoring systems.

Istio achieves this by deploying:

• A control plane that manages the overall network infrastructure and enforces the policy and traffic rules
• A data plane which includes sidecars implemented using Envoy, an open source edge proxy

Apart from Envoy proxy, key components of Istio are:

• Istio Pilot (for traffic management): In addition to providing content and policy-based load balancing and routing, Pilot also maintains a canonical representation of services in the mesh.
• Istio Auth (for access control): Istio Auth controls access to the microservices based on traffic origination points and users, and also provides a key management system to manage keys and certificates.
• Istio Mixer (for monitoring, reporting, and quota management): Istio Mixer provides in-depth monitoring and logs data collection for microservices, as well as collection of request traces. It uses Prometheus, Grafana, and Zipkin to provide some of these in-depth metrics.

Get out in front — try it today!

In our new journey, we show how you can modify and deploy the sample microservices application on Istio and use Envoy sidecars to enable the framework features in the application, as well as allow the application to connect to external services using egress Envoy. You’ll learn how Istio features such as traffic flow management, access policy enforcement, and telemetry data aggregation between microservices can be enabled without requiring changes to your microservice code. We’ve also integrated the journey with Bluemix DevOps Toolchain to provide a one-click deployment for anyone who wants to try it out quickly. Please use the journey, extend it, and send your feedback. As with every IBM Code journeys, all pull requests are welcome!