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

As described in the previous article in this series, the functional requirements and characteristics for edge orchestration and central cloud orchestration are different. This article looks at the different functional requirements and how they impact the solution for edge orchestration.

Application orchestration

The term “orchestration” has become overloaded. In the context of this article, we focus on application orchestration: automating the application lifecycle that happens after the CI/CD pipeline, when the containerized applications are stored in a registry. The orchestrator is then responsible for the following tasks:

• Deploy: Getting the applications to run where they should.
• Monitor: Observing the health of the applications.
• Maintain health: Healing and scaling application deployments.
• Upgrade: Keeping applications up to date.

To perform these tasks, the orchestrator needs to provide a mechanism so that the application owner can specify:

• Which containers constitute an application, application-specific configuration, and policies for deployment.
• Where the applications should run.

Distributed edge orchestration

Edge sites need to be operational without connection to a central orchestrator since network connectivity to edge sites is often unreliable. Decisions need to be made locally in such situations, which implies the need for a local control plane per edge site.

Therefore, a distributed edge orchestrator consists of two parts: a central orchestrator and, for each edge site, a local edge orchestrator:

Distributed edge orchestration = central edge orchestration + local edge orchestration

If a developer with a containerized application wants to run the application at specific edge sites, they need to communicate the application specification and placement policy to the central orchestrator.

• The application specification should define which containers constitute an application, as well as application-specific configuration.
• The placement policy should describe on which edge site or group site the applications should run.

At this stage, the central orchestrator can deploy the application to the edge sites. After that, the edge orchestrator manages the edge application lifecycle at the site.

We will now look into the following questions:

1. Which functionality is needed for the central orchestrator?
2. Which functionality is needed for the local orchestrator running at each edge site?

Central orchestration

The main functional requirements for the central orchestrator are:

• Application deployment at edge sites: When deploying applications, the central orchestrator uses declarative specifications to ensure that all needed configurations, secrets, certificates, tenant configurations, and images are installed at the site. These specifications describe the desired states of edge sites, which the orchestrator then tries to achieve and maintain. Fine-grained declarative policies control where the applications are placed.
• Managing the local edge orchestrators: Since a local orchestrator is running at each edge site, the central orchestrator needs to manage these. This includes lifecycle management, monitoring, system upgrades, and so on. However, in case of network outages, edge sites should be able to run autonomously without connection to the central orchestrator (although with limited functionality).
• Central monitoring of the edge sites: Operations teams need a central view of the application health on all sites, proactive monitoring needs to be in place to detect issues on sites, and in the case of issues, drill-down tools need to be in place to understand the underlying problems.
• Edge multi-tenancy: Different organizations might need to share the edge resources. Therefore, the central orchestrator needs to have an efficient mechanism to separate the resources on the edge sites across the organizations.
• Distributed secrets management: Secrets such as keys, passwords, and certificates need to be centrally managed but distributed to the edge sites in a secure manner. The security mechanisms also need to ensure that secrets are kept secure at the edge sites. Central threat mechanisms need to be in place as well (for example, an operation to lock down an edge site to protect the data on the site).
• Distributed event streaming: An event-streaming service optimized for edge computing has a few extra requirements in addition to those of cloud-oriented systems (such as Kafka or Pulsar). First, it needs to continue accepting messages even if network connectivity to the outside world is broken, even if that is for long periods of time. Second, it needs support for producing to and consuming from topics at edge sites located behind NAT firewalls. Third, it needs to be able to process very fast queries over application logs for a large number of edge sites.

One could argue that secrets management and event streaming are functions not usually found in an orchestrator. However, including such application-level services, which are deployed at each edge site, into an orchestration platform has clear advantages: there is no need for the user to install, configure, or upgrade these services on a large number of edge sites – this is handled automatically by the orchestration platform*.*

An overall requirement is also that the central orchestrator should integrate to CI/CD pipelines to support full automation all the way to running applications at the edge.

Local edge orchestration

The local edge orchestrator needs to create a replication cluster between the edge hosts. Important state information and container images need to be replicated between the hosts to manage local healing scenarios.

The local edge orchestrator is responsible for networking within an edge site. It should automatically create a local secure network that can be used both by the cluster control plane and the applications. This network should allow for secure encrypted communication of the control plane and between the application instances. In addition, the local edge orchestrator should support the management of connections to the central orchestrator, ingress networking, and DNS to enable application discovery.

A key responsibility of the local edge orchestrator is managing the application life cycle at the edge: to be able to keep the applications and their containers working and manage any requests from the central orchestrator for new deployments or upgrades. In coordination with the central orchestrator, this should be supported at the application level, not just for individual containers making up applications.

The local edge orchestrator needs to manage local secrets. Edge sites might be vulnerable to intrusion as well as theft. Data needs to be encrypted and secured locally. But as described above, these secrets need to be managed and distributed from the central orchestrator. Keys for encryption also need to be auto-rotated.

A prerequisite for the healing and lifecycle management functions is that the local edge orchestrator monitors the application and container health as well as the host resource usage. The monitoring results in local actions, for example, container restarts, as well as events forwarded to the central orchestrator.

Finally, sites might be shared between different tenants. In conjunction with tenant policies in the central orchestrator, the local edge orchestrator needs to enforce resource policies so that different application tenants do not starve each other.