When your IoT goes dark: Why every device must be open source and multicloud

[The AchieVer]

When your IoT goes dark: Why every device must be open source and multicloud

The open sourcing of a device stack, the cloud APIs, and cloud services "glue" needs to happen during the entire lifecycle of an IoT product -- not at the end of its life.

 

 

 

Earlier this month, owners of the Jibo personal social robot -- a servomotor animated smart speaker with a friendly circular display "face" that underwent $73 million of venture capital funding -- saw their product's cloud services go dark after the company had its assets sold to SQN Ventures Partners in late 2018.

 

The robot, aware of its impending demise, alerted owners with a sad farewell message:

"While it's not great news, the servers out there that let me do what I do are going to be turned off soon. I want to say I've really enjoyed our time together. Thank you very, very much for having me around. Maybe someday, when robots are way more advanced than today, and everyone has them in their homes, you can tell yours that I said hello. I wonder if they'll be able to do this."

What Jibo, no "Daisy?" So disappointing.

THE ABANDONWARE ISSUE

Once disconnected from its cloud service, which provided all voice-based processing and other key analytics, Jibo's functionality became extremely limited. Similarly, Amazon Echo is dependent on its Alexa intelligent agent. If any services component of AWS, which Alexa uses, is down, or if the device is disconnected from the internet, just about the only thing you can still do with it is use it as a Bluetooth speaker.

 

That's exactly what happened when Aether, another voice-activated smart speaker, and its cloud service music streaming partner, Rdio, went bankrupt in December 2015.

 

The list of IoT products over the past several years that have become abandonware is embarrassingly long. And it hasn't happened only with small venture and crowdfunded companies like Jibo; it's also happened with smart hub products like Revolv and Netgear's VueZone home security product.

 

Look, I am the first to admit I am a major cloud proponent for enterprise computing, and I love the technology for the type of home automation that IoT brings to the table. But this abandonware issue with IoT devices, especially for expensive products like Jibo or devices that control key infrastructure components of a home, such as lighting and thermostatic and ventilation devices, needs to be dealt with now.

 

I'm not so much concerned with products that are issued by a major cloud hyperscaler such as Amazon or Google or Microsoft. Those companies have a history of supporting their products for a very long time after they have been discontinued, and in a number of cases -- such as with Google and Revolv and Microsoft and its Band -- they have issued full refunds to customers when they have had to discontinue back-end cloud services.

 

My issue is more with the small- to medium-sized companies that use cloud providers, or worse, their own data centers with proprietary software stacks with weird homegrown stuff to run the back-end systems for all the IoTs.

 

MITIGATING THE RISKS

Over the years, in addition to products like Nest, Ecobee, and Ring, and Jandy's poorly run and long-in-the-tooth iAqualink, I have installed a number of hub and app-controlled devices in my home, such as Haiku fans and lighting controls, Belkin Wemo smart plugs and smart switches, Philips Hue bulbs, and most recently, Lutron's Caseta, which not only does all of the above to enable you to transform dumb lights and fans into smart ones, but also provides app and cloud control for smart shades that automatically lower and raise, depending on pre-set programming or from localized sunshine data.

 

I think that, for the most part, I've mitigated the risks of cloud abandonware by going with some large industry vendors that have been around for a long time or are at least financially healthy. But I am sure there are a lot of folks out there who have not been so lucky and have found their devices abandoned in some way after a vendor goes belly up or decides to no longer support a product line -- requiring them to replace the devices in question. 

 

In some cases, it's just a hub communication device, and that can be swapped out for another. But if it's a proprietary line of smart switches and controllers, or something like a Jibo, it might be quite a few devices that need to be replaced.

 

         

 

IS THERE A SOLUTION?

Well, with Jibo, it is highly dependent on analytics and AI services -- if not the entire stack, at least the kernels for these devices. The back-end stacks running in the cloud need to be set up in some kind of "what if the company dies or the products are abandoned" trust.

 

The APIs and unlicensed parts of the stack for the device and its managing cloud service should be open sourced so that the cloud service can either be taken over by a not-for-profit or another interested party, or that another cloud service can be swapped in and out so that the device doesn't lose major functionality. 

 

Ideally, this open sourcing of device stack, the cloud APIs, and cloud services "glue" needs to happen during the entire lifecycle of an IoT product -- not just at the end -- so a consumer can jump ship to another cloud back-end at any time. It would be no different than the way a consumer might switch internet providers, wireless carriers, or a TV content provider.

So, for example, Amazon, or a similar company producing an Alexa-based smart speaker device, could release the APIs for voice control and playback and audio capture as well as the SDKs into open source. This would allow an Amazon Echo to run on Azure with Microsoft's Cortana or even on Google Cloud and Google Assistant. Alternatively, Apple's HomePod could run on any of those clouds, potentially.

NO SMALL FEAT

Obviously, swapping one equivalent cloud service for another after the fact -- even with the best of open sourcing scenarios -- is not as easy as it sounds. If the cloud infrastructure is IaaS-based, it's one thing to move a set of VMs or containers from one cloud to another; it's certainly not trivial, but it isn't impossible either. 

 

But if it is PaaS or SaaS-based, or some combination of all three, it might not be able to be moved. It might have to be re-architected entirely, which is no small feat. 

This is going to be the case as companies that develop cloud services move more toward finished PaaS and SaaS services to run application code instead of IaaS and containers, and the cloud hyperscalers begin to implement functionality that is specific to the cloud implementation.

 

 

 

Source