6 enterprise-scale IoT platforms compared

There’s little need to tell anyone in IT that the Internet of Things (IoT) is a big deal and that it’s growing insanely fast; BI Intelligence estimates that there will be some 23.3 billion IoT devices by 2019. As IoT support becomes more of an enterprise concern, there are four key issues about enterprise IoT (EIoT) deployments to consider:

1. The sheer number of enterprise IoT endpoint devices – There will be 1 billion by 2019.
2. The frequency of data generated IoT devices – IDC estimates that by 2025, an average connected person anywhere in the world will interact with connected devices nearly 4,800 times per day or one interaction every 18 seconds.
3. The incredible volume of IoT data – Of the 163 zettabytes (that’s 1021bytes) of data that will be created in 2025, IDC estimates that 60% will be from IoT endpoints and half of that (roughly 49 zettabytes) will be stored in enterprise data centers.
4. The challenges of maintaining security for your device constellation – IDC estimates that by 2025, 45% of the stored enterprise data will be sensitive enough to require being secured but will not be.

Now, if you’re an early adopter, you may have already built your own IoT infrastructure and your endpoint-device deployment may well be underway. You’ll have discovered that the do-it-yourself approach is non-trivial in the enterprise IoT world. On the other hand, if you’re about to enter the IoT world and you’d rather not build a homegrown solution, then what are your platform choices? To make your research easier, we have complied a collection of six of the leading enterprise IoT platforms that can not only do the job but do so at enterprise scale.

Building blocks of enterprise IoT

But before we get to the offerings, let’s look at the building blocks of enterprise IoT. First, consider the type or types of endpoint devices you’ll be using. There are now literally thousands of off-the-shelf products that can be used for prototyping, tracking vehicles and products, monitoring environmental conditions, controlling equipment, or reporting on the status of all sorts of things. You name it, there’s probably a device waiting for you to use and, as the majority of platforms are device agnostic, there’s not much to constrain your choice of EIoT platform. That said, a few platforms were designed to only support specific devices and in some cases that support is only for a single type of device (for example, see the Amazon AWS IoT Button).

Alternatively, you might have to “roll your own” and build IoT functionality into your existing processes and products. When it comes to endpoint hardware there are literally hundreds of single-board computers now available (such as Arduino, Raspberry Pi and SolidRun’s HummingBoard-Gate) or you could choose any other device with more smarts than an electric toothbrush. For communications, you can use an industry standard protocol such as MQTT, HTTP/HTTPS, AMQP, XMPP, DDS, and CoAP (see the sidebar “Communications Protocols and Technologies”), and you’ll have no trouble finding a compatible EIoT platform. Alternatively, if your endpoint devices use protocols or media that aren’t supported, you can use IoT gateways to convert from whatever protocol and media the devices use to enable communication with an EIoT platform.

Fog computing and IoT

Next comes an optional layer of intermediate services, often called fog computing, that sits between the endpoint devices and the cloud (this is a major marketing battle zone so you’ll find a lot of alternative names used for this layer). In the fog-computing layer, functions such as data aggregation, filtering and processing can be used to optimize communications bandwidth. For example, only sending critical data or summaries to improve communications performance to reduce data costs or reducing what would be a cloud-processing load such as machine learning or performing statistical analyses.

Examples of fog computing products include Cisco’s Fog Data Services and Microsoft’s Azure IoT Edge, although the latter focuses on moving the filtering and processing functions onto the device itself which really makes it an additional endpoint-device layer rather than what is generally considered to be fog computing. Whether you need fog computing will depend on the endpoint device choices you make and the communications limitations in the deployment environment.

It’s worth pointing out that in IoT situations that require real-time or near-real-time interactions – for example, closing a valve when a liquid level is reached – you either have to have devices smart enough to respond and control the event with little or no delay or rely on fog computing to handle the sensor data and issue a control signal to an actuator.

Typically, the latency from endpoint devices to fog-computing services will be in the range of milliseconds to seconds. Compare that delay to a latency in the range of seconds to minutes connecting devices or fog computing services to an EIoT platform and you can see that fog computing has an important role in real-world environments.

