SEATTLE -- Some Kubernetes proponents said they believe Istio service mesh is as important to cloud-native infrastructure as container orchestration, but most enterprise IT shops aren't ready to dive in just yet.
Service mesh, a term coined by the makers of Linkerd in 2016, refers to a microservices networking architecture that consists of a centralized control plane and a pool of sidecar containers deployed in each container cluster pod. The sidecars' proximity to microservices workloads creates detailed visibility into application performance and intricate segmentation of networks for container security. Istio is also backed by IBM and Google, and therefore has the attention of the Kubernetes community, especially since the project reached version 1.0 in July 2018.
Google and IBM subsidiary Red Hat promoted Istio management products and services at KubeCon here this week, while the project generated buzz in the halls among conference attendees. In the right hands, service mesh can be a vital tool for microservices management, but it comes with daunting complexity for IT pros already challenged to learn container orchestration.
"Like everyone else, we're evaluating service mesh, but I'm just not sure the juice is worth the squeeze," said Brad Linder, DevOps and big data evangelist at Dish Technologies, the engineering arm of Dish Network in Englewood, Colo.
Istio offers big rewards, with big risks
The problem isn't just that service mesh is hard to implement -- without proper expertise, service mesh can actually hurt more than it helps. The upstream version of Istio integrates with Helm charts to ease service mesh installation, but Helm charts use a server component called Tiller, which has privileged access to an entire Kubernetes cluster unless carefully configured. The upstream version of Istio also uses a privileged container to force network traffic through the Envoy sidecar. Thus, inexperienced IT pros that want to use Istio service mesh for its security benefits may expose themselves to security vulnerabilities instead.
"We need to focus on making sure customers can use service mesh in the service of making it easier to deploy and manage apps," said Brian Harrington, principal product manager for OpenShift Service Mesh at Red Hat. "Not as something that just makes life harder."
Red Hat, which uses Kubernetes Operators for Istio in its OpenShift Service Mesh integration, said they are simpler and more secure than the upstream version, and both the Istio and Helm upstream projects plan to move away from Tiller in future releases. But Istio's lack of maturity makes some users hesitant to put it into production.
Brad LinderDevOps and big data evangelist, Dish Technologies
"We will use GKE's Istio service -- we were part of the alpha tests and it's on our roadmap," said Erik Rogneby, senior manager of infrastructure development at media company USA Today Network, based in McLean, Va. "But there are a lot of moving parts and we have to make sure we roll it out in a reliable, well-thought-out way."
Where IT shops have Istio service mesh in production, it's still so new that it can be difficult to get consensus on the value of the technology from everyone on DevOps teams.
"There are so many things in the Kubernetes ecosystem that create decision-making problems, and it's easy to get stuck in analysis paralysis," said Andy Domeier, director of technology operations at SPS Commerce, a communications network for supply chain and logistics businesses, in Minneapolis. "That will cause some companies to struggle to move forward with team unity."
Domeier believes in the benefits of Istio service mesh, particularly for security. SPS uses Istio with its API gateway to exercise fine-grained access control and precise behavior monitoring as external customers and partners connect to its APIs.
"I want it to be part of our standard platform, but I don't know that everyone is on my side right now," he said. "I'm hoping to bring home more selling points [from KubeCon]."
Service mesh -- too many cooks in the kitchen?
Istio is far from the first or only service mesh project, or the only microservices networking alternative at users' disposal. Buoyant, which markets the Cloud Native Computing Foundation (CNCF) project Linkerd, introduced version 2.0 of the project in September, and Linkerd has much more production use by large enterprises than Istio.
Linkerd 2 was overhauled to support faster, smaller sidecars than Linkerd 1's Java virtual machines, and smoother integration with Kubernetes. Buoyant also demonstrated enhanced setup features at KubeCon, such as a means to test whether a certain command will work within the service mesh, automate the application of the command if so, and verify it worked as desired. Linkerd 2 also supports a single namespace or application within a Kubernetes cluster, so that enterprises can ease into service mesh gradually.
"They're working on the right things at the right time," said Harrison Harnisch, staff software engineer at Zeit, a cloud computing managed services and software provider in San Francisco. Harnisch used Linkerd 1 at a previous job and plans to evaluate Linkerd 2 in his current role. "We could use it in production right now."
IT vendors such as Nginx also offer service mesh alternatives, and some users prefer microservices networking utilities that offer some of the features of service mesh without the overhead of a full service mesh deployment, such as HashiCorp Consul Connect and Covalent's Cilium.
Meanwhile, tensions may be brewing between Istio's backers and CNCF proponents over governance of the Istio project. Red Hat's Harrington said he plans to push for Istio's donation to CNCF to give the project vendor-neutral governance. But Istio contributors' priority in 2019 is to expand the project's scope, and include coverage for non-container workloads, before they decide about long-term governance.
"The main reason to join CNCF at this point would be visibility for the project, but we've already reached that goal," said Shriram Rajagopalan, a staff engineer at VMware who was among Istio's founding engineers, in a panel session at KubeCon. "Right now, [development] velocity is a lot more important, so we can quickly reach a higher level of functionality and stability."