Edge series - Mirantis: Managed edge is a fleet management problem, not a platform slogan
This is a guest post written for the Computer Weekly Developer Network by Dom Wilde in his capacity as SVP and GM for cloud infrastructure business at Mirantis.
Mirantis is known for its enterprise open source cloud services, specialising in managed Kubernetes and OpenStack platforms that allow software engineering teams to build, deploy and scale applications across multiple clouds.
Wilde writes in full as follows…
Edge computing has become an enterprise operating model. Organisations now run applications across factories, stores, telecom sites, and vehicles i.e. anywhere compute must stay close to users, devices, or data.
The hard problem is no longer whether software can run outside a datacentre; containers made that practical years ago. It is how to provision, update, secure, observe, and govern many sites that differ in hardware, network conditions, operational constraints, and regulation.
Kubernetes helps by providing a common declarative model: at each site it manages containers, maintains state, and exposes standard APIs; across the estate, a management layer defines cluster types, services, and policies once, then applies them to groups of sites.
Edge is thus a constrained form of the hybrid, multi-cluster Kubernetes problem, and part of the secure-and-compliant one – best solved by extending the methods an organisation already uses, rather than inventing new ones.
Match Kubernetes to the site
Edge sites do not all need the same footprint.
A site may run a full local control plane, a compact single- or multi-node cluster, or remote workers attached to a hosted control plane. The right design depends on what the site must keep doing when networks or central services are unavailable.
A worker that loses contact with its control plane does not necessarily stop running existing pods; the local runtime may keep them going. What it loses is coordination – scheduling, reconciliation, configuration changes, and recovery – all of which need the Kubernetes API. A site-local control plane preserves more of this during a WAN outage; a hosted control plane cuts the footprint but increases dependence on connectivity, which suits datacenters or clouds serving many remote workers.
The real question is therefore not “connected” versus “disconnected”, but which capabilities each kind of failure – lost control plane, lost WAN, lost upstream dependency – actually removes.
Manage the estate declaratively
Mirantis’ Wilde: A managed edge platform is one that survives the failures you specify, reconciles when connectivity returns and can always report what ran where.
Once Kubernetes is running, the harder problem is managing the clusters themselves.
Sites fall into classes – by architecture, accelerators, network topology, location, or regulatory domain – and those differences belong in templates and placement rules, not local exceptions.
The platform should provision clusters and services declaratively, assign policies to groups of sites, and keep an inventory of hardware, versions, workloads, and certificates. Changes should be staged – update a cohort, observe, expand, reverse if needed – and the platform should detect drift from declared intent and correct it once a cluster is reachable, staying authoritative without running its full mechanism at each site.
Local autonomy is not uncontrolled administration: it must still define who can change clusters, which artefacts may run, and what evidence is kept for audit.
Security & compliance as ops requirements
Edge sites may be physically exposed, lightly staffed, and spread across jurisdictions, so one fleet can cross national, customer, and data-residency boundaries.
Security and compliance therefore have to be expressed as policy attached to clusters, services, workloads, and data flows, with controls for identity, admission, network access, secrets, signed artefacts, and provenance.
Organisations also need to reconstruct past state: which version and policy were active at a site, which change caused a failure, and whether the site reconciled after reconnecting. A managed platform should answer those questions across the fleet without treating every location as a separate system.
Add AI where the application requires it
AI and ML add placement and governance decisions, but do not replace the underlying edge-management problem. An application once written as local code may now run a classifier at the site, call a model in a regional facility, or hit a central service – each with different latency, cost, data sensitivity, and failure behaviour.
A local model preserves responsiveness during an outage but is another artefact to distribute and update; remote inference keeps large models off every site but needs policy-based routing between local, regional, sovereign, and central endpoints. Selection may turn on data classification, jurisdiction, approved model lists, capacity, or cost, and the same policy should govern what data leaves the site, what is logged, and whether it may be used for training.
Define ‘managed’ by the outcome
A managed edge platform is one that survives the failures you specify, reconciles when connectivity returns, and can always report what ran where. It should also preserve architectural choice: open source foundations reduce dependence on a single hardware vendor, cloud, orchestration layer, or proprietary management model.
Mirantis provides this through the combination of k0s, an open source lightweight Kubernetes distribution for edge and distributed environments, and k0rdent Enterprise, a declarative platform for managing clusters, services, policy, lifecycle, and observability across heterogeneous infrastructure.
