I blogged yesterday about the OPNFV project for Event Streams and the need to take a broad view of event-driven software as a precursor to exploring the best way to standardize event coding and exchange. It occurred to me that we’re facing the same sort of problem with IoT, focusing on things that would matter more if we had a broader conception of the top-down requirements of the space. Let me use the same method to examine IoT as I used for the Event Streams announcement—examples.
Let’s suppose that I have a city that’s been equipped with those nice new IoT sensors, directly on the Internet using some sort of cellular or microcellular technology. It’s 4:40 PM and I left work early to get a jump on traffic. So did a half-million others. I decide that I’m going to use my nice IoT app to find me a path to home that’s off the beaten path, so to speak. I activate my app, and what happens?
What I’m hoping for, remember, is a route to my destination that’s not already crowded with others, or will shortly become crowded. That information, the IoT advocates would say, is exactly what IoT can provide me. But how, exactly? If the sensors count cars, I could assume that car counts would be a measure of traffic, but a car counter would count not cars but cars passing it. If the traffic is at a standstill, how many cars are passing? Zero, so I have a bad route choice.
However, it may not be that bad because I may never see the data in the first place. Remember, I have a half-million sharing the road with me, and most of them probably want to get home early too. So what are they doing? Answer; hitting their IoT app to find a route. If that app is querying those sensors, then I’ve got a half-million apps vying for access to a device that might be the size of a paperback book. We have websites taken down by DDoS attacks of that size or smaller, and those sites are supported by big pipes and powerful servers. My little sensor is going to weather the storm? Not likely.
But even if I got through, would I understand the data? I could presume that the sensors would be based on a basic HTTP exchange like the one that would fetch a web page. Certainly I could get something like an XML or JSON payload delivered that way, but what’s the format? Does the car sensor give me the number of cars in the last second, or minute, or hour, or what? Interpreting the data starts with understanding what data is actually being presented after all.
But suppose somehow all this worked out. I’ve made the first turn on my route, and so have my half-million road-sharing companions. Every second, conditions change. How do I know about the changes? Does my app have to keep running the same decision process over and over, or does the sensor somehow signal me? If the latter is the case, how would a specific sensor know 1) who I was, 2) what I wanted and 3) what I had to know about to get what I wanted?
OK, you say, this is stupid. What I’d really do is go to my “iIoT service” on my iPhone, where Apple would cheerfully absorb all this sensor data and give me answers without all these risks. Well, OK, but that raises the question of why a city-full of those IoT sensors got deployed when they’re nothing but a resource for Apple to exploit. Did Apple pay for them? Ask that to Tim Cook next shareholder call. If Apple is just accessing them on “the Internet” because after all this is IoT, then is Apple and others expecting to pay for the access? If not, why did they ever get deployed. If so, how does that cheap little sensor know who Apple is versus some shameless exploiter of their data?
Maybe, you speculate, we solve some of our problems with the device that started them, our phone. Instead of counting cars, we sense the phones that are nearby. Now we know the difference between an empty street and gridlock. Great. But now we have thousands of low-lifes tracking women and children. Prevent that with access controls and policies, you say? OK, but remember this is a cheap little sensor that you’ve already had to give the horsepower of a superserver to. Now we have to analyze policies and detect bad intent?
Or how about this. A bunch of Black Hats says, gee we could have fun by deploying a couple hundred “sensors” of our own, giving false data, and getting a bad traffic situation to become gridlocked enough that even emergency fire and rescue can’t get through. Or we’re a gang of jewel thieves with an IoT getaway strategy. How do these false-flag sensors get detected?
Sometimes insight comes in small steps. For example, the Event Stream project talks about Agents that get events, Collectors that store them in a database. This kind of structure is logical to keep primary event generators from being swamped by all the processes that need to know the state of resources. Isn’t it logical to assume that this same sort of decoupling would be done in IoT? The project seeks to harmonize the structure of event records; isn’t it logical to assume that sensor outputs would similarly have to be harmonized? Resource information in NFV and sensor data in IoT both require what are essentially highly variable and disorderly sources to be loosely coupled with highly variable and disorderly process sets that interpret the stuff. The issues raised by each would then be comparable.
Once we presume that we need to have common coding for event analysis and some sort of database buffering to decouple the sensors in IoT from the processes, we can resolve most of these other questions because we don’t have a sensor network problem anymore, we have a database problem, and we know how to address all the concerns raised above if we presume that context. But just as Event Streams have to trigger an awareness of the need for contextual event processing, so the existence of a database where sensor data is collected and from which it’s distributed begs the question of what apps do and how public policy goals are maintained.
We’re not there yet with IoT. Even IT vendors who make IoT announcements are still kissing low-power protocols and transmitters and not worrying about any of the real issues. And these are the vendors who already sell the databases and analytics products and clouds of servers, who have the technology to present a realistic model.
Way back in 2013, in CloudNFV, I outlined the set of issues that NFV would have to address, and everyone who was involved in that process knows how hard I tried to convince both vendors and operators that key issues were being ignored. It’s now 2016, and we’re now just starting to address them. Could we have today a complete NFV implementation to deploy if we’d accepted those issues in 2013 when they were first raised? My point isn’t to aggrandize my own judgment; plenty of others said much the same thing. Many are saying it now about IoT. Will we insist on following the same myopic path, overlooking the same kind of issues, for that technology? If so, we’re throwing out a lot of opportunity.