IoT gateways

Another service you’ll find in fog computing systems is IoT gateways. One of the most common uses of IoT gateways is to bridge from endpoint devices that, for example, connect over Wi-Fi to another medium such as an Ethernet network or cellular service. Gateways can also translate between protocols. For example, they might convert HTTP requests or a custom protocol from endpoint devices to MQTT messages.

Hosted IoT platforms

Finally, we reach the enterprise IoT platform core in the cloud. This will be a hosted Platform as a Service (PaaS) providing a publish-subscribe (pub-sub) or request-response (RR) message-brokering system. Which messaging pattern you’ll use will depend on the available protocols given your devices and their constraints and performance. (For a serious discussion on the two communication patterns, see the paper, A Communication Model to Integrate the Request-Response and the Publish-Subscribe Paradigms into Ubiquitous Systems.)

IoT digital twins

A feature many EIoT platforms offer is virtual endpoint devices. A variety of names are used for these virtual devices; for example, AWS IoT Core calls them “device shadows” while Microsoft calls them “twins.” Virtual endpoint devices are documents or database records that allow other devices to interact with the last known or predicted future state of the actual device even when it isn’t connected. So, for example, if an endpoint device is setting the temperature of a water bath to 200 degrees but the device has to disconnect for some reason and might not reconnect until after the water bath has reached the target temperature, the virtual version can be set to show the target temperature and target time that it will be reached. Other devices that have to interact with the water bath can now read the device future target state without the measuring device being online.

Enterprise IoT security

There’s one more critically important aspect of IoT architectures that applies to all layers: security. Given the problems and liability issues that unsecured IoT products have caused such as the massive 2016 Distributed Denial of Service (DDoS) attack on the DNS service management company, Dyn, Inc., robust security is absolutely required and all of the EIoT solutions we cover here have serious security baked in.

So, which enterprise IoT platform will meet your needs best? The bottom line is that successful enterprise IoT solutions require careful engineering starting with the endpoint devices, through the fog computing layer to the cloud and finally, to the EIoT platform. Then, when the data are captured by the EIoT platform, how they’re handled, processed, and stored once they get there will determine the data’s manageability and actionability and, therefore, the cost and value of your EIoT system.   

Amazon AWS IoT

At the heart of Amazon’s IoT offerings is the AWS IoT Core, built around a publish/subscribe message-broker service that supports HTTP 1.1, WebSockets and MQTT version 3.1.1 with X.509 mutual authentication, encryption and granular privileges. The broker is front-ended by the Device Gateway, which manages active device connections and handles protocol semantics. Amazon claims the gateway can scale automatically to support over one billion devices. Alongside these features is the Registry, which assigns a unique identity for each device and tracks device metadata such as attributes and qualities, and, optionally, virtual devices (device shadows).

AWS IoT is hardware agnostic so the AWS IoT SDKs provide tools to support pretty much any endpoint devices you might want to use. There are SDKs for Android, Arduino Yún, embedded C and C++, iOS, Java, JavaScript and Python, and they include open-source libraries, developer guides, sample code and porting guides.

The final feature that completes the AWS IoT Core is the Rules Engine that parses inbound messages, transforms them as required and, based on rules you define, routes them to a service or device. The services include all of the Amazon AWS service endpoints including AWS Lambda (cloud code hosting), Amazon Kinesis (real-time big-data handling and analysis), Amazon S3 (massive-scale object storage), Amazon Machine Learning, Amazon DynamoDB (a NoSQL database service), Amazon CloudWatch (AWS cloud monitoring), Amazon Elasticsearch Service with built-in Kibana visualization and Amazon Simple Notification Service. With this collection of tools and services you can build IoT systems at global scale.

AWS IoT 1-Click

