Service Mesh Will Transform Network Management
As more cloud-native applications are deployed in production environments the need for application connectivity between highly distributed microservices is becoming more important. What is less clear is the profound impact the rise of cloud-native applications will have on the way networking was historically managed.
Networking has long been a fiefdom run by specialists with their own insular culture. However, with the rise of service meshes that provide a layer of abstraction for connecting application programming interfaces, networking overlays are becoming truly programmable for the first time. Instead of having to wait for a network administrator to provision networking resources, it’s becoming possible now for DevOps teams to manage network traffic using routing rules and policies that can limit communication between applications.
In effect, the service mesh provides an overlay through which DevOps teams can manage network traffic. There will always be a need for networking teams to set up the physical underlay made up of switches and routers, but once installed, a service mesh transfers control over networking services to the teams that are deploying modern cloud-native applications.
There are four different types of service mesh that have emerged in the last few years, with Istio, Linkerd, Consul and Kuma all garnering varying degrees of support. Regardless of which service mesh is employed, however, the historic divide between networking operations and DevOps workflows is finally being bridged. “Networking becomes a natural extension,” said Idit Levine, CEO of Solo.io, a provider of a curated instance of Istio. “We’re reinventing the way networking works.”
The service mesh has become the glue through which, for example, a platform engineering team can invoke an API to enable application connectivity, she added.
IT teams are making this transition because cloud-native applications constructed using microservices are much more latency-sensitive than legacy monolithic applications, noted Eric Frieberg, COO of Tetrate, another provider of a curated instance of Istio. “The shift is being made out of necessity,” he said.
The debate that has emerged among proponents of service mesh platforms comes down to what capabilities are required. Istio, originally developed by Google, was designed to be employed by engineers that need to support cloud-native applications at web scale. It provides more capabilities than other service meshes but also requires a centralized team to support it.
Linkerd, conversely, is a lighter-weight service mesh designed to be deployed by smaller development teams. Originally created by Buoyant, the Linkerd service mesh makes it simpler for DevOps teams to drive application connectivity on their own terms in a way that is more accessible, said Buoyant CEO William Morgan. “Istio suffers from the same issues as Kubernetes, in that it’s complex,” he said.
Two other options are Consul, a service mesh being advanced by HashiCorp, and Kuma, a service mesh originally developed by Kong, Inc. Like Linkerd, Consul and Kuma provide a lighter-weight service mesh alternative. Kuma and Consul in addition to enabling application connectivity within Kubernetes environments, however, also extends that capability to legacy monolithic applications. Consul also provides additional failover and observability capabilities.
It’s not clear to what degree organizations may be standardizing on one type of service mesh or another. In many cases, organizations are starting to employ multiple service meshes depending on who is driving the decision. Centralized IT teams in larger enterprises might, for example, favor Istio for scalability reasons, while an individual developer within the same organization may have decided to employ a lighter weight alternative that was easier for them to install.
Regardless of approach, the way networking services are managed is now being permanently changed in a way that will soon profoundly alter how IT teams that deliver those services are organized.
