The use of containers is becoming mainstream in the development of embedded computing and IoT devices. This means that more and more embedded developers are faced with the task of orchestrating a set of containers for their hardware target. Once a design reaches production, they need to perform functions such as deployment, scaling, load balancing, logging, failover, and monitoring of containers.
Ready-made systems for performing these functions exist in the enterprise computing world: Kubernetes, maintained by the Cloud Native Computing Foundation, and Docker Swarm. But how well do they work in the embedded world?
For various reasons, not very well, and there is a better alternative.
Let’s explore the options.
Perfect for a data center
To understand the drawbacks of Kubernetes and Docker Swarm, it is helpful to know their genesis. Kubernetes was created by Google to manage the billions of containers which form applications such as Maps and Meet; it was then made available as open-source software. Google’s applications run on gargantuan racks of servers operating in the precisely controlled environment of a data center. One of the functions that Google built into Kubernetes was balancing the compute load across a networked array of hardware resources.
Docker Swarm is similarly optimised for the management of containers in a server-based enterprise computing environment.
This environment is clearly the polar opposite of an IoT device, which is normally a stand-alone unit rather than part of a distributed computing resource. Unlike a data center’s server, it is also subject to intermittent interruption of its network connection, and potentially its power supply, and has highly constrained memory and compute resources.
Supporting the outsize features and capabilities of Kubernetes or Docker Swarm in a constrained IoT device exposes it to a host of risks and dangers. So while the large pool of developers who are familiar with Kubernetes or Docker Swarm might make it seem appealing to embedded device OEMs, in practice, attempts to use these platforms in the embedded world will tend to quickly be consumed by difficulties.
Troublesome update deployment
One manifestation of the non-alignment between Kubernetes/Docker Swarm and the IoT is in the deployment of firmware updates. Kubernetes and Docker Swarm are optimized for an environment in which power, compute and network bandwidth are effectively unlimited. So they adopt a synchronous mode of deploying firmware updates, requiring their simultaneous adoption across all devices.
This is impracticable for fleets of IoT devices, which can suffer from connection outages, or be held in sleep or hibernate mode for long periods. This means that over-the-air updates to IoT devices need to be asynchronous, allowing different devices to log in and download the update at different times.
The second problem for users of Kubernetes or Docker Swarm, which require the maintenance of an open port to external devices, is security. In a data center, a server with an open port is protected by multiple layers of physical and logical security, from the barbed wire fence and guarded entrances which limit access to authorized personnel, to the grid-independent back-up power supply which ensures that no server suffers from an unplanned shutdown.
These features are essential to the secure and reliable operation of Docker Swarm and Kubernetes, but none is available to an IoT device. The security of an IoT device relies on its own resources. External software such as an upgrade package cannot gain access via an open port, but has to pass securely encrypted barriers which guarantee the software’s authenticity.
An IoT-native option for container orchestration
Users of the FoundriesFactory® platform benefit from a solution which does not entail the top-heavy, oversized resources of Kubernetes or Docker Swarm. Built into the FoundriesFactory system is support for a container utility based on the open-source Docker Compose system.
In the FoundriesFactory platform, container updates can be deployed flexibly and asynchronously. The Compose-based utility is also robust, featuring methods for minimizing the risk of code corruption in the event of a power or connection fault, and providing for fail-safe recovery if corruption occurs. The FoundriesFactory software also includes a function called ‘Reset app’: if an app gets corrupted, the function retains a local copy which can replace the corrupted version, enabling the IoT device to be reinstated after it suffers a power failure that would disable Docker operations.
Crucially, the Compose-based utility in the FoundriesFactory platform is easy for developers who are familiar with Kubernetes or Docker to learn, as the terms and services are described and operate in a very similar fashion.
So while Kubernetes and Docker Swarm can seem superficially attractive for container orchestration because of their broad use in enterprise computing, they are inappropriate for embedded and IoT devices – and a much better IoT-native alternative is available to users of the FoundriesFactory platform.