The technology developed by the Cloud Native Computing Foundation (CNCF) connects enterprise multicloud tasks at the network layer, wherever they take place.
Networking enterprise multicloud workloads can be complex and time consuming. But the open source Network Service Mesh project under the auspice of the Cloud Native Computing Foundation, a Linux Foundation entity, could change that. His ambition? Securely communicate with each other, cloud-based Kubernetes workloads, regardless of the cloud in which they run. And the demand for such technology continues to grow. According to a recent study released by Cisco, companies with 5,000 or more employees are likely to use more than 10 public cloud providers and 20 to 100 SaaS providers in areas such as email, collaboration, and video calling, as well as managing customer relationships and human capital. This is a potentially rich target environment for Network Service Mesh advocates. “Using Network Service Mesh technology, the customer can connect individual workloads, wherever they run – multicloud or hybrid cloud – to a service mesh without the complexity of Layer 7 gateways or the need to orchestrate a single domain. Single , large, complex, and flat Layer 3, ”said Ed Warnicke, Principal Engineer Office of Open Source Initiatives at Cisco.
A standard application service mesh works at Layer 7 (HTTPS) and has the basic features of service discovery and routing HTTPS requests from workloads to services. “Network Service Mesh takes some of the principles of traditional application service mesh and brings it down to the L3 layer. Its primary function is to provide network service discovery and routing, i.e., to connect individual workloads to the Network Service using virtual wires or vWires, “said Ed. Warnicke. The Network Service Mesh makes a flat , dynamic, on-demand L3 overlay where enterprises can run a service mesh where they can connect any allowed workload. ”Ultimately, teams can choose the best option for running their workloads – in multiple clusters, in legacy environments, on -premise, or in public clouds – without having to add additional layers of complexity or introduce risk. extra, “said the Cisco senior engineer.
Open network containers
Until now, attempts to solve this multicloud communication challenge typically involved either placing all the workload and the service mesh control plane on a flat L3 network, or implementing a system of gateways. The L7s connect themselves to a flat L3 network. According to Mr. Warnicke, flat L3 networks are very difficult to configure in a multicloud/hybrid environment, and L7 gateways are extremely complex to maintain and configure and represent a bottleneck in the system. “Network Service Mesh does not provide traditional L7 services. It provides the add-on service of a flat L3 domain that can be connected by individual workloads so that the traditional service mesh can do what it does, better and easier, in a larger span, ”explained Ms. Warnicke. “Network Service Mesh also enables multiservice meshing, which is the ability for a container to simultaneously connect to more than one service mesh, regardless of its location,” Warnicke added. “Network Service Mesh has an identity federation and admission policy feature that allows an enterprise to choose to accept the workloads of another enterprise in its service mesh,” Mr. Warnicke.
Common cases of using Network Service Mesh technology, which the Cloud Foundation specifically mentions include:
– A common flat vL3 domain so that databases running in multiple clusters/cloud/hybrids can only interact with each other for database replication.
– Single L7 service mesh (Istio/Linkerd/Consul/Kuma) to connect workloads running across multiple clusters/cloud/on-prem.
– A single workload that connects multiple L7 service meshes.
-Multi-enterprise workloads that connect to a “collaborative” service mesh for cross-enterprise interactions.
Various vendors, including Cisco, Xored, and Ericsson, are working on CNCF’s Open Source Network Service Mesh project. “A number of implementations are already available,” Wernicke said. Every 60 days, a new version will be released. “As versions are released, new use cases become available. The ‘Istio extender’ use cases are expected to be shipped in early June along with the upcoming 1.4 release, ”Warnicke said.