Containers On The Edge

IoT devices have seen unprecedented evolution in the last few years in terms of their features and usefulness. However, the IoT devices of today are still largely limited in the functionality that manufacturers assign to each device. In order to get new functionality, you generally need to purchase a new device. This limitation keeps many users away. Device and installation costs can be significant. Think, for example, of built-in lighting or appliances. You don't want to replace them two years after purchasing just to make them talk to a new device in your office.

To enable the next level of IoT engagement, users want devices that can serve a longer and more useful life. Devices need to enable this by being flexible enough to extend or even change their functions once in the field.

IoT Products Aren't General Purpose Computers

IoT devices are turnkey devices where product designers have to decide the hardware and software components that will shape the product during design. And in doing so, they need to account for their various uses during their entire life-cycle. General purpose computers stand in stark contrast. They can be upgraded and repurposed even after being purchased and deployed.

IoT device designers need to size each device's capabilities at the start, looking at the projected end goals of the device as their hardware will hardly ever be upgradeable. On the other hand, their software traditionally sees bug fixes and modest feature changes at best once deployed. One of the design-time decisions is which operating system will run on the device. That decision also influences the ecosystem available to build the software portion of the device.

The Two Major Operating System Families: RTOS-based and Linux-Based 

There are two major families for the choice of operating system and ecosystem: RTOS-based and Linux-based families. Smaller, cost-constrained devices tend to benefit from the simplicity of RTOS-based, while more full-featured and complex devices benefit from the richness of Linux (see The Shift to Linux Operating Systems for IoT for more background on the reasons for these approaches in IoT). Linux has been used in embedded devices for almost as long as it has existed. The focus here is on Linux based products, as they have the needed functions such as access controls and memory segregation that allows for upgrading portions in a controlled fashion.

Monolithic Linux

Linux running in general purpose computers follows a general pattern of using distributions, which are composed of a vast array of software components. A computer deployed with such a distribution can select a set of these software components based on the purpose it serves. So a computer set up as a web server will contain a certain set of software components, while another computer set up as a media center will have a different set of software components installed. These two distinct machines can be built on the same hardware configuration.

In contrast, Linux running within IoT devices—and more generally in embedded devices—tends to be more monolithic. The software components that will be part of the device are pre-chosen by the product designers. They're either unchangeable, or are selectable from a very small set of options (a typical distribution used for general purpose computers has more than ten thousand software components).

There are a few reasons for this. First, hardware resources are constrained due to cost and size. They're made to fit a single intended purpose. It's usually impossible to add functionalities that would require hardware reconfigurations later on. Moreover, given the turnkey nature of these systems, the product manufacturer is on the hook for the full device functionality—both hardware and software. They need to limit the software variants to that which they can test and validate. In contrast stands the general purpose computer model, in which the hardware vendor ensures the hardware works while the software vendors are in charge of software.

Separation of Interests In IoT

Monolithic solutions are all well and good until they aren't. IoT devices are requiring more flexibility, which needs to extend beyond device deployment. As the IoT evolution gains speed, the battles for protocols and functions that the devices have to interact with are going on furiously—from mesh protocols to get neighboring devices to communicate at a basic level, to value-adds such voice enablement and control. New functions, middlewares, and APIs will show up regularly. They'll also disappear almost as regularly until this new environment has more maturity.

Customers can already see the value in IoT devices and are ready to deploy more and more of them, but most are unwilling to rip them out and start over at every new technological wave to hit the IoT shores. Some of these devices are quite costly such as large appliances while others are not accessible or replaceable such as light switches and environmental sensors such as temperature and gas sensors. For IoT devices to be successful going forward they need to have the capability to evolve even after they are deployed.

In order to achieve this, there needs to be a shift from the use of monolithic Linux deployments to a more modular deployment scheme in which at least some portions can be easily added or modified in the field.

One area in which this has happened successfully is in the mobile space. Hardware vendors now provide the platform software that provides all of the basic enablement of the hardware features, but then those vendors leave the user-visible functions to apps from which users can pick and choose. These apps are written by Independent Software Vendors (ISVs) and can be deployed across mobile devices from different vendors.

Next Generation IoT Devices

This positive trend toward a modular deployment scheme needs to gain traction to start bringing IoT devices into the next generation. Such a pivot will require both business and technical changes to the current model. From a business perspective, hardware vendors have to start enabling third parties to add features to their devices by creating both a deployment model and devices that have sufficient resources to allow new features into the field.

