Edge and cloud orchestration — same same but different (part 1 of 2)

We all are engineers, and as engineers, we are solution focused: “Give me a problem, and I have a solution for it”. But in some cases, we are too solution focused; we are not giving the problem at hand enough consideration. The classic risk attached to this sort of tunnel vision is picking the wrong tool for the job. Another typical human behavior is to search for similarities between issues. We hope that in finding these similarities we will also find a solution. Stacking these two behaviors on top of each other, however, can lead us down a path to non-optimal solutions.

In this series of articles, we will look at the problem of edge orchestration and discuss appropriate solutions. As stated above, a classic risk is identifying edge orchestration as the same “problem” as central cloud orchestration. Sometimes, this happens simply because the term “cloud” is attached to edge like in “edge clouds”. While cloud orchestrators, such as Kubernetes, are often an appropriate solution for central clouds, we would be jumping to conclusions to simply assume that running cloud orchestrators at edge clusters is the best solution for that domain.

Problem: Central cloud orchestration

Since day one, public cloud providers have addressed how to orchestrate workloads in clouds (central data centers). A cloud is characterized by:

• Centralization: There are many hosts in few central locations.
• Virtually unlimited resources: Compute, network, and storage resources can be viewed as unlimited.
• Resource pooling: Resources (compute, networks, and storage) are pooled to serve multiple clients at one time.
• Good connectivity: Network connectivity within datacenters are usually fast and predictable, especially between the control plane and worker nodes in a Kubernetes cluster.

So what is the problem domain for central cloud orchestration?

• Rapid elasticity: Quickly adding or removing compute, storage, and network resources to maintain steady, predictable performance at the lowest possible cost.
• Moveable workloads: Workloads can move between host within data centers between sites to solve healing and scaling issues
• Perimeter security: Data centers are physically secured, and perimeter security addresses most security concerns.

Central cloud orchestrators are designed to address the above use cases and more. But what about edge orchestration?

Another Problem: Distributed edge orchestration

For the distributed edge, we have a different set of characteristics and challenges that need to be addressed by the orchestrator. An edge site is characterized by:

• Distribution: Few hosts in a large set of distributed locations.
• Limited resources: Edge sites and nodes are limited in resources, typically 1-3 hosts ranging from medium servers to Intel NUCs.

The problem domain for distributed edge orchestration can be described as:

• Autonomy: The edge sites should be operational without connectivity to other networks and the central cloud for long periods of time.
• Network limitations: System services that depend on networking, such as message queueing, need to be designed for network outages as well as slow and costly connections.
• Static workloads: Workloads are pinned to the edge locations and do not move. In contrast to the central case, workloads need to stick to the edge site where they are deployed.
• Availability and healing: Availability cannot be solved by moving workloads to other sites, since workloads at the edge need to stay where they are placed.
• Security: Edge nodes often lack strong perimeter security by necessity. Therefore, local data need to be highly secured on the host it resides on..

The above challenges are different than the primary ones of central cloud orchestrators. Therefore, it is important to use an edge orchestrator that addresses precisely these issues instead of employing an inherited central cloud orchestration solution.

Once the problem is understood, we can look at the solution

While central cloud orchestration still has challenges, the problem space has been around for a while and an industry practice around Kubernetes has been established that addresses the relevant problems in that space. But edge orchestration comes with a different problem space, and inferring that a central cloud orchestrator is the best tool for the job would be to jump to conclusions too quickly.

In part 2 of this series we will look at the solutions to address the edge orchestration problem.