The future of IoT cloud services in enterprise IT

Over the past two years, high-profile IoT services such as Google IoT Core, IBM Watson IoT Platform service and Arm’s Pelion unit have been closed or restructured. The latest evidence of this trend appeared on February 14, 2024, when an erroneous system message appeared on Microsoft’s Azure console: “Azure IoT Central will be discontinued on March 31, 2027.” In a Feb. 16 IoT blog post, Microsoft clarified the situation: “The message is incorrect and was presented in error.” The company emphasized that any such product recall will follow the standard Azure service notification process, including a three-year advance notice period.

Regardless of the future of Azure IoT Central, Microsoft customers have three years to react, so there is no immediate business impact. However, sudden end-of-life events and rumors of decommissioning remind us that IoT services are a work in progress as enterprise operational technology environments move closer to mainstream information technology systems. In this new OT/IT converged world, data analytics, including AI training and inference applications, leverages data from all sources – IoT and non-IoT. Thus, enterprises are beginning to question the need for IoT application environments that are separate and distinct from IT systems. However, OT equipment has unique characteristics that require specialized services to develop, deploy, and operate fleets of connected devices on an industrial scale. Choosing these services is a key architectural decision in any IoT deployment, so let’s ask the obvious question: As IT and OT computing environments converge, what specific IoT services do businesses really need?

Bringing order to the IoT Wild West

Until recently, the Internet of Things was like the Wild West. Together, Gunslinger engineers (including myself) hacked together end-to-end solutions using custom, stripped-down device hardware, one-off device OS configurations, firmware written in Cu, ad-hoc security architecture, cloud services with low-level APIs, and intricate integrations with business data and applications. No wonder the success rate for enterprise IoT projects has remained disappointingly low over the past ten years. (Analyst estimates range from 12% to 30%, depending on industry, strategy, company size and other factors.)

Over the past ten years, IoT cloud services have sought to bring law and order to the Wild West of IoT solutions by offering fully integrated, secure, end-to-end computing environments spanning three main areas of IoT software development:

1. IoT device software — OS, networking, security and application development
2. IoT data and device middleware — Device management, data entry, collection, filtering and analysis
3. IoT solution services for enterprises — Development of IoT-oriented solutions, analytics and export to business systems

An integrated set of services that simplifies end-to-end IoT is a compelling proposition. “Put all your IoT problems into our world and we’ll take care of everything for you.” Unfortunately, there is no one-size-fits-all IoT service. Each vertical industry requires unique devices, data structures, and solution architectures. Therefore, the above services require extensive customization for each customer situation, the cost of which often exceeds the savings from using a pre-integrated solution. To better understand the future of IoT services, let’s break down each of the three focus areas and predict which add long-term value – and which don’t.

IoT device software

IoT platforms have limited memory, storage and computing power. These limitations force most OEMs to construct the entire device software stack themselves, customizing each product’s OS, drivers, network stack, and security functions. System development is expensive, developers with the necessary embedded engineering skills are rare, and supporting unique configurations for each product throughout its lifetime creates significant technical debt. The solution to this problem is to make the IoT software development process more similar to development for mainstream PC and smart platforms. Using IoT platforms as-is instead of building new ones eliminates undifferentiated system development and allows developers to focus on creating value-added applications. This approach is increasingly practical as new generations of SoCs support larger software stacks and as “device platform as a service” offerings automate OS customization. The savings in development and support costs outweigh the increased silicon costs, especially for small industrial products, so we’re on the verge of a big change in embedded product development.

For microprocessor-based platforms, IoT DPaaS offerings simplify customization and create custom Linux microPlatform distributions that can be continuously updated. For many device types, developers can assemble plug-and-play application components using Docker or other container technologies, allowing OEMs to focus on value-added software without worrying about the underlying computing platform. Foundries.io’s FoundriesFactory is a great example of a DPaaS that automates system development, providing a maintainable custom OS with minimal cost and effort.

For microcontroller-based platforms, the extreme limitations of memory, storage, physical size, power consumption, and real-time performance require a more diverse set of specialized operating systems. There is no LMP equivalent, but Zephyr (Linux Foundation) and FreeRTOS (Amazon Web Services) have significant market share, and dozens of commercial and open-source alternatives offer specialized capabilities. While the MCU OS space is unlikely to unify anytime soon, companies like MicroEJ offer application virtualization environments that allow developers to write platform-independent code that runs on devices preconfigured with OS and firmware and drivers specific to silicone. For example, NXP and MicroEJ have partnered to provide container-ready platforms based on NXP’s MCU portfolio.

