WebAssembly and Containers

Containers have become ubiquitous for most developers, whether they’re used to run tools or incorporating them into applications. Even embedded systems integrate them. Like hardware virtual machines (VMs) and hypervisors, containers provide a way to modularize and isolate systems so that they’re teasier to create, manage, and secure. Our latest TechXchange: Hypervisors, Containers, and Virtual Machines collects articles about different aspects of VMs, hypervisors, and containers.

At a high level, hypervisors, VMs, and containers are similar (see figure). Each provides an isolated region. However, many variations exist, such as Type 1 hypervisors that don’t rely on an underlying operating system while it’s just the opposite for Type 2. In both cases, isolation is implemented in hardware. Container systems can utilize operating system isolation and security, although there are other ways to implement container-based systems.

Containers on Resource-Constrained Operating Systems

If your project happens to be based on the Zephyr Project, a compact, open-source operating system, then you’re in luck. Most smaller operating systems and RTOSes don’t have built-in support for container systems like higher-end operating systems, including Linux and Windows, for a variety of reasons (see the TechXchange for more details). One of those reasons is more limited hardware memory-management support.

For the Zephyr Project, Atym turned to WebAssembly (WASM) to implement its container system that essentially places the onus on the compiler and language to put applications into a sandbox. The approach isn’t new. Languages like Java and Java virtual machines (JVMs) provide similar security and memory limitations — they prevent errors typically found in C and C++ applications that normally run with few restrictions other than those imposed by the hardware, which is why hypervisors are often needed.

WASM is essentially a virtual machine that will run containerized applications. The applications can be written in a host of popular programming languages such as C, C++, GoLang, and Rust. The main difference between native compilers and those targeting Atym’s containers is the limits placed on them by the VM environment.

Containers and Artificial Intelligence

If you’ve worked with artificial-intelligence (AI) tools, you may have already run into containers. They’re quite common in the cloud and servers with tools like Docker and Podman, as well as even more advanced orchestration tools Kubernetes. These types of tools have been used to manage AI training and deployment in the field, but usually on high-performance platforms like embedded server farms.

Still, AI isn’t limited to the cloud and high-end systems. We’ve been covering edge computing since the term was coined, and AI for inference, which has been possible in software and embedded AI hardware, is now readily available for all platform levels.

The task is usually getting the models to run. Often containers provide that support because it makes development and deployment much easier by reducing the number of dependencies. I’ve run many of the demos on NVIDIA hardware employ containers. It also makes it simpler for companies to deliver a container package that can be more easily tweaked.

So, if you haven’t worked with containers, you might want to take a closer look at what’s available in the space you’re targeting. It may make using AI less difficult.

By the way, your favorite chatbot will likely have suggestions. They come in very handy for system configuration, as they tend to be as arcane as they come and tweaking all of those command line and configuration files can be easy with a little help. At least that’s what I have found.