From a technical perspective, the good news is that we already have a model to follow for this next generation. We just have to look toward the world of servers for ideas.

The last few years have seen major disruptions in the server model. The transition continues toward containerization, in which light-weight and self-contained software components can be built and packaged in nearly complete isolation from the underlying hardware to which they are eventually deployed.

Containerization has all been enabled by a Linux technology many years in the making called cgroups. They allow for a rich set of vertical solutions to be created by ISVs. They can be easily deployed in any number of different scenarios—from traditional physical servers all the way to serverless deployments wherein the underlying hardware is completely virtualized and can change from one execution of a container to the next.

Image Credit: Flickr

Transitioning to a modular and container-based platform allows new products to solve several long-standing issues with the traditional monolithic approach. The base platform retains the Operating System (OS) and very basic building blocks, such as container management tools. All other functions are available through modules. These modules can come from both the hardware vendor and third parties.

Upgradeability

Todays' IoT products suffer from a lack of upgrades, for both features and bug fixes. A major reason for that lack is that monolithic platforms have deep cross-dependencies. Even small upgrades require significant testing and are fraught with risk. Who wants a tweak to their UI to potentially brick their product? By moving to a modular model, individual modules can be upgraded independently. This reduces the test-surface for a module release and narrows the scope of eventual problems with upgrades.

Minimization of Dependencies

Modules interact with each other only through well-defined APIs and are otherwise independent. Each module is then free to pick and chose their internal building blocks. These can be middleware, libraries, and/or compilers. One module can then upgrade or fix a library without affecting other modules that depend on the same library. 

Granular Deployment Cadence

Modules are deployed as the need arises. Users or vendors can choose this deployment based on evolving needs. This increases customer satisfaction and loyalty. When they purchase a product they'll know that not only their current but future needs can be accommodated.

IoT Container Hub

In addition, ISVs need a way to provide their verticals to these IoT devices. This can be done in a way similar to docker hub, or one of the mobile device app stores. Hardware vendors should allow feature-add ons through this hub. This will make it feasible for other groups to add richness to the next generation IoT platforms.

Image Credit: Pexels

Where We Are Today

Some IoT platforms have taken steps already in this direction. Here are a few examples:

EdgeX Foundry

EdgeX is a container-based middleware environment. It provides pre-existing services such as DB, security, logging, etc. and also has an SDK to allow new services to be created. It's still in the development stage, however, it looks like a promising platform for IoT development.

EdgeX's early releases have suffered from a footprint too excessive for most IoT devices and systems. Lately, the team has been spending more energy on getting the services footprint smaller. It's a project to watch as a possible base for containerized IoT platforms going forward.

Ubuntu Core

Ubuntu has long been a traditional Linux distribution. It has attempted time and again to gain entry into the embedded engineering space. Their approach tends to shoehorn the traditional distribution model into something more "embedded-friendly."

Ubuntu Core is their latest attempt at this. Originally created for the server space, they're now offering it as a solution for the IoT space as well. It relies on the migration from the traditional deb packages used in distributions to snaps.

While a package provides a container to isolate the binaries, configuration and setup scripts that provide an app or service into build-time units, Ubuntu Core doesn't provide any isolation at runtime between the packages. Snap goes a step further to use cgroups to extend this isolation between the packages to runtime, minimizing their cross-talk and dependencies on middleware such as system libraries.

Image Credit: Bernard Spragg via Flickr

What's Next?

While the current options are steps in the right direction, they insufficient for next-generation IoT devices. We're still missing a path for ISVs to engage with IoT devices in a way that works for them.

From a technical perspective, there are missing items such as:

• Modules need abstracted access to the necessary hardware components
• Platforms need to restrict the number of resources available to modules
• A path for ISVs to make these modules available to customers (e.g. a hub or app store)

From a business perspective, monetization is key. The first modules will come from companies that are already in the ecosystem (because they already have a business model). They can use modules to enhance their products by better interacting with other products in the ecosystem. Independent ISVs will need a way to monetize before they can engage though. IoT devices will have limited ad-driven monetization, so new forms of revenue must come into existence. Product vendors can view certain modules as valuable enablers and choose to compensate the ISVs directly. And end-users will be able to purchase some functions directly. These are the traditional paths to monetizing and, as with any new technology, new ways of monetizing will be created.

In summary, we need a new IoT-centric platform for new IoT devices. This platform needs to provide container-based modules to segregate and manage the device functions. Having such an IoT platform will enable the hardware and software teams and companies to focus on what they do best.