The Future Of IoT Cloud Services

By Bill Curtis, Patrick Moorhead - March 22, 2024

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

Regardless of the future of Azure IoT Central, Microsoft’s customers have three years to react, so there’s no immediate business impact. However, sudden end-of-life events and deprecation rumors remind us that IoT services are in flux as enterprise operational technology environments converge with mainstream information technology systems. In this new OT/IT converged world, data analytics, including AI training and inference applications, utilize data from all sources—IoT and non-IoT. So, 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 for developing, deploying and operating fleets of connected devices at industrial scale. The choice of these services is a critical architectural decision in any IoT implementation, so let’s ask the obvious question: As IT and OT computing environments converge, what specific IoT services do enterprises actually need?

Bringing Order To The IoT Wild West

Until recently, the Internet of Things was like the Wild West. Gunslinger engineers (including myself) hacked together end-to-end solutions using customized, stripped-down device hardware, one-off device OS configurations, firmware written in C, ad-hoc security architecture, cloud services with low-level APIs and convoluted integration with enterprise data and applications. It’s no wonder that the success rate for enterprise IoT projects has remained disappointingly low for 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 endeavored to bring law and order to the Wild West of IoT solutions by offering fully integrated, secure, end-to-end computing environments spanning three principal areas of IoT software solution development:

  1. IoT device software — OS, networking, security and application development
  2. IoT data and device middleware — Device management, data ingestion, aggregation, filtering and analysis
  3. IoT enterprise solution services — IoT-oriented solution development, analytics and export to enterprise systems

An integrated set of services simplifying IoT from end to end is a compelling proposition. “Put all your IoT problems in 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. Hence, the services listed above 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 ones add long-term value—and which don’t.

Forbes Daily: Join over 1 million Forbes Daily subscribers and get our best stories, exclusive reporting and essential analysis of the day’s news in your inbox every weekday.

IoT Device Software

IoT platforms have limited memory, storage and computation power. These constraints force most OEMs to construct the whole device software stack in-house, customizing each product’s OS, drivers, network stack and security functions. System development is expensive, developers with the required embedded engineering skills are scarce and supporting unique configurations for each product throughout its lifetime creates considerable technical debt. The solution to this problem is to make the IoT software development process more like developing for mainstream PC and smartphone platforms. Using IoT platforms as-is rather than 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. Development and support cost savings exceed increased silicon cost, particularly for low-volume industrial products, so we’re on the verge of a sea change in embedded development.

For microprocessor-based platforms, IoT DPaaS offerings simplify customization and create tailored, continuously updateable Linux microPlatform distributions. For many types of devices, developers can compose plug-and-play application components using Docker or other container technologies, enabling OEMs to focus on value-added software without worrying about the underlying compute platform. Foundries.io’s FoundriesFactory is an excellent example of a DPaaS that automates system development, delivering a customized, maintainable OS with minimal cost and effort.

For microcontroller-based platforms, extreme constraints on memory, storage, physical size, power consumption and real-time performance require a more diverse set of specialized OSes. There’s 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. Although the MCU OS space is unlikely to unify any time soon, companies like MicroEJ offer application virtualization environments that enable developers to write platform-independent code that runs on devices preconfigured with an OS and silicon-specific firmware and drivers. For instance, NXP and MicroEJ teamed up to provide container-ready platforms based on NXP’s MCU portfolio.

Regarding our question about which IoT services we need, DPaaS services turn embedded MPU and MCU devices into platforms with standard networks, protocols and OSes capable of running containerized applications. Those applications can function as endpoints for various data and enterprise services. Those services can plug and play without deep integration into device software.

Recommendation: Device platform services reduce development and support costs, enable developers to focus on applications and don’t require deep systems expertise or integration with enterprise services.

IoT Data And Device Middleware

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

  • Data formats — Key-value pairs, arrays, time series, video and audio streams, blobs, trees, graphs
  • Data size — Volume, velocity, variety, latency, scalability
  • Data movement and processing — Push (MQTT), pull (HTTP), on-device, hub/gateway, edge server, cloud
  • Data security and privacy — In motion, at rest, network access, physical access, privacy, regulatory constraints
  • Device management — Onboarding, securing, controlling, monitoring, updating