Regarding our question about what IoT services we need, DPaaS services turn embedded MPUs and MCUs into platforms with standard networks, protocols, and operating systems that can run containerized applications. These applications can function as endpoints for various data and business services. These services can be plugged and played without deep integration into the device software.

Recommendation: Device platform services reduce development and support costs, allow developers to focus on applications, and do not require deep systems expertise or integration with business services.

IoT data and device middleware

Although IoT connectivity is standardized, IoT data is not. (Matter, a new standard from the Connectivity Standards Alliance, standardizes smart home data, but that’s an exception.) Every vertical industry, installation, and device has unique data characteristics and software requirements. Here are some examples of architectural diversity:

• Data formats — key-value pairs, arrays, time series, video and audio streams, blobs, trees, graphs
• Data size — volume, speed, variety, latency, scalability
• Data movement and processing — Push (MQTT), pull (HTTP), on-device, hub/access, edge server, cloud
• Data security and privacy — in motion, at rest, network access, physical access, privacy, regulatory restrictions
• Device management — Turn on, secure, control, monitor, update

The data path from devices to business applications runs through an intricate web of data and device management middleware. This is where most of the complexity of designing an IoT solution resides. The incredible diversity of device, data, and situational application architectures is why there are no universal, “one-size-fits-all” IoT middleware services. Comprehensive services have less flexibility to address specific solution requirements, so savvy developers are looking for simpler services that thoroughly address specific verticals or architectural configurations. Golioth is a good example of a company focused on a single architectural problem—moving and processing data. Golioth simplifies connecting devices to the cloud for more than 100 microcontroller-based hardware platforms without limiting the choice of cloud services.

An IoT middleware that provides a wide range of services can be too rigid and fragile to address the inherent complexity of IoT solution design. I think this is why Google shut down IoT Core last year. From Google’s post-retirement IoT Core page: “Google Cloud offers a variety of partner-driven solutions, built on Google Cloud, that meet the needs of IoT users.” Google could be ahead of the trend, making it easy for any IoT intermediary service to connect to Google Cloud instead of trying to offer end-to-end solutions. AWS and Azure continue to offer a full range of IoT services for data management, application enablement, device management and application enablement. Enterprises committed to one or both of these hyperscale platforms should take advantage of these services. But be careful – some services require deep system-level integration into IoT devices. In general, it is unwise to tie long-term investments in devices to a wide range of middleware.

Device management needs a little clarification. Enterprises want a single dashboard view to manage powering on, provisioning, monitoring, controlling and updating all IoT devices. Unified system management on all devices is a big advantage of using an IoT platform from one manufacturer, but it comes at a high price. Management services typically only work within the middleware vendor’s ecosystem. So, for example, your chosen DPaaS with its own update procedures is probably not compatible. We need a new generation of device management services with easy API-based platform integration. Stay with us.

Recommendation: Use data and device management services relevant to your vertical industry and architectural configurations. Ideally, these services do not require deep integration into IoT devices (i.e. run on off-the-shelf platforms) and connect to your business services.

IoT Enterprise Solution Services

Microsoft’s Azure IoT Central is an example of what they call an “out-of-the-box environment for developing IoT solutions.” It is a user experience layer and an API layer pre-integrated with IoT data sources and transformation tools to power business applications. If toolkits like this solve your IoT solution integration problems, don’t duplicate services already present in your business applications, and don’t require significant customization, then by all means use them. However, I often see these systems deliver fast, impressive initial results, but fall short of expectations as the requirements for the solution mature. Ultimately, enterprises need to combine all data sources, IoT and non-IoT, into a unified view, so direct access to all data is better than inserting an IoT-specific solution environment in front of the enterprise’s primary solution environment.

Recommendation: In a converged OT/IT world, IoT data should flow directly into existing business frameworks whenever possible.

Conclusion

A comprehensive, end-to-end IoT services framework is a simple and fast way to build an IoT solution, provided the framework’s capabilities match all of your requirements. However, most solutions require more flexibility, requiring the developer to divide the service offering into three categories. So which ones do we need?

Device Platform Services (DPaaS) and IoT middleware services simplify the most complex parts of IoT solution development. However, developers should avoid codependencies. Middleware services should not require invasive platform modifications, and platform software should be open to multiple middleware providers. IoT-specific enterprise solution services are most useful in small deployments where capabilities do not overlap with existing enterprise services. As OT and IT converge, the best environment for developing IoT solutions is the one you already use to develop enterprise solutions. IoT implementations should plug directly into existing business frameworks, not create new ones.