Amazon Web Services also offers a unique IoT platform called AWS IoT 1-Click. This is built on top of Amazon’s general purpose IoT services but designed for handling simple event notifications generated by physical “buttons.” These button events trigger functions and services hosted in the Amazon Web Services cloud. For example, when single-clicked, an AWS 1-Click button in a conference room could signal that a meeting has begun and when double-clicked that the meeting has concluded, and the facility should be cleaned. Because buttons can be quickly and easily deployed anywhere, they can be used to increase customer engagement, expand and extend applications and signal any kind of user-driven event or need.

AWS IoT 1-Click currently supports only two types of devices: the Wi-Fi-enabled AWS Enterprise Button and the AT&T LTE-M Button that uses cellular communications.

The AWS IoT Enterprise Button is actually a redesigned Amazon Dash Button, a device that was created to make ordering consumer products from Amazon really easy (Need more laundry soap? Press the button with the laundry soap logo on it, and the soap will appear in a couple of days, and your credit card debited). The potential of using this simple device for purposes other than shopping were apparent from the beginning (I covered the mechanics of hacking the Dash Button back in 2015).

The AT&T LTE-M Button uses AT&T’s Long Term Evolution for Machines (LTE-M) network, designed for simple, low-power devices that need wide-area coverage and to have a long battery life.

When the button is pressed on either type of device (single-click, double-click and long-press are all recognized) a secure and encrypted message is sent to the AWS IoT Core. The AWS 1-Click service messaging is based on the MQTT protocol so the button is actually an MQTT subscriber and the AWS IoT core is acting as an MQTT message broker. A message sent by a button specifies the device ID, and the AWS IoT Core Rules Engine determines what should be done, which can be really pretty much any functionality you can think of. 

Provisioning, management and reporting can all be done through either the AWS IoT Console or the AWS IoT Button Dev app (available for iOS and Android).

Cisco Systems Jasper

“Cisco Systems’ Jasper is focused on mobile devices and distributed by more than 50 service providers currently servicing 85 million active IoT devices in over 120 countries and adding 2.5 million new devices per month.”

Devices that use cellular and LPWAN (that is, devices that connect frequently and have relatively high data usage) are managed with the Control Center for IoT, while devices running over NB-IoT wide area networking are managed via the Control Center for NB-IoT. In both cases, Control Center features include device monitoring, diagnostics, authentication, and fraud detection. Users can also add in additional Control Center services, which include an Automation Package, an Integration Package, an Analytics Package, Threat Protection and Smart Security for Purpose-Specific Tablets, and Traffic Segmentation.

For developing new cellular and LPWAN endpoint devices, Cisco offers the AT&T IoT Developer kits.

A particular strength of Cisco’s IoT offerings is their extensive IoT hardware product lines which include routers, IoT gateways, switches and wireless access points. Cisco also offers the IOx operating system, a Linux application environment for fog applications. Cisco explains:

Fog applications offer … the ability to transform IoT sensor data and perform control functions within the distributed network infrastructure. With the support of IOx included in routers, switches, and compute cards, the distributed IoT network can function as the compute environment for fog applications. Examples of deployed fog applications include site asset management, energy monitoring, and smart parking.

Cisco’s Fog Manager is designed to manage large-scale production deployments of IOx-enabled fog applications from initial roll out through change management to application retirement. Fog Manager is delivered via a web GUI or it can be integrated with network management systems through APIs. The Fog Portal, designed for developing fog applications “… provides all the developer resources for the developer to develop, test their application and make them available for deployment via Fog Director,” Cisco says.

Last year, Cisco launched its Cisco Kinetic IoT platform, which includes connection management, fog computing and data delivery for a wider range of connected endpoint devices. The system’s cellular and LPWAN functionality comes from the Jasper platform so it can handle both wired and wireless devices. It’s likely that eventually Kinetic will become the main platform in Cisco’s IoT solutions.

Microsoft Azure IoT

Microsoft describes Azure IoT as “a fully managed SaaS (software-as-a-service) solution that makes it easy to connect, monitor and manage your IoT assets at scale.” Azure IoT provides two types of software libraries (available in .NET, C, Java, Node.js, and Python versions): device libraries for building apps on endpoint devices and service libraries for managing an Azure IoT hub, sending messages, scheduling jobs and sending updates to your IoT devices.

