The Cloud Native Computing Foundation develops technologies to connect multi-cloud enterprise workloads at the network layer, regardless of where they are running. […]
Networking multicloud-based enterprise workloads can be complicated and tedious, but there is an open source software project that could change that. Under the name Network Service Mesh [engl.] the project would enable cloud-based Kubernetes workloads to communicate securely, regardless of where they are in different clouds.
It is under the auspices of the Cloud Native Computing Foundation, which is part of the Linux Foundation.
And the need for such technologies is growing. Cisco recently published a study [engl.]According to which companies with 5,000 or more employees are likely to use more than 10 public cloud providers and 20 to 100 SaaS providers in categories such as e-mail, collaboration and video telephony, as well as customer relationship and human capital management.
For the proponents of Network Service Mesh, this is a potentially very attractive working environment.
“Network Service Mesh allows the customer to connect individual workloads, wherever they are running – whether multi-cloud or hybrid cloud – to a service mesh without the complexity of [Layer 7]-Gateways or the orchestration of a single, large, complex, flat [Layer 3]Domain,” said Ed Warnicke, Principal engineer at Cisco’s Office of Open Source Initiatives.
The traditional Application Service Mesh works on Layer 7 (HTTPS) with the main features of Service discovery and routing of HTTPS requests from the workloads to the services. “Network Service Mesh takes some of the ideas of traditional Application Service Mesh and brings them to L3. The most important function is the detection and routing of network services – the connection of individual workloads to ‘network services’ via virtual lines or vWires,” he said.
Basically, Network Service Mesh creates dynamic, flat L3 overlays as needed, on which companies operate a service mesh and into which they can integrate all 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 additional levels of complexity or additional risks,” says Warnicke.
So far, attempts have been made to solve the challenge of multi-cloud communication by either placing all workloads and the service mesh control layer in a single flat L3 network, or using a system of L7 gateways, which in turn reach others via a flat L3 network. According to Warnicke, a flat L3 network is very difficult to arrange in a multi-cloud/hybrid environment, and the L7 gateways are extremely complex to maintain and configure and represent a bottleneck in the system.
Network Service Mesh itself does not offer traditional L7 services. It offers the complementary service of a flat L3 domain that individual workloads can connect to, so that the traditional service mesh can perform its tasks better and more easily in a larger area, Warnicke says.
Network Service Mesh also enables multi-service mesh, i.e. the ability of a single container pod to connect to more than one service mesh at the same time, regardless of its location, according to Warnicke.
Network Service Mesh has identity federation features and approval policies that allow one company to selectively include another company’s workloads in its service mesh, Warnicke said.
The Cloud Foundation cites some typical use cases for Network Service Mesh, including:
- A common flat vL3 domain that allows DBs running in multiple clusters/clouds/hybrids to communicate with each other only for DB replication.
- A single L7 service mesh (Istio/Linkerd/Consul/Kuma) that connects workloads running in multiple clusters/clouds/on-prem.
- A single workload connected to multiple L7 service meshes.
- Workloads from multiple companies that connect to a single “collaborative” service mesh for cross-company interactions.
Network Service Mesh is an open source project of the CNCF, on which a number of vendors such as Cisco, Xored and Ericsson are working, and, according to Warnicke, some implementations are already available. “With the regular release (about every 60 days), more use cases will become available. According to Warnicke, the ‘Istio Extender’ use cases will be released as part of version 1.4 at the beginning of June.
*Michael Cooney is a senior editor at Network World and has been writing about the IT world for more than 25 years.