You can’t run a modern business without connectivity—except when your edge location is remote, not served by reasonable links, or can’t be connected because of security or other business reasons. This blog takes a closer look at the specific challenges related to network connectivity at edge locations and how VMware Edge Compute Stack is purpose-built to address them.
When we look at the existing landscape of solutions for orchestrating virtual machine and container workloads, we assume there will be network connectivity between the management plane and the infrastructure/workloads that rely on it to consume and process data. Unfortunately, that is not always the case. Whether supporting computer vision inferencing applications for worker safety on an offshore oil platform, running process controls on a manufacturing line, or processing bodycam footage and license plate information in the trunk of a police car, edge-native applications continue to proliferate in locations where the level of connectivity available in datacenters and public cloud environments simply isn’t available.
Because there is no one-size-fits-all profile for environments where edge workloads are deployed, you might encounter multiple networking challenges:
Unreliable or unavailable connectivity: In the first installment of this series I mentioned one of our retail customers who observed an average of 10-15% of their stores being offline at any given time. Even in that case, we’re talking about locations in shopping centers that are not remote or hard to access. As you can imagine, this problem is even more prolific when the use case is monitoring a wind turbine in a rural area, or running navigation apps on a marine vessel with little to no connectivity once it leaves the port. In these cases it’s undesirable, if not unacceptable, to have degraded application performance due to a storm impacting rural network facilities, the ship leaving port, etc.
Poor quality network connectivity: In locations where network connectivity is generally expected to be available, the quality of connectivity might still pose a challenge. For both on-prem datacenter and IaaS provider-managed edge solutions, there are often stringent requirements around both the amount of latency that can be tolerated between the edge and management plane as well as the amount of bandwidth required. This is because in either case, solutions designed for a datacenter or cloud assume the presence of performant network connectivity, and there are real implications of those solutions often incorporating vital control plane functions into the management plane.
Secure/Isolated edge networks: Finally, even in edge locations where highly reliable and performant bandwidth is available, edge applications often need to be deployed inside isolated networks with security boundaries that pose a challenge for traditional infrastructure offerings. OT networks in manufacturing facilities, utility substations, and secure enclaves in defense environments are often reachable only via firewalls and/or proxies that highly restrict inbound access to the environment. We recently worked with a food producer that completely disconnects the OT environment during production runs to ensure that nothing can impact product integrity. Additionally, in some cases like franchise retail locations, the edge network may not even be under the control of IT. This poses the risk of IP overlap and other perimeter requirements driving the need to traverse a NAT device, further complicating access from the outside in.
Solving network challenges at the edge
You can see that network conditions pose multiple challenges in edge locations. VMware Edge Compute Stack can solve for each of these individually:
Separation of the management and control planes: As mentioned in our post Scaling Edge Deployments with Central Cloud Management and GitOps, there are certainly benefits to having a unified management plane for edge deployments. But because we can’t depend on reliable/performant network connectivity between the management plane and edge locations means that traditional DC and IaaS models—which incorporate not only the management plane itself, but also important components of the control plane responsible for things like VM/container orchestration, cluster services, etc.—can degrade edge application performance. To solve this, VMware Edge Compute Stack is designed with a centralized management plane (VMware Edge Cloud Orchestrator) that is responsible only for initial provisioning and ongoing monitoring/visibility. All control plane functions, on the other hand, run locally in the edge host runtime, meaning they can continue to provide full functionality even when network connectivity is degraded or unavailable—even for extended periods of time.
Eventual consistency model: When it comes to making configuration changes and deploying workloads to an edge deployment, there are a couple of ways that we uniquely address unreliable and poor quality network connectivity at the edge. The first is the eventual consistency model used in applying the desired state configurations. In the VMware Edge Compute Stack architecture, edge hosts reach out directly to the Git repository where their desired state configuration files are held periodically. In the event that the repository is unreachable, the edge host simply continues to try until connectivity is restored. Since the repository itself isn’t needed for ongoing operations, existing applications and workloads continue to operate normally. Any changes are applied as soon as the edge host can reach the repo again.
Local Git repository: If waiting for a non-deterministic amount of time to make changes is unacceptable, the Git repository for a given edge host can also be deployed locally in an edge location, negating the need for any WAN connectivity to detect/implement changes to the desired state.
Pull-based orchestration: In edge locations where workloads exist in secure/isolated networks, the pull-based orchestration model leveraged by VMware Edge Compute Stack solves multiple problems. To help illustrate this, consider the alternative push-based model that many data center and IaaS models use. In a push-based architecture, some network connections between the centralized management/control plane components need to be initiated from the management plane to the hosts (often due to the timing sensitivity of control plane functions that are centralized in these models). Unfortunately, this causes problems in secure/isolated edge networks. For sites where traversing proxies/NAT devices is required, supporting this kind of inbound connectivity might not be technically feasible at all. Even at sites that need to traverse an OT firewall to reach a network containing Supervisory Control and Data Acquisition (SCADA), process automation, and other OT workloads, there may be security resistance to the idea of opening inbound access in the firewalls to these environments. VMware Edge Compute Stack uses a pull-based orchestration model, which means that all network connections to the management plane and git repository are initiated from the edge host out to those components. As a result, these connections can traverse existing proxies and NAT, and no additional inbound rules in the firewall are required to connect infrastructure in secured edge networks.
Conclusion
As we’ve reviewed, there are actually a number of challenges associated with delivering edge applications due to the networking conditions that prevail in many of the locations where they’re deployed. In addition to the other benefits discussed in our first post, VMware Edge Compute Stack is purpose-built to address these challenges and ensure a simple, reliable, and scalable way to deliver these workloads at the edge.
This blog is part of a series exploring the real challenges of deploying and managing applications at the edge, and how VMware Edge Compute Stack helps companies overcome those obstacles to meet their business goals.
