Which Comes First: Istio or Kubernetes?
What we do know about Kubernetes? It’s a raw, gaping maw. It’s not meant for most of us. What is needed? Access to the grinding, digital gears that make what we know of as distributed architectures.
Istio is an example of a management layer for Kubernetes, said Zack Butcher, part of the founding engineering team at Tetrate, a service mesh company. He joins Varun Talwar, co-founder at Tetrate for a discussion about the service mesh Istio and its role in the management of highly distributed networks, including Kubernetes in this The New Stack Makers podcast. Alex Williams, founder and publisher of The New Stack, hosted this episode.
What to Build First: Istio or Kubernetes?
Service mesh is increasingly seen as an essential prerequisite for any organization making the shift from legacy infrastructure to cloud native and microservices environments. Among the service meshes on offer to help manage distributed environments, Istio has a short lead, according to a Cloud Native Computing Foundation (CNCF) survey. CNCF’s survey for 2020 showed how 47% of all organizations with service mesh in production use Istio, followed by Linkerd and Consul, both with respective market shares of 41% (an organization can also use more than one mesh).
Istio, as well as service mesh in general, can be thought of as the space between the networking and the programming layers. In this way, it helps to manage an entire operation, while Kubernetes is essentially just part of the network.
“Kubernetes is purely about compute — this is why we see both the mesh as a bigger thing, and why we see the mesh as something that you can start without starting Kubernetes,” said Butcher. “The mesh is architecturally…the network for the applications. That gives us tremendous, tremendous power, and this…is why the mesh is compelling.”
One might hypothesize that it is first wise to deploy a Kubernetes environment and then add a service mesh to manage it all, Tetrate advised. However, this approach is not recommended, nor is it a good idea for organizations to begin their digital transformations by implementing Kubernetes and service meshes, such as Istio, at the same time. While it may “run a little bit counter to what a lot of people think, I think you should start with Istio,” said Butcher.
“Maybe the shortest answer to why you shouldn’t do both at the same time is that it’s really hard to change the engine on the car and the tires at the same time — while we’re going down the interstate,” said Butcher. “There’s a lot of operational complexity and organizational learning that needs to go on to be able to adopt either technology.”
Meanwhile, Istio “at its core remains the same,” said Talwar. From the outset, Istio was created to help connect, secure and observe services,” he explained. “Istio is still the same — it does a fantastic job of doing that within a single Kubernetes cluster, and continues to do so,” said Talwar. “The direction where the project is going… is going to make it more reliable and more usable. So all the roadmap items are more around the usability and reliability of what it does. There is some work [taking place for] extensions and a bunch of those things, but at the core, it is the same.”
Eventually, Istio, like any mature technology, “should become boring and disappear in the background,” said Talwar. “So, what should be happening is that you provision and it’s just part of your infrastructure. And application developers can do the programming side of their APIs and reliably get what behavior they want.”
