Eric Brewer at Tetrate's Service Mesh Day 2019: Why Istio and Envoy are the Future of Networking for Distributed Systems
We’ve all noticed that the cloud is changing.
What’s really going on, according to Google’s VP of Infrastructure Eric Brewer, speaking at Tetrate’s inaugural Service Mesh Day 2019, is that we’re moving to a world where everything’s going to be a service, and where Istio’s role is to make services work well.
Istio decouples developers from operations
While VMs and discs are the right infrastructure for moving legacy things to the cloud and saving server costs, it’s not what we really want, said Brewer. We want the ability to do something with services and APIs, to stop thinking about the hardware, to use different languages and have different teams that can work independently. These are the problems answered by Istio.
Istio is often defined by its functionalities as a tool to “control, secure and observe” services. While it does do those things, for Brewer the more salient point is that in the presence of tens of thousands of services and billions of containers, Istio enables automation. Even more than that, it decouples developers from operations. And it decouples service policies from service implementation.
For example, the traditional way you set access control policies is to put some source code in your service. If you want to change the policy, you later find the source code and change it, find and change all the call sites and all the services that do access control, and then redeploy all the services you’ve just changed.
Istio takes the source code out of that equation. Policies can be set consistently and at once across services. They can change while the services are running, without involving developers. Another long-term advantage for productivity: Policies don’t block launches. With policies in the source code, you have to go through launch control, convincing your CIO or your security org that your service is safe to launch and meets all the policies. That process goes away when you have these policies in the proxies.
Brewer went on to describe the two unsolved architectural problems he foresees that are going to matter in the future of networking: Federation and structuring. It’s easy enough now to have a mesh, but we’re not yet ready for using collections of meshes that can interconnect. And looking ahead, Brewer hopes to see Istio and Envoy expand from L7 to further handle lower OSI levels.
The core of Istio is managing L7 headers, and with a plug-in model we can do application-specific things; it would be helpful to make it more well understood, said Brewer, that Envoy proper looks at header and Envoy plugins look at payload. This matters because some of this work is often done, at considerable expense, using hardware. “We don’t want to force people to do everything in a general purpose CPU,” said Brewer, “especially for lower layers.”
Users should avoid the pitfall of adding features to Istio or Envoy that will make the system impossible to offload. Rather, they should ensure that lower layers are constrained enough that they can be later offloaded to ensure high performance in the long term. In the future, too, a practical goal would be to have one, platform-agnostic policy language that can be broad enough to be used for all the layers.
For more from Brewer, including the virtues of canary testing and progressive rollouts, check out his 3-minute interview with Tetrate.