Posted by Carsten Lehbrink

The rapid growth of Internet of Things (IoT) devices underscores the necessity for their efficient and reliable management. As the number of these devices surges into the billions, understanding the evolution of device management becomes pivotal. By tracing back the history of traditional server installations, we can glean insights into the future of IoT device management.

A Brief History of Server Management

Initially, servers were managed manually, a method prone to errors, demanding individual device access, typically via SSH. This tedious approach is surprisingly still in vogue among some IoT firms with smaller fleets of devices and the cause of continuous frustration. To streamline this process, the "Golden Images" strategy emerged for server installation, setting a standard starting state to reduce manual interventions. However, the game-changer was server automation, with tools like CFEngine leading the charge, followed closely by Chef and Puppet. This allowed to configure servers in a fully automated way thus allowing a very small team to manage thousands of servers in a defined manner.

With Docker's advent and cloud computing's growth, the paradigm shifted to disposable infrastructure. Instead of merely tweaking servers and workloads, they were rebuilt from scratch using fresh container definitions. So no history is kept which forces engineers to encode all configurations properly. This makes disposable infrastructure very scalable and portable.

Drawing Parallels with IoT

How does this relate to IoT? Well, it appears that IoT is evolving through similar stages, though I'd argue we haven't reached a point of disposable IoT devices yet. The core challenge for IoT revolves around updating devices in a secure, reliable, and efficient manner. This effectively eliminates manual SSH as a method. However, when we delve into the specifics, IoT exhibits a wide range of requirements.

Take, for example, a basic CO2 sensor designed with a microcontroller and a connectivity link. All these sensors have a consistent setup and a uniform software foundation. This situation is ideal for implementing a full image update, which is indeed the most suitable method for such devices. The device's memory gets flashed with the latest firmware. Though the methods might vary, contemporary MCU management platforms often facilitate an A/B update mechanism.

Now, let's shift our focus to advanced IoT devices operating on a more comprehensive Linux OS. If they share the same code foundation, an A/B image update might be appropriate and often is the industry norm. This is evident in our mobile phones. While they do have a separate data/application user space, the primary software is uniformly updated since all phones function on a consistent code base (with applications stored elsewhere).

However, executing full image updates in IoT can be challenging and comes with a significant risk of malfunction. Thus, careful strategies are essential to mitigate these risks. This brings us to another pertinent point. While many of us eagerly await the latest phone update, there's no real incentive to update a perfectly functioning industrial measurement device, especially if it's certified. In such cases, updates may only be necessary to fix bugs or OS library security issues. These are usually restrained to one file or package.

Risks and Alternatives to Full Image Updates

When assessing the risks and implications of updating the full image for tens of thousands of devices due to minor issues in one OS library or a minor calculation bug in a rarely used function for instrument readings, it might not seem worth it. Instead, a more targeted, surgical intervention is preferred. IoT device management platforms like qbee.io cater to this need. They not only support full image updates but can also replace a single file or library. This broadens the strategic avenues for IoT management allowing you to update software or OS libraries without doing a full image update.

Moreover, IoT systems frequently require a customized approach due to their inherent need for individualization and environmental or equipment awareness, such as interacting with electronics, drivers, or Modbus devices with varying IP addresses and coil values, among other factors. It's common to find long lists of essential configuration values for specific edge IoT devices based on customer, location, installed hardware modules or more. These configuration values are usually stored in third party systems (let's all hope this is not Excel). In such cases, the practical approach is to introduce supplementary configuration through an API that links the device management system to the third party system or ERP and fetches the configuration values from there. Additionally, many businesses employ a strategic upsell model to gradually enhance the functionality of machines or measurement tools. At qbee, this challenge is addressed through templating, which facilitates the use of tailored software, scripts, and configurations with data coming from other systems. This approach allows to detach the program logic (the script or software) from the configuration. Thus the software can be updated independently of the configuration and vice versa. Dividing this yields a huge improvement in operational efficiency and stability and also opens up for on-demand business models or feature unlock strategies.

As mentioned earlier, disposable infrastructure is not commonly found in IoT devices, especially at the OS level. However, containers are becoming increasingly prevalent and facilitate the transfer of workloads to those. Therefore, it's vital that the IoT device management platform you select for your project is equipped to handle this, should the need emerge or if you see the advantages of offering containerized software. 

In Conclusion

Navigating the complex world of IoT systems requires a discerning eye, especially concerning update and configuration strategies. Key considerations include:

• Full Image Updates: Suitable for major changes but pose higher risks

• Pin Point Updates: Target specific software or OS libraries, offering lower risk and need less bandwidth.

• Container Updates: Gaining popularity, often seen in hybrid models with native OS and base applications and additional containers.

• Templating: A frequently overlooked function, templating facilitates workflows and new innovative business models by dividing software logic and configuration.

Choosing the right IoT device management platform is a strategic imperative. Companies attempting DIY solutions often grapple with high costs, scalability issues, and security vulnerabilities, all while being overly reliant on individual expertise. It's wiser to channel resources towards enhancing the unique value of products or services.

In summary, while IoT management's journey echoes server installations' evolution, its unique challenges demand innovative solutions. Making the right strategic choices today will shape the IoT landscape of tomorrow.