Rethinking IOT and AI for future – I don’t want to take cloud to a drone fight !

IOT has always fascinated me. As a young developer in the 90s, I made a living doing mostly integration work – making two computers talk somehow . And then I moved into the world of data management and analytics. IOT is one of those things that just combine all the good and bad of what I know from my data and integration background. It is of particular interest off late to me given its part of the portfolio I lead at IBM – so I have a practical need to understand it better and think about where it is headed.
When I think of IOT – like many others, the first thing I think of is mobile phones to get the idea clarified in my head. 

I started with “How does an app really work ?” . You do something with the app as a user -leading to some minimal processing that happens in the phone using its RAM and CPU and then some information gets sent to a server somewhere ( as in cloud) where it does the heavy lifting and then it sends  back simple instructions back to the phone. Rinse and repeat for every action . 

The computers in the data center and the processing power of the phone are all improving exponentially . What is not keeping pace is network bandwidth. Network is the biggest bottleneck today and with the explosion of data that we live with today – its going to choke even more tomorrow . This is already true for non IOT world – for example I know SAP Hana projects that could not go forward because of insufficient network capacity . 

That is just phones. What about all the other “smart” devices that have processing power ? Everything from toothbrushes to cars already have, or will have, significant processing power soon . And that is only going to increase over time. 

I don’t know for sure – but between our two cars, I am guessing there are couple of hundred processors sitting in my garage as I am typing this. And my cars are not Teslas,  which probably have many more. As “things” stop needing humans to do their “thing” (see what I did there cleverly ? )  – they will have more and more processing power and local memory. They will generate even more data that needs to be analyzed quickly . And “network” as we know it will be toast dealing with all the traffic .

Already machine generated data is many times bigger than human generated data. These “things” won’t rely on “small data” to work without humans – this will be the “real” big data challenges we need to solve. It won’t be simple text files that count as data – it will be things like sound and video. 

The volume, variety and velocity of data will become quite unmanageable if we wait for these things to ping the cloud , transfer data and get a result back. You don’t want a drone to crash into something because it could not reach its cloud source to exchange data and find out how to land. You get the general idea – things that need quick request/response generally cannot work like how the average phone app works today. Even the next gen of phone apps probably can’t work like how they work today !

So what is the big deal ? Well – the current thinking on systems architecture needs some refresh. Maybe a significant refresh !

I don’t think cloud will go away per se. Just that it will become more “hybrid” in nature. My purist cloud friends who hate the term hybrid cloud will probably yell and scream at me – but for now, I am going to take the heat on that 🙂

What I mean is – a lot of processing where latency is a critical factor – the “things” will become mini clouds themselves. I am sure there is (or will be) a better term for it – but till then “mini cloud” is the official technical term for me. 

These mini clouds might be very powerful – many CPUs/cores/storage/RAM etc – and should be able to do pretty much all real time processing, and also be capable of some point to point interfacing. 

For example if I ordered Sushi and my wife ordered a burger – and two drones are trying to both land in our front yard to deliver our orders – they should be able to talk to each other on who lands first and not wait for both to talk back and forth with their respective clouds. If there are only two drones – perhaps we can tweak existing infrastructure and design patterns to make this work. But what if there are two million drones over my city doing different things ? I don’t want to take cloud to a drone fight !

My other passion is AI and analytics . How do they play in the IOT world ? Well – they need to play in two places at least . A micro version needs to play in the “thing” (the mini cloud) and a “macro” version needs to play in the traditional cloud . And there might even be a third version that brokers information flow in the middle . 

The reason is straightforward  – things need to make autonomous decisions like a drone figuring out where to land given what it can sense . There might not be enough time to ping the cloud and get an answer and hence the mini cloud needs algorithms that help with the task at hand . But this way the drone never gets much better beyond what is already coded . For the drone to get better at its job – it needs to learn from every other drone , as well as some external data like weather etc . In some smaller scenarios I guess point to point interfaces can solve this problem . But at scale – this would mean the big cloud runs advanced algorithms ( probably AI types ) and what it figures out gets shared with all the drones that it serves . 

This is a non trivial problem . Just to reliably sync regular text databases in a distributed system makes life complicated for IT shops around the world today despite such techniques being available for a long time . Just getting one set of machine learning models going is a pain for many teams . IOT just makes it much harder problem to solve – especially considering different vendors might own what goes into the brains of a drone and what goes into the centralized cloud . 

Not to make it more complicated – there are all kinds of “quality of service” questions to be considered too like performance , security , disaster recovery, standards and so on . And of course there are the unknowns – like what happens if a brand new communication protocol comes up that eliminates the network bandwidth problem ? 

Not all scenarios need all the bells and whistles of the drone example I used to make my case . A smart toothbrush probably doesn’t need as much sophistication to reach its peak potential compared to a drone . What that means is that whatever is the future architecture we come up with – it needs to be “sliding scale” friendly . Otherwise at a minimum the economics might preclude scale and viability of the solution . 

Interesting world eh ? If this kind of work fascinates you , let me know – I am always hiring 🙂