Microsoft has open-sourced a lot of their IoT technology and their GitHub repo is an excellent way to get into the hows and whys of Azure IoT. From Choose the right IoT Hub tier for your solution:

…Azure IoT Hub offers two tiers, basic and standard, that differ in the number of features they support. If your IoT solution is based around collecting data from devices and analyzing it centrally then the basic tier is probably right for you. If you want to use more advanced configurations to control IoT devices remotely or distribute some of your workloads onto the devices themselves then you should consider the standard tier.

 …  Each IoT Hub tier is available in three sizes, based around how much data throughput they can handle in any given day. These sizes are numerically identified as 1, 2 and 3. For example, each unit of a level 1 IoT hub can handle 400 thousand messages a day, while a level 3 unit can handle 300 million.

Important concepts in the Azure IoT Hub are Device Twins and IoT Edge Module Twins, which are documents describing the actual endpoint devices and Edge modules. These twins live on the IoT Hub and report current state information such as available capabilities and conditions and synchronize the state of long-running workflows between device apps and back-end apps (see Microsoft’s Azure Docs articles on device and module twins).   

The IoT Protocol Gateway includes an identity registry that stores all the information about devices that are part of the IoT configuration. Customers monitor their asset status to see whether devices are connected or disconnected to the network along with the last known activity of devices. 

IBM Watson IoT

The IBM Watson IoT Platform for IBM Cloud includes directly connected applications, endpoint devices that support industry-standard protocols, gateways, device management and external service integrations giving you the ability to gather and store real-time IoT data and perform on-demand analytics.

Applications can connect directly to the Watson IoT Platform via the HTTP REST API using API keys and tokens or by binding the application directly. Alternatively, as with directly connected IoT endpoint devices, MQTT can be used as the connection method.

Watson IoT gateways connect to the Watson IoT Platform using MQTT or HTTP messaging protocols, and IBM provides supporting client libraries for C++, C#, Embedded C, Java, Mbed C++, Node.js, Node-RED and Python. Edge Analytics move the analytics rule-triggering process from the cloud to an edge-analytics-enabled gateway.

The Watson IoT platform handles data management that includes a device-twin feature and an asset-twin feature. The device-twin feature enables you to take advantage of the collection, transformation and normalization of different formats of device data into a single logical model. The asset-twin feature enables you to group different devices together to create a Thing, which is a higher value asset-based data structure. You can group Things together to create new Things. An application can interact with the logical model, regardless of the data format that is used by the individual devices or Things.

The Watson IoT Platform lets you add selected IoT data to a private, secure blockchain so you can share data with specific business partners involved with a transaction. The Watson IoT filters device events and sends only the required data to the blockchain contract and can translate existing device data from one or more device types into the format needed by the blockchain contract APIs.

Google Cloud IoT Core

Given Google’s global reach it’s not surprising that they offer an enterprise scale IoT solution. Moreover, given the company’s enormous range of cloud services, there’s pretty much everything you need for any IoT implementation including storage, big data, analytics and machine learning.

Central to Google’s Cloud IoT Core is the Cloud Pub/Sub message broker that supports MQTT and HTTP connections. The data gathered via the broker is aggregated and forwarded to Google Cloud data-analytics services. Supported endpoint devices can be pretty much anything you can think of, and Google has partnered with a who’s who of device manufacturers, including Intel, Arm, Marvell and Allwinner, and application developers such as Bright Wolf, Losant, and Afero.

Cloud IoT Core includes the Device Manager that handles endpoint device configuration and device authentication. You can access the Device Manger via its Web-based console or programmatically through an API. The Protocol Bridge provides the device communications interface as well as handling load balancing. Client libraries are available for Go, Java (Android), .NET, JavaScript, Objective-C (iOS), PHP, Python and Ruby.

Downstream services include analytics, Google Cloud Pub/Sub, Dataflow, Bigtable, BigQuery and machine learning. Google is wor