Network Service Mesh: Linking multicloud workloads

Networking multicloud-based enterprise workloads can be complicated and tedious, but there is an open-source software project underway that may change that.

Called Network Service Mesh, the project would enable cloud-based Kubernetes workloads to communicate securely regardless of where they are located in disparate clouds and is under the auspices of the Cloud Native Computing Foundation, which is part of the Linux Foundation.

And the need for such technology is growing.  Cisco recently issued a study that says organizations with 5,000 or more employees are likely use more than 10 public-cloud providers and 20 to 100 SaaS providers across categories such as email, collaboration and video calling, and customer-relationship and human-capital management.

That’s potentially a target-rich environment for Network Service Mesh proponents say.

“Network Service Mesh allows the customer to connect individual workloads wherever they are running—either multi-cloud or hybrid cloud—to a service mesh without the complexity of [Layer 7] gateways or having to orchestrate a single, large, complex, flat [Layer 3] domain,” according to Ed Warnicke, principal engineer with Cisco’s Office of Open Source Initiatives.

Traditional application service mesh operates at Layer 7 (HTTPS) with key the features of providing service discovery and routing the HTTPS requests from workloads to services, “Network Service Mesh borrows some of the thinking of a traditional application service mesh and brings it down to L3.  Its marquee feature is providing network service discovery and routing—connecting individual workloads to ‘Network Services’ using virtual wires or vWires,” he said.

Basically, Network Service Mesh creates on-demand, dynamic flat L3 overlays on top of which organizations can run a service mesh and into which they can plug any authorized workloads. “Ultimately, this allows teams to choose the best options for running their workloads—across multiple clusters, in legacy environments, on-premises, or in public clouds—without worrying about adding extra layers of complexity or introducing additional risk,” Warnicke said.

Until now, attempts to solve the multicloud-communication challenge have typically involved either having all workloads and the service-mesh control plane on a single flat L3 network or a system of L7 gateways which themselves reach other over a flat L3 network. Warnicke said Flat L3 is very difficult to arrange in a multi-cloud/hybrid environment, and L7 gateways are extremely complex to maintain and configure and represent a choke point in the system.

Network Service Mesh itself does not provide traditional L7 Services. It provides the complementary service of flat L3 domain that individual workloads can connect to so that the traditional service mesh can do what it does better and more easily across a broader span, Warnicke said.

Network Service Mesh also enables multi-service mesh, which is the capability for a single container pod to connect to more than one service mesh simultaneously regardless of its location, Warnicke said.

Network Service Mesh has identity-federation and admissions-policy features that enable one company to selectively admit the workloads from another into its service mesh, Warnicke said.

The Cloud Foundation lists a few typical use cases for Network Service mesh including:

• A common flat vL3 domain allowing DBs running in multiple clusters/clouds/hybrid to communicate just with each other for DB replication.
• A single L7 service mesh (Istio/Linkerd/Consul/Kuma) connecting workloads running in multiple clusters/clouds/on-prem.
• A single workload connecting to multiple L7 service meshes.
• Workloads from multiple companies connecting to a single ‘collaborative’ service esh for cross-company interactions.

Network Service Mesh is an Open Source project at the CNCF being worked on by a variety of vendors including Cisco, Xored and Ericsson and a number of implementations are available today, according to  Warnicke.  “As its regular cadence of releases (roughly every 60 days) continues more use cases will become available. Its ‘Istio extender’ use cases should be released in early June as part of its v1.4 release, Warnicke said.