The data path from devices to enterprise applications leads through the tangled web of data and device management middleware. This is where you find most of the complexity of IoT solution design. The incredible variety of situation-dependent device, data and application architectures is why there are no universal, “one size fits all” middleware services for IoT. Comprehensive services have less flexibility to address specific solution requirements, so savvy developers look for simpler services that thoroughly address specific verticals or architectural configurations. Golioth is a good example of a company focused on one architectural problem—data movement and processing. Golioth simplifies device-to-cloud connectivity for more than 100 microcontroller-based hardware platforms without restricting cloud service choice.

IoT middleware that provides a broad spectrum of services can be too rigid and brittle to address the inherent complexities 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 host of partner-led solutions, built on Google Cloud, that meet the needs of IoT customers.” Google might be ahead of the trend, making it easy for any IoT middleware service to hook into Google Cloud rather than trying to provide end-to-end solutions. AWS and Azure continue offering a full range of IoT services for data management, application enablement, device management and application enablement. Enterprises with commitments 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’s unwise to tie long-term device investments to broad-spectrum middleware.

Device management needs a bit of clarification. Enterprises want a single dashboard view to manage onboarding, securing, monitoring, controlling and updating all IoT devices. Unified system management across all devices is a big advantage of using a single-vendor IoT platform, but it comes at a high cost. Management services typically work only within the middleware vendor’s ecosystem. So, for example, your chosen DPaaS with its own update procedures probably isn’t compatible. We need a new generation of device management services with lightweight, API-based platform integration. Stay tuned.

Recommendation: Use data and device management services that address your vertical industry and architectural configurations. Ideally, these services do not require deep integration into IoT devices (i.e., they run on standard platforms) and connect with your enterprise services.

IoT Enterprise Solution Services

Microsoft’s Azure IoT Central is an example of what it calls “a ready-made environment for IoT solution development.” It’s a user experience layer and an API layer pre-integrated with IoT data sources and transformation tools to drive enterprise applications. If toolsets like this solve your IoT solution integration problems, don’t duplicate services already present in your enterprise applications and don’t require significant customization, then by all means, use them. However, I often see these systems deliver quick, impressive initial results but fall short of expectations as solution requirements mature. Ultimately, enterprises must combine all data sources, IoT and non-IoT, into a unified view, so direct access to all data is better than interposing an IoT-specific solution environment ahead of the primary enterprise 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 framework of IoT services is an easy and fast way to build an IoT solution, provided the framework’s capabilities fit all your requirements. However, most solutions need more flexibility, requiring developers to break service offerings into three categories. So, which ones do we need?

Device platform (DPaaS) services and IoT middleware services simplify the most complicated 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 don’t overlap existing enterprise services. As OT and IT converge, the best environment for IoT solution development is the one you already use for enterprise solution development. IoT deployments should plug directly into existing business frameworks, not create new ones.

+ posts
Bill Curtis is the Moor Insights & Strategy Analyst in Residence for large-scale Internet of Things systems. Bill helps enterprises design distributed solutions that integrate the full end-to-end IoT stack from real-world devices to analytics.
+ posts
Patrick founded the firm based on his real-world world technology experiences with the understanding of what he wasn’t getting from analysts and consultants. Ten years later, Patrick is ranked #1 among technology industry analysts in terms of “power” (ARInsights)  in “press citations” (Apollo Research). Moorhead is a contributor at Forbes and frequently appears on CNBC. He is a broad-based analyst covering a wide variety of topics including the cloud, enterprise SaaS, collaboration, client computing, and semiconductors. He has 30 years of experience including 15 years of executive experience at high tech companies (NCR, AT&T, Compaq, now HP, and AMD) leading strategy, product management, product marketing, and corporate marketing, including three industry board appointments.