How Istio Is Built to Boost Engineering Efficiency
One of the bright points to emerge in Kubernetes management is how the core capabilities of the Istio service mesh can help make engineering teams more efficient in running multicluster applications. In this edition of The New Stack Makers podcast, we spoke with Dan Berg, distinguished engineer, IBM Cloud Kubernetes Services and Istio, and Neeraj Poddar, co-founder and chief architect, Aspen Mesh, F5 Networks. They discussed Istio’s wide reach for Kubernetes management and what we can look out for in the future. Alex Williams, founder and publisher of The New Stack, hosted this episode.
ASPEN MESH: How Istio is Built to Boost Engineering Efficiency
Microservices have certainly introduced complexity into infrastructures, compared to the virtual machines (VM) in the past. Istio has emerged as a way to program network policies through an API, Berg said. “It’s a natural evolution to fit where we are today with cloud native applications based on containers,” Berg said.
Istio is also a particularly well-suited way for writing generic and reusable software to manage intraservice communication. As an open source service mesh platform for simplifying microservices communication, Istio handles “a lot of complicated pieces around microservices communicating with each other,” Poddar said. Its range of use includes enforcing policies, managing certificates and telemetry, “so that you can understand what’s happening in your cluster,” said Poddar. “Those problems become more and more complicated as you add more microservices.”
Additional challenges exist once the deployment is operational too, Poddar said. “On day two, you want to harden your cluster environment and you don’t want unencrypted data flowing through for maintainability,” Poddar said. “They need to have consistent metrics across the system, otherwise they don’t know what’s going on.”
Similarly, the development team must be on alert if and when their applications fail during the day two-phase. Developers “need to be brought in when failures happen and need to be consulted at the right time with the right context,” Poddar said.
Istio’s telemetry capabilities are a critical component in “understanding what’s happening in your cluster,” Poddar said. “And those problems become more and more complicated as you add more microservices,” Poddar said. “So service mesh in Istio is just taking that burden away from the developers and moving into the infrastructure layer. It’s basically decoupling the two teams and enabling them to be successful at the same time.”
Aspen Mesh also plays a role in helping the DevOps team take advantage of Istio’s traffic management, security, and general networking capabilities, Berg said. “Generally speaking, there are traffic management capabilities and things like that a developer would use, because you’re defining your routes and characteristics specific to your application, as well as the rollout of your deployment,” Berg said.
But for the setup phase, involving policies for inbound or outbound access controls into the cluster, “that may be a security adviser that’s responsible for defining those levels of policies, and not necessarily the developer, because you wouldn’t want the developer defining that level of security policies,” Berg said. “It would be a security officer that would be doing that. There’s room for multiple different roles.”
The future of Istio in terms of how it builds upon running multicluster applications on Kubernetes should include evolving to “talk to the language of applications,” Poddar said. “That’s where the real value will kick in and service mesh will still be a key player there, but it will be a part of an ecosystem where other pieces are also important and all of them are giving that information and we are correlating it,” Poddar said. “We’re still very early, as people are just getting used to understanding service meshes. So telling them that we need to coordinate all of this information in an automated way is scary — but we will get there.”
