Use of the cloud depends upon ubiquitous networking. And not just everywhere, but extremely high speed as well. This came to mind as I was sitting at the top of a mountain in a national park and heard someone ask Siri a question. Siri’s response was that the network was not in reach. This struck me as funny, then odd, then sent me down the path of ubiquitous networking. We are in the age of the Internet of Things (IoT), and if we do not have a network, then IoT fails rather spectacularly. So, what are the real requirements for IoT? 
We have already mentioned a ubiquitous network, and that network apparently needs to be a public network with everyone and everything on it. I feel, given how people are, that that network should also be the fastest network humanity can possibly make. People and things expect to transfer quite a bit of data in as short a time as possible. How many of you have upgraded your household, business, or organizational wireless to 5G Wi-Fi or 802.11ac? Granted, new wireless devices are faster, smarter, and much more secure, but the key is faster. People want access quickly. IoT transmits a huge amount of data.
As a fan of Disney’s Phineas and Ferb, I watched “Night of the Living Pharmacists,” and there was one part that was very interesting: Water is still running, power is up, and the network is there. Then, they all disappear in reverse order. Even kids’ shows are equating the network with a ubiquitous necessity of modern life. How will we react when it is not there? How will your customers react?
This implies that any cloud service you use or provide needs to be always up. However, “always running” does not necessarily entail “always available to everyone.” Just think of a person in a location where there is no high-speed network, or where towns are few and far between. This may be why we need to rethink the IoT, or at least the growing need for continually increasing network capability on our sites and tools. “Fast” is often at odds with “functionality,” especially in the case of networking. But this raises several questions:

  • What if I do not want my data to leave my premises?
  • What if my network is not available: does the system cease to function?
  • How can I seed data into an application if I know I will be leaving a ubiquitous networking area?

And these lead to several more about how we are developing our next generation of applications and IoT devices:

  • What are the failure modes if there is no network? For example, can we still make payments? Still get power? Still have running water?
  • Is there a possible on-premises appliance (virtual or other) we can use to keep data local? Do we really want our medical data (weight, BMI, pulse, blood pressure, glucose, etc.), household data (alarm status, alarm video, temperatures, light timers, etc.), and travel data (flights, GPS coordinates, fuel efficiencies, etc.) to be readily available to anyone with sufficient or hacked access on the ubiquitous network?
  • What are the failure modes for when the network drops and the application is temporarily unavailable to access, or for when some other network interruption occurs?

Some of these may be addressed by adding more security (such as encryption) into next-generation applications, or by placing applications in more availability zones, etc. However, not all companies can afford to do this. And even if they can, overloaded, slow networking within a region does not equate to “readily available.” Thus, we need to design our applications better by looking at things not only from the supplier side but also from the perspective of how the application is accessed and used.
With regard to web applications, there are a number of tools available to query them from all over the world: Akamai, ThousandEyes, and other tools come to mind. These look at things from the consumer side but also rely on ubiquitous networking. Do they have sensors in outlying regions of the world? Or less networking-dense areas of the world? Perhaps on top of a mountain somewhere?
Perhaps we need to start considering how much data our applications require and, from there, ensure we use as little as possible to make the application work. To optimize our traffic for lower bandwidths. In some regions in the United States and throughout the world, dial-up is still considered state of the art. What are your application’s networking requirements? Have you considered failure modes for lack of ubiquitous networking?