SMART CITIES

The rise of the IoT is shifting the focus of design efforts away from hardware toward software. This creates an opportunity for IoT developers to embrace DevOps principles, which emphasize rapid iteration and deployment.

But applying DevOps to IoT can be challenging. Until recently, embedded developers had a hardware-centric view of the world. “They were born into a world where you optimized every single byte of RAM,” said Thibaut Rouffineau, vice president of marketing at Canonical. This approach is fundamentally incompatible with the DevOps philosophy of accelerated delivery.

In contrast, today’s IoT developers often come from an IT software background, where concepts such as agile and DevOps are the norm. They view hardware as a risk to be managed, rather than an asset to be optimized—but this mindset doesn’t always suit embedded design.

For example, if a server goes down, the IT solution is to initiate a new instance on another server. Problem solved. This approach doesn’t translate easily to the IoT world, where hardware is already deployed and can’t be replaced quickly.

To bring these worldviews together, Rouffineau outlined nine practical DevOps lessons for IoT device builders that all can support to some degree or another, regardless of background.

1. Standardize Where Possible

The first rule of DevOps for the IoT is to use standard hardware if at all possible. Rouffineau gave the Bluetooth-enabled Intel^® NUC, based on an Intel^® Atom^™ processor, as a good example of a standard, compact hardware platform to base an IoT design on. “It’s good for Bluetooth hotspots, digital signage, and industrial IoT gateways, and it’s very versatile,” he said. IEI Integration Corp. used the NUC as the foundation of its TANK-801-BT fanless embedded system (Figure 1).

A developer may save $50 on a more optimized board, but it’s not worth it, said Rouffineau. Also, the NUC is “quite well powered with headroom to run future applications.” This scalability is critical as customers are coming with more advanced applications, incorporating artificial intelligence (AI). It can also be used as both a development and production platform.

The principle of standard hardware also applies to software. Rouffineau recommends the use of standard, certified operating systems out of the box, such as Ubuntu. “Why have complexity when you can have simplicity?” he said. Having Ubuntu means having ready tech support for as long as the OS is in use.

2. Use the Right Development Tools

According to a Canonical study, 68% of IoT professionals are struggling to hire employees with the right IoT skills. But, according to Rouffineau, the problem is they’re looking for such a broad swath of skills, from back-end coding to hardware and business savvy, that it’s nearly impossible to get one person to do all of it.

The simplest solution is to use a standard Linux development environment, he said, as this makes it easier to form a team with the diverse skills needed. Plus, it easier to develop and deploy when the environment matches the OS on the devices. This compatibility simplifies coding and debugging, and avoids the need for a full-stack developer that might be doing node.js for rapid development, and then coding in C for optimization.

3. Reuse Code

“Code reuse is one of the beauties of doing IoT in a new way, especially with Linux,” said Rouffineau, citing Nextcloud’s private cloud storage as an example.

Nextcloud wanted to develop a small-appliance version of its storage solution. By reusing its Ubuntu-based cloud software, the company was able to create a Raspberry Pi solution in only three months.

4. Use a Replicable Build Process

The problem with Linux is that developers start baking their own image, modifying variables such as applications, shared libraries, and device drivers. “Now you have an image that depends on who builds the image and how they decided to build it,” said Rouffineau.

To circumvent this, Canonical developed Ubuntu Core, which packages software in “Snaps” (Figure 2). These packages ensure that software has certain characteristics, such as:

• They’re immutable, so they’re read only.
• They can be traced and authenticated, so they can be downloaded from a store.
• They are easy to upgrade.

One of the advantages of Snaps is that a developer can split the image based on where the code came from. For example, the kernel and device would come from the chip manufacturer or OS vendor and would be split from the OS, which in turn is split from the application packages sitting on top. The entire structure can be managed using Ubuntu Core from a command line.

5. Automate the Build Process

“This is where we want to get to from a DevOps standpoint,” said Rouffineau, versus a command line instruction for each build. To do this, the code is pushed to a hub, which builds it for different architectures, and then distributes it to the device.

6. Distribute Code Automatically

“There’s no really good, universal mechanism to distribute software in the embedded space,” said Rouffineau. DevOps solves this problem. Using Ubuntu Core, the process starts with putting the update in a Snap—and only the update, not the entire code, to avoid sending large files (Figure 3).

Next, the original Snap and its data are backed up on the target device. If something goes wrong during the update, or something is detected when testing the upgrade, it’s simply a matter of rolling back to the original data and Snap.

7. Build Security for the Long Run

Automatic distribution is particularly important for device security. A Canonical study showed 57% of respondents expected security to be handled by the service provider or device manufacturer.

While a device may have all the vulnerabilities addressed when it is first deployed, just wait. After a year, there will be up to 450 more vulnerabilities in the Linux kernel alone.

“DevOps really don’t think about this as it’s taken care of automatically by live patching,” said Rouffineau. “Why not apply the same mindset here?” All the security patches can be deployed automatically using Ubuntu without having to dedicate anyone to address security.

8. Accelerate the Build, Deploy, Test Cycle

DevOps processes can be used to continually update devices and fight obsolescence. “You can even beta-test your software on some key customers,” said Rouffineau. Using DevOps best practices, devices can evolve once deployed, long after the device has been shipped to the customer.

9. Pivot Like a DevOp

“Start with the value proposition for your service, then evolve, evolve, evolve, as the customer demands,” said Rouffineau, until the perfect product emerges. With drones as an example, drone hardware was “a race to the bottom,” but by adding software services they become a much better value proposition (Figure 4).

Now, drone providers can sell software services for the long term, and even encourage third parties to create applications to run on the drones. Or they resell the data coming from a drone, which all makes a provider much more valuable and less likely to be replaced by lower-cost hardware.

In this new world of IoT DevOps, it’s possible to start with standard hardware and get to market faster, more securely, and more reliably. Most important, you can retain customers for the long term instead of depending on one-off hardware sales. It’ll take a mind-shift for embedded developers, but the benefits are worth it.

To learn more about this topic, watch the webinar “Building an IoT Device Like a DevOp.”