Network Service Mesh: Linking multicloud workloads

The Cloud Native Computing Foundation is developing technology to link multicloud enterprise workloads at the network layer regardless of where they are running.

Stephen Lawson/IDGNS

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, as well as 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 meshes operate at Layer 7 (HTTPS) with the key features of providing service discovery and routing 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 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 connect 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 choke points.

Network Service Mesh itself does not provide traditional L7 services. It provides the complementary service of flat L3 domains 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.

Copyright © 2022 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022