Putting microservices on a diet with Istio

Description

In a microservice world, things become more complex. Platforms such as Kubernetes address a lot of the complexity; they handle resource isolation and utilization, networking, and deployments nicely. But a lot of the involved complexity such as load balancing, rollout scenarios, circuit breaking, retries, rate limiting, observability, tracing, and transport security is still left up to the development teams.

Of course, you can address all of these challenges in your microservices programmatically using popular open source components such as Hystrix, Ribbon, Eureka, the EFK Stack, Prometheus, or Jaeger. But unfortunately, this approach can quickly lead to excessive library bloat, and suddenly your microservices are not quite so micro anymore.

All this might seem acceptable if you’re on a single, consistent development stack like Java EE or Spring Boot. But tackling these complexities becomes even more challenging if you’re dealing with multiple stacks and multiple frameworks, to say nothing about dealing with legacy applications that you can’t modify to retrofit these requirements.

In comes Istio to the rescue. It is a so-called service mesh that addresses many of the cross-cutting communication concerns in a microservice architecture. Think of Istio as AOP (aspect-oriented programming) for microservice communication. Instead of implementing everything directly within your services, Istio transparently injects and decorates the desired concerns into the individual communication channels.

Mario-Leander Reimer offers an overview of Istio and explains how it addresses the inherent complexities in microservice architectures. Mario-Leander briefly discusses the conceptual architecture and the main building blocks of Istio before diving into several examples deployed on a live Kubernetes cluster to demonstrate the different traffic management features, as well as diagnosability and security.