Rinor Maloku - Istio in Action

A service mesh can maximize the development speed of your whole organization by enabling thousands of independent microservices that are automatically compliant with a wide range of evolving policies. This book discusses many other benefits of Istio, but they largely follow from this premise.

This brings us to the central question, What is a service mesh, and why do I need one? Im asked this question frequently, and the answer is not trivial. It is not about security or telemetry or most of the benefits some people claim. Nor is it automatically the case that you need a service mesh for your application, especially if it is a monolith.

The real answer has to do with decoupling applications from infrastructure. Istio is the third major step in that direction. First, Docker provided a way to package an application (and its library choices) separately from the machine on which it runs. Next, Kubernetes made it easy to create a service with automation to help with autoscaling and management. Together, Docker and Kubernetes enabled the practical movement to fine-grain services, often called microservices. This book guides you through implementing a service mesh with Istio to achieve this third step: application decoupling.

Microservices allow greater overall velocity by enabling teams to be more autonomous. Ideally, your team can update its microservice(s) without deep interactions with other teams. The top-level goal for Istio is to enable this at scaleto make it easy to have thousands of microservices (Google has more than a million!).

But enabling velocity for a service is not just about decoupling it from the machine; the service must also be decoupled from shared policies. Every enterprise has policies that apply to all services, and we must be able to change those policies quickly if needed. Traditionally, such policies are embedded inside services as part of the code or as libraries that services are expected to use. Either way, such policies are hard to update and enforce.

Istio moves a wide range of such policies (primarily those involving an API) out of the service and into the service mesh, which is essentially a proxy that sits in front of the service and implements the policies. When this is done correctly, all services meet the policies with no workand, conversely, policy changes do not require updating the services. This is the decoupling we are after.

In Istio in Action, Christian and Rinor present a clear-headed vision of how to achieve the goal of decoupling applications from infrastructure. I hope youll enjoy this book as much as I have.

Eric Brewer, VP Infrastructure and Google Fellow

Building software is hard. Connecting different services across a network is harder. Any time you put a packet, message, or request on the network, there are no guarantees about its outcome. Will the request make it? How long will it take? Will anyone know if the communication fails?

Docker and Kubernetes have done a lot to support distributed services architectures like microservices, but they exacerbate the existing communication problems. One misbehaving service might take down everything.

While working with organizations worldwide that are trying to adopt microservices, I find that getting teams to consistently think about and solve these communication problems is very difficult. There are many questions: How will they do service discovery? Timeouts? Retries? Circuit breaking? Tracing? Authentication? Large cloud companies like Netflix, Twitter, and Google pioneered some of the early, successful microservices architectures. These companies had to build a lot of their own developer tooling and infrastructure to solve these problems, and fortunately, they open sourced much of it. Could other organizations use the NetflixOSS stack or Twitter Finagle? They could, and some did, but doing so created a new operational nightmare.

For example, the NetflixOSS stack was primarily written for Java developers. What about NodeJS, Golang, and Python teams? Teams had to either build libraries themselves or hack together the functionality with various bits they found on the internet. They also had to intermingle this networking code into their business logic. This approach added transitive dependencies, cluttered the code, and made revisions more difficult. Operating a service architecture with these application networking libraries, upgrading, patching, and doing this consistently across many different languages was extremely complex and error prone.

A service mesh is a cleaner solution to this application-networking problem. With a service mesh, we abstract away the application-networking logic into a dedicated piece of infrastructure and apply it to all services regardless of what languages they are written in.

Istio is a scalable, mature, powerful service-mesh implementation that originally came out of a project from IBM and Google. I was introduced to the Istio team in January 2017 and began working on the project very early. At the end of 2018, I went to work as global field CTO at a startup, Solo.io, to focus full-time on service mesh technology and advancing the state of application networking.