Istio: Is it a bird?… Microgateway Blog Series, Part 4

“It’s a bird. It’s a plane. It’s Super…” No, wait, it’s Istio! If you squint, you can just make it out! What is Istio? Superheroes come in all shapes and sizes! Today, in a microservices architecture, Kubernetes is the superman. It’s easily recognizable, it’s the most powerful cloud (and on-premises) superhero today: bulletproof, flies anywhere, always available, secure, trustworthy,….

For more microgateway information, read the other blogs in this series:

• Part 1: Traffic Management
• Part 2: Edge to Internal
• Part 3: Whodunit?

Like the movie Ant-Man and the Wasp, I’d like to talk about the smallest superhero needed in a microservice architecture, namely Istio! Istio combines some of the best attributes of a superhero by guaranteeing that chaos is kept at bay and ensuring that the expected order of the Galaxy prevails!

In the comic world, the smallest superhero is arguably Ant-Man. In the microservices world, it is most definitely Istio! Just like Ant-Man, Istio is small, fast, flexible, and strong. Superman and Kubernetes are great for solving big problems, but they are clumsy and slow in very tight spaces. Ant-Man and Istio excel in these environments; in fact, they were designed for this exact reason (separation of concerns).

Istio – the tiny hero of micro service deployment – is like Ant-Man (image source)

Istio provides a uniform means of managing, securing, and monitoring microservices. We’ve heard this before, right? The Netflix stack provides Eureka (routing), Hystrix (resiliency/fault-tolerance), and Zuul (Security/API Management). Kubernetes solves many of these same concerns, as well; so, what’s the fuss? Why is Istio important?

Istio was announced in May 2017 by Google, IBM, and Lyft. Istio doesn’t get as much fanfare as Kubernetes – a little bit like the hype associated with Avengers: Infinity War compared to Ant-Man and the Wasp, but it does have a unique role. It functions as a microgateway, which adds tremendous value – because it simplifies hard problems, allowing development to become easier.

A key role of any microgateway is to take some of the complexity out of the hands of developers. The developer can focus on important company business logic and not worry about how his or her service needs to handle common network functions like routing and load balancing, resiliency functions like retries and timeouts, security functions like authentication, authorization, and service-level monitoring and tracing.

Istio acts as a lightweight sidecar to manage traffic between services. To add Istio support to your microservices architecture, sidecar proxies (Envoy-based) are deployed throughout your environment. The sidecars are responsible for intercepting network communications between services. The Envoy supports L3/L4 filtering for custom protocol needs and L7 routing for HTTP/2 traffic. When you have all of the sidecars deployed, you end up with service mesh!

Microservice architecture with and without a sidecar. With sidecar = service mesh

If we look closer at the design, we can see the elegance of the architecture. Consider that the Envoy is deployed “out of process”, meaning it is a separate process from the service it is benefiting. In addition, because it is out of the process, it can provide a governance layer without the need for embedding libraries and providing ugly annotations (i.e hystrix) inside each service. Finally, and the obvious one, it solves the polyglot issue. You can deploy Envoy, in front of any microservice, regardless of the origin of the service: java, js, go, legacy, even COBOL (no joke, if it is in a container, yes). As a developer, your sole focus can be on the business logic that makes money for your company and not the complexities of microservice orchestration.

Istio overview (image source)

The diagram above describes the main components of the Istio stack. The diagram can be logically split into two:

1. 1. The data plane is composed of a set of Envoy proxies that mediate and control all ingress and egress network communication between microservices, The data plane also acts as a policy enforcement point and gathering of telemetry. Picture Ant-Man running back and forth quickly between the services making sure things are happening as they should. The data plane provides the following features:
      

      Ingress features	Egress features
      Authentication Authorization Rate limits Load shedding Telemetry Request Tracing Fault Injection	Service authentication Load balancing Retry and circuit breaker Fine-grained routing Telemetry Request Tracing Fault Injection

2. The control plane is responsible for managing and configuring proxies to route traffic and configuring Mixers to enforce policies and collect telemetry. Think of this as the command center where Ant-Man gets his instructions on how to complete his mission.

   The Envoy proxy gets its traffic management rules from Pilot. Pilot lets you specify what rules you want to use to route traffic between the proxies and configure failure recovery features (i.e. timeouts, retries, and circuit breakers) and fault injection.

   Mixer is responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other services.

   Citadel provides strong service-to-service and end-user authentication with built-in identity and credential management.

We have been trying out Istio in our environment to see what it can provide us with and how it can help us bring our microservices towards production readiness. Istio provides us with a lot of out-of-the-box visibility without the team having to instrument their services. Also, keep in mind, that some of the services we use have not been built in-house, so Istio allows us to “spy” on these black boxes, by capturing and recording data points surrounding the ingress and egress.

Istio Dashboard (using Grafana Istio add-on) showing microservice metrics (image source)

In addition, because Istio controls all ingress and egress traffic to a service, it allows for complex microservice tracing to be captured and visualized with tools such as Zipkin.

Tracing of calls between services using Zipkin

Istio employs the use of the ambassador pattern making it easily extensible. Istio can be plugged into many different metrics/telemetry or logging systems or can be used to enforce a custom policy. Basically, you add an existing adapter or build your own for whatever system you wish to interact.

As we’d previously established there are many things that can go wrong on the network when a service is interacting with another. Istio is designed to increase resiliency by stopping cascading failures and encouraging the adoption of stability patterns. Istio allows you to use circuit breakers, timeouts/retries, rate limits, and other advanced resiliency features without changing the application code. It can even allow you to do fault injection which allows you to see how your services behave in failure cases (aborts, delays in responses, etc.).

Just like in the upcoming movie, I hope that you now know that microgateway and Istio are a lot bigger than you ever thought possible.

Image from Ant-Man and the Wasp trailer