Credit: Dreamstime
IoT, the Internet of Things, is currently one of the most hyped concepts in the computing world. Cloud IoT platforms may even exceed IoT on the hype scale.
Nevertheless, both have real applications and could become important to a business. In this article we’ll define IoT and cloud IoT platforms without too much technical detail, then discuss what IT leaders need from a cloud IoT platform and how to choose one.
The simple explanation of IoT is that it is physical things connected to the internet. These things can have sensors that measure various parameters and send their data over the internet, typically back to a remote or 'edge' server located in the same geography.
Internet things can also take directions via the internet and act on them. Most usefully, the physical things that make up IoT might both send measurements and receive instructions.
For example, a 'smart' internet-connected soil moisture sensor could report its readings periodically, and whenever the soil in a field was too dry an internet-connected water valve could open. When the soil moisture was adequate, the valve would close.
The moisture sensor and the water valve might be connected to the same 'edge computing' device or node that talks to the internet, or they might be connected to different nodes, since many soil moisture sensors are likely to be used for a large field, while only one centralised irrigation system would be needed for each field.
How does IoT relate to the cloud?
'The internet' is not an endpoint, of course, but an interconnected collection of networks that transmit data. For IoT, the remote endpoints are often located in a cloud server rather than in a single server inside a private data center.
Deploying in a cloud isn’t absolutely necessary if all an IT leader is doing is measuring soil moisture at a bunch of locations, but it can be very useful.
Suppose that the sensors measure not only soil moisture, but also soil temperature, air temperature, and air humidity. Suppose that the server takes data from thousands of sensors and also reads a forecast feed from the weather service.
Running the server in a cloud allows businesses to pipe all that data into cloud storage and use it to drive a machine learning prediction for the optimum water flow to use. That model could be as sophisticated and scalable as required.
In addition, running in the cloud offers economies. If the sensor reports come in once every hour, the server doesn’t need to be active for the rest of the hour. In a 'serverless' cloud configuration, the incoming data will cause a function to spin up to store the data, and then release its resources.
Another function will activate after a delay to aggregate and process the new data, and change the irrigation water flow set point as needed. Then it, too, will release its resources.
Local vs. remote IoT feedback loops
In our irrigation example, the system will still work if the response time from the cloud server is an hour. Other systems are much less tolerant of lag.
For example, consider a self-driving car: It is constantly viewing the road, identifying obstacles, and measuring its location. It may also constantly send its data to the cloud, but it can’t depend on a remote server to adjust its throttle, brakes, or steering. That must all be done locally.
This is one of the essential lessons of an introduction to control systems engineering course: Push the control feedback loops down to the lowest possible level. Yes, a remote supervisor can change the destination set point or the route plan, but the car itself must take care of all the time-sensitive actions.
Essential cloud IoT functions
A cloud IoT platform must monitor IoT endpoints and event streams, analyse data at the edge and in the cloud, and enable application development and deployment. These are the essential functions required for virtually any IoT implementation.
In order to enable cloud data analysis and application development, the IoT platform needs access to cloud storage. For industrial IoT devices and vehicles, there can be a lot of data to store, although it can be filtered or aggregated for long-term analysis purposes.
Industrial IoT can also present a challenge in terms of network and protocol conversions. Old-fashioned industrial programmable controllers weren’t made for Ethernet and TCP/IP.
Another piece of the puzzle is transporting the data from the edge devices to the cloud platform. For indoor applications users can often use wired Ethernet or Wi-Fi. For outdoor applications, such as the agricultural scenario, using cellular data is common, with cellular M2M (machine-to-machine) plans rather than much more expensive cell phone plans.
Managed IoT connectivity services can help with this piece. Some of these services are mostly about managing SIM cards and related data; broader IoT connectivity platforms also deal with edge device operating systems and agents. Beware: Some mature M2M services have added “IoT” to their branding without adding any real IoT capabilities.
IoT platform considerations
Rather than simply jump onto an attractive-sounding cloud IoT platform, CIOs should first identify their own requirements and sketch out a few monitoring, analysis, control, and application architectures that might fulfil them. Figure out the user experience, data, and business decision pieces of the design before jumping into the technology.
Try to avoid designing to a specific device, device OS, gateway, edge platform, network, communications protocol, cloud platform, or cloud brand. Instead, design in generic terms first. Figure out which features are most important to an application, and use that list to inform platform selection. In other words, it’s a process.
Cloud IoT costs can be hard to predict, and easy to underestimate. Part of the problem is that cloud pricing is inherently complicated. Often the only way to really know what a cloud application costs is to run it for a month and look at the bill.
Another part of the problem is that cloud IoT platforms generally offer an introductory discount. If users rely on the introductory pricing, they can be in for a rude surprise when the prices go up. Finally, it’s easy to neglect the cost of data storage, and hard to implement a long-term strategy for discarding older inessential data.
Another difficult part of the process is to evaluate internal capabilities. Does the business have expertise in managing devices and sensors? In communications protocols and networks? In cloud application architecture, operations, and management?
Will the people be able to dedicate themselves to building an IoT application, or do they have important ongoing responsibilities? Will new hires be required? Are new hires with the right skills available?
Those evaluations will inform a choice of full-featured or bare-bones cloud IoT platforms. Some vendors offer robust, nearly complete platforms that are easily customisable to application needs. Other vendors supply some of the pieces needed, but require IT leaders to do much more integration and customisation, either internally or using consultants.
I can’t overemphasise the value of performing a proof of concept for a first cloud IoT deployment. Like any other project involving software development, users need to plan for the first effort to fail so that they can learn from their mistakes and build it right the next time. Only after a proof of concept succeeds can they start scaling it up and out.
