Some innovations are so good they make it too easy. Parabolic skis and AutoTune, to name just two. For the Internet of Things, it’s the cloud that is making things way too easy.
For IoT developers, the cloud is like beer in a college dorm: a cold one is around every corner you turn and … beer just becomes a constant of academic life. At least this is the way it works in America. So when an IoT developer is offered free cloud-based frameworks, databases, analytics, etc., reactions like “Hey look at all this cool cloud stuff! I think I’ll use it to build an IoT product!” is more norm than exception.
But like that one guy in your dorm who had a hard time saying no and then quietly dropped out before the end of his freshman year, IoT developers risk a similar fate if they become too dependent upon the cloud.
Admit It: The IoT Has A Problem
In case you weren’t paying attention, the IoT and the cloud have advanced to what can only be described as a very intimate relationship. Consider:
A Nest thermostat has a WiFi radio and is accessed via your smartphone, which also has WiFi. Yet for your smartphone to access your Nest thermostat, it does so via a long-distance internet session with a Nest cloud server, even though it would be faster and more reliable to connect your thermostat and smartphone on a peer-to-peer basis.
Cloud-based IoT “developer platforms” pop up weekly, no doubt due to low entry barriers provided by the cloud, the extreme example being the shark-jumping salesforce-for-iot platform. According to one survey of 651 developers and IT professionals by IBM (not an unbiased source, but directionally consistent with my own experience), 75% were using some form of cloud-based development platform for an IoT project.
Microsoft, GE, and others each sell “industrial cloud” platforms with the aim of enabling legions of manufacturing companies to bring the IoT to their factories and products via the cloud. Features run the full gamut from controlling and configuring endpoints to analytics.
A FitBit wristband connects via Bluetooth with your smartphone but sends your activity data to a FitBit cloud app. Does your personal health data really need to sit in the cloud or can you extract sufficient value from it by simply keeping the data stored locally on your smartphone?
Next-gen IoT computing platforms that include augmented reality already use a round trip to the cloud in order to resolve some objects discovered in an AR headset. For mobile devices engaged in real-time cognitive assistance that rely on IoT devices to help do their jobs, the cloud doesn’t exactly speed things up. You can learn more here.
“I really worry about everything going to the cloud. I think it’s going to be horrendous. I think there are going to be a lot of horrible problems in the next five years.”— Steve Wozniak, 2012
For most of the IT industry — let’s just get this on the table — the cloud today is the hammer and there’s almost nothing that isn’t a nail. And the cloud is an easy place to build an IoT application and operates without the messy hassles of embedded software, endpoint security, FCC regulations, or fertility risks, to name a few. And more and more, the cloud is a norm that pervades the IoT with increasing risk.
How The Cloud Is Infecting the IoT
The popularity of the cloud in the IoT is the result of several colliding realities:
It’s cheap and everywhere. Like beer in your dorm, the cloud today is so popular and so well-capitalized that infecting the IoT was only a matter of when, not if. Spin-offs like cloud analytics or cloud perimeter security (no laughing!) are simply too affordable and too visible to pass up. Traditional enterprise IoT pilots that used to cost $250,000 in enterprise software and systems integration services can be executed at a fraction of this price now due to the cloud.
Tools. Compared to older desktop-based tools, cloud-based environments and API’s are vastly simpler to use and integrate while offering robust functionality. Heroku, to cite just one example, is a complete but inexpensive cloud-based environment used by a number of IoT companies for deploying Ruby- or Python-based applications in the cloud and it is popular with novice and elite users alike.
Weak endpoints and edges. Endpoints that don’t do analytics, support real-time queries, or even support full two-way messaging tend to spew data remorselessly to an edge router and/or the cloud. Bluetooth, ZigBee, 6lowPAN, and others are all guilty as charged and as a result, they end up driving their users to the cloud.
Cupertino. It is hard to recall another company’s passivity stunting an industry’s growth the way Apple has for the IoT. First, Apple takes pride in a “slow follower” wireless strategy, unwittingly resulting in an IoT industry where 90% of new hardware devices rely on 1990’s-era Bluetooth or WiFi just to ensure iPhone connectivity. Second, When it embraces a new wireless technology, the pace is plodding: the API for NFC remains closed, for example, preventing non-payment IoT use cases for NFC from seeing the light of day with the iPhone. Third, Apple just redefines what it means to be a great hardware company by layering cloud-based services on top of its dominant hardware platforms, a lesson that is lost on few IoT hardware entrepreneurs.
Mountain View. This may come as a shock, but there are those who would drive your data to the cloud for purposes of finding new ways to sell you stuff. Yes, I know I am sticking my neck out here, but some companies are pushing your data to the cloud not because they have to, but because it’s profitable to do so or represents future revenue streams. It probably has the ancillary result of making some IoT products less expensive today, though, so we’ve got that going for us.
Why Your IoT-Cloud Relationship (Probably) Isn’t Healthy
A few years ago, a rock-climbing buddy of mine who was in what some might call a tragically unhealthy relationship ignored warnings from me and others and got married on a whim. Well, the wedding reception was epic, and two months later (that’s 2 months) the whole thing came crashing down and he was back on the street — single again. With the IoT and the cloud, it is IT departments, not fellow rock climbers, waving red flags:
It’s not secure. This one is hard to overstate as crummy IoT security is the sordid “yeah, but” in so many discussions about the IoT. IDC predictsthat nearly every IT network will have an IoT security breach by the end of 2016 and IT departments are in full freakout mode now. Endpoint security is comically bad and compounded with a hacker-friendly cloud, what could go wrong? Maybe your company can get some free PR on 60 Minutes.
It may not be reliable. If your IoT system relies on a cloud that you don’t own or control and the cloud fails, then what? Tracking a sales pipeline via the cloud is one thing, managing a fleet of vehicles, a mission-critical city power grid, or perishable flu vaccines in the cloud, that’s different.
It’s not real-time. IoT apps that require real-time responses can’t tolerate the extra seconds or minutes required for a cloud lookup. Ditto real-time analytics. The cloud = increased latency.
It may not be faithful. The integrity of your data in the cloud is only as good as the people and systems hosting it. Sensors in your manufacturing facility in Taipei showing you running at 50% below your normal run rate or showing a supply chain hiccup? Hedge funds and competitors enjoy learning about this kind thing! The cloud is the jackpot of data repositories and it’s where hackers focus.
Getting out may be easier than getting in. Once you’ve married a cloud service, how easy will it be to disengage/migrate to another solution at some future date? Is standardization and interoperability in a state that will increase the risk of vendor lock-in? What if the cloud vendor is bought by your competitor and changes policies?
“Vendor lock-in is a concern, it always is. Today’s leading-edge cloud companies are tomorrow’s dinosaurs.” — AstraZenica CIO David Smoley
How To Unbundle The Cloud and the IoT
De-clouding your IoT roadmap means substituting some or all of the cloud with … something else. So let’s start with:
A new golden rule of IoT network design is to store sensor data as close as possible to its point of origin and limit its sharing across the network unless absolutely necessary. This was previously not really practical with 1990’s-era endpoint technologies, but today if an endpoint can run its own analytics and other applications autonomously, what is the point of sending the data upstream at all, much less all the way to the cloud? If for no other reason, the IoT golden rule should be applied for the sake of IoT security and privacy.
The endpoint is key to the golden rule. Better processors, cheaper memory, and better networking stacks from companies like Haystack are evolving endpoints from dumb terminals to independent, distributed computing devices with real-time query (think Google for the IoT) and NoSQL-like filesystem support. Endpoint-centric designs also have the bonus of being more stealthy and secure, faster, cheaper, and better stewards of battery life and wireless bandwidth. In short, good IoT network design should begin with the endpoint in mind and “dumb” endpoint technologies that beacon or create unnecessary security risks should be phased out.
Endpoint-centric design brings us closer to a P2P IoT. If you envision a future with IoT devices that can operate more or less autonomously using artificial intelligence, intelligent agents, or blockchain-based contracts, it means reducing (or eliminating) our dependence on clouds and edge gateways and allowing devices to communicate on a peer-to-peer basis to do their jobs. This could be a separate post unto itself, but here are just a few examples of P2P IoT application opportunities:
Driverless cars and drones communicating with smart city infrastructure. You need immediate, low latency info about the icy bridge or railroad track you are about to cross. Waiting 2–3minutes for a cloud app to make time for you is a non-starter. Actually, any moving thing that communicates with a fixed thing using low power wireless needs P2P.
Moisture sensors coordinating in a cornfield to better manage irrigation. Where water is scarce, programs residing on endpoints bid and arbitrate in order to optimize for food production.
Access control. Second-factor authentication. The P2P IoT as an additional security layer for data centers and other computing devices.
Supply chain networks. Chain-of-custody tracking. A nurse querying the temperature history of a carton of flu vaccine can do so without the cloud.
Bitcoin. P2P payments. Autonomous, battery-powered, wireless things will bid, negotiate, and execute financial transactions based on the condition of what or who they are sensing.
Augmented reality wearables.
Most of today’s wireless IoT technologies were not designed for P2P:
Bluetooth low energy is basically a one-way beaconing technology so is not P2P. It’s sister standard, Bluetooth 4.0, can “pair” with another Bluetooth 4.0 device but it’s a long, laborious process that is neither real-time nor low power and is full of security vulnerabilities. Bluetooth’s short range and poor signal propagation make it a poor choice for anything but the shortest range IoT projects.
ZigBee and 6lowPAN tout “meshing” as a way for their short range technologies to daisy-chain messages to an edge gateway. This might qualify as “P2P-lite” but for private networks only since the feature is useless in public network scenarios like driverless cars or AR wearables where true P2P discovery and authentication must occur almost instantly. These technologies are also good if you are OK with hackers being able to easily find and exploit their endpoints.
WiFi supports mesh networking as well and recently announced plans for better P2P support, though its woeful security and high power consumption make it rarer and rarer in IoT deployments. WiFi, too, suffers from molasses-like discovery and authentication which is a non-starter for most IoT networks, especially public ones. I do not expect WiFi to find its way into serious P2P IoT discussions despite its ubiquity on smartphones.
Newer wireless IoT technologies like DASH7 were built directly for P2P and provide “instant-on” connections in public and private IoT networks. The technology is still young, but it gets P2P more right than any other low power wireless IoT technology. DASH7 does not currently support meshing (it supports 2-hop, which is typically more than sufficient) but since it uses longer range physical layer technologies, meshing is almost always unnecessary.
“Quite a lot of this content won’t be sent over the network to be processed by the ‘enterprise-based’ cloud infrastructure. Rather, you will need cloud computing-like processing at the edge … Quite simply, this is a big deal.” — Vernon Turner, SVP @ IDC.
When endpoints are not enough, then add the edge. For processes that can’t logically reside entirely at the endpoint, the edge gateway (or edge router or server) is their next logical home in the network. An edge gateway can interact with endpoints, host applications like analytics, store data, manage security, and more. There are no rules about the size or capabilities of edge gateways — they can be very simple or very large computing devices or may be a component of a much larger computing device. But the essential point in all of this is that the edge gateway is controlled and maintained locally and not in the cloud and not by a third party.
Think of the edge as a “cloudlet”. Smart cloud vendors will help customers bring cloud functionality to their edge devices as functionality that is usually delegated to the cloud can often be executed at the edge gateway. Gateway hardware is cheap and powerful, and much of what resides in the cloud can be placed at the edge for an increasingly ridiculous low price. Cisco, IBM, and a few others are trying to make “fog computing” a trendy term and … this is all for the better. And for those legacy firms doing yoga moves to transition into this cloud thing, it’s possible that your product lines can more easily make a more successful and shorter leap to the edge/fog.
The “Intranet of Things” is already here. Remember that the IoT is not new. Barcode and RFID networks have used fog computing for decades and hundreds of building automation, defense, manufacturing, and other types of local IoT networks existed before the cloud became a trend.
Special reminder to cloud people reading this with clenched teeth: helping your customers to keep more of their data at the edge of their network is a good thing for you. If you keep what belongs in the cloud in the cloud (e.g. global network analytics) and what belongs at the edge at the edge, your customers (and their CSO’s and PR people) will thank you for it. Some of you already market “private clouds” or “hybrid clouds”, so marketing “local clouds” may be easier than you think. And keep in mind that 40% of all IoT data is predicted to be “stored, processed, analyzed, and acted upon close to, or at the edge, of the network,” by 2018 according to IDC.
When the edge is still not enough, it’s OK to look to the cloud. The cloud has a role to play in the IoT, and where processes cannot be practically executed at the endpoint or the edge, the cloud may be the only reasonable choice. Batching data from gateways around the world for non-real time, non-mission critical analysis is one example of a “smart” cloud+IoT process. Controlling, configuring, and querying endpoints via a cloud-based application is not, however.
Pilot in the cloud, deploy in the fog. The cloud is a fast and affordable way to prototype, demonstrate, and pilot, but it is the IoT’s Faustian bargain. For projects requiring scale, it’s a good idea, again, to default to the endpoint and/or the edge gateway and then ask how the cloud can complement them, not vice-versa.
If you deploy in the cloud, have a Plan B. If the temptation to deploy in the cloud is too great, at least be able to articulate how the system will function in the case of a cloud outage, hack, or other “unforeseen” event. At a minimum, a Plan B lays the groundwork for a future phase you may need in order to reduce your IoT system’s exposure to the cloud. You know, the phase that happens after your cloud IoT system is hacked and your board of directors asks “so now what?”.
So Now What?
The cloud is a useful tool for jump-starting IoT initiatives and has an important role to play in non-real time analytics. But it is inevitable — if only for the sake of security — that the IoT as an industry will go through a kind of cloud “detox” that results in a healthier and more resilient IoT where the cloud is deployed with eyes wide open to the accompanying risks. If your organization is talking about designing an IoT network and you are hearing or seeing the word “cloud”, it’s worth raising your hand and asking questions like “Is there a good reason not to execute this (insert process/feature) at the edge, rather that in the cloud?” or “Are we able to deploy stealthy endpoints that don’t over-share data?”
The momentum behind the cloud is strong and some of you may encounter resistance to arguments for pushing IoT functionality to the edge. If so, you can always take comfort in the fact that endpoints are only increasing in functionality, security “accidents” in the cloud will only become more numerous and more lethal, and that in the history of computing, the arc of history clearly supports the inevitability of more autonomous IoT endpoints.