Can You Now Safely Remove the Service Mesh Sidecar?
Service mesh has certainly emerged as a cornerstone layer for managing containers, virtual machines and Kubernetes environments. Without it, observability and monitoring, logging, routing and, of course, security would be even more difficult than it is now. The sidecar is a key component of the service mesh. It connects — or more exactly — interconnects microservices to different distributed containers and virtual machines. It also serves a key function with service mesh for connecting microservices in Kubernetes environments, serving as a gateway in many ways.
But what if we were able to eliminate the sidecar in the service mesh? And more importantly, why would you want to?
Solo.io and Google have introduced Istio Ambient Mesh which company representatives claim is the industry’s first service mesh to deliver both sidecar or sidecar-less architectures.
For Istio, the sidecar component of the service mesh has worked very well for a number of years, Idit Levine, founder and CEO of Solo.io — the leading provider of tools for Istio — told The New Stack. However, Solo.io has been at work finding ways to improve the structure of both the service mesh and the sidecar. Google, as it turned out, has been doing the same thing. “We both basically have been trying to figure out how to make Istio more easily consumed and maybe even being a little bit more secure,” while offering the same functionality but while solving some of the difficulties users were having, Levine said.
During the past six months or so, Solo.io and Google have been working together to build “the next version of Istio that we believe will be the future,” Levine said.
Eliminating the sidecar has long represented one way to improve connectivity, lower latency and save costs, in addition to reducing complexity for operations teams using service mesh for Kubernetes. However, “there are a limited number of ways you can do it and still be secure,” Louis Ryan, principal engineer, Google Cloud, told The New Stack. “What we’ve done is find a way to do that while still maintaining all the best security properties of a service in a really important and meaningful way. We don’t think that there’s anything inherently wrong with sidecars, but they do represent operational challenges.”
However, this is not the first attempt to offer a sidecar-less service mesh, Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack in an email response. A new architecture where sidecars are optional, depending on use case specific requirements, also just became available with Cilium, which is used for container networking and security, Volk said. Cilium uses a Kubernetes Custom Resource to directly program proxies through the Linux kernel. Linkerd “went down a different route” by using the Kubernetes control plane for service discovery only but relying on independent sidecar-based proxies to function, Volk said.
Istio Ambient Mesh is fully compatible with sidecar-based Istio deployments, and either sidecar or sidecar-less deployments are managed by the Istio control plane. solo.io and Google say with the Ambient Mesh enhancements, Istio becomes the “first service mesh” to deliver both modes with a consistent control plane. Also, with Istio Ambient Mesh, there is no loss of platform or policy management capabilities on the overall service mesh, no loss of application-specific security and application offload capabilities and no need for application or infrastructure teams to immediately learn new programming languages, Solo.io and Google say.
Volk agreed the Istio sidecar-less version is possible to maintain security — but he said caveats remain such as potential “noisy neighbor” problems that could occur when specific This is because CPU-intensive sets of application workloads meet on the same node or cluster requiring the Kubernetes scheduler to make scaling decisions “without knowing which application policy to apply,” Volk said. Inexperienced users could introduce configuration errors that would lead to compliance issues related to a lack of traffic separation. “Also, in case of failure, multiple applications could be impacted,” Volk said. “Sidecars would also still be needed for applications relying on the runtime injection of custom code, for example, to pull off event-triggered configuration changes or enforce context-specific security requirements.”
- The enablement of a sidecarless architecture that moves the proxy functionality from the pod-level to the node-level, in order to improve overall application performance, with 10 to 20 times less compute and memory overhead, the companies say.
- Improved transparency for applications to simplify operations and facilitate system upgrades and new applications to be deployed into the mesh.
- The availability of a new optional security element, PEP (“policy enforcement point”), that the companies say delivers Layer 7 security inspection.
As mentioned above, users also have the option to use the Istio service mesh in sidecar mode since there is a common control plane that can be used with either sidecar or Ambient mode. “This brings consistency to the overall environment,” Brian Gracely, head of product marketing strategy for Solo.io, said in an email response. “We allow sidecar or Ambient mode to be deployed on a per-cluster or per-namespace basis, so users can best match the architecture with their application needs.”
A regulated company might prefer sidecar mode for a set of applications that absolutely cannot have any shared resources (such as proxies) anywhere in the data path for security and/or compliance reasons, Gracely explained. “But they might also have a set of applications (e.g. marketing applications) that can use Ambient mode without any issues,” Gracely said. “Other service meshes offer either sidecars or sidecar-less, and they often make you bring-your-own control plane depending on which data plane you choose (if they support more than one mode).”