When does it actually make sense to use a local cloud? One great way to characterize some types of local clouds is by their scope: a single idea that groups all the nodes in the cloud.
Personal local cloud: (also called a “personal area network”) There are potentially as many personal, deca-clouds as there are people. The cell-phone is the leading candidate for the compute node in this network. But I can envision that we carry another, more powerful and probably somewhat more bulky, compute node device that lives out of sight in a backpack or purse. Other nodes in this cloud would be watches, heart-rate monitors, etc. But importantly, these personal clouds could be isolated and independent from all other clouds (based on personal preferences). The bulk of the data never needs to leave this cloud. Hacking this cloud gives the hacker only one person’s data, which dramatically limits the hacker’s value. Getting data on millions of people, requires hacking millions of independent personal clouds.
Car cloud: This is a small deca-cloud (10) or hecto-cloud (100) that is local to a single car or vehicle. The master compute node is contained somewhere in the car chassis. It also contains nodes for the dashboard display and all kinds of other cool features. Existing cars already have multiple (hundreds) of on-board computers that could in connected to the car’s cloud. The most recent CES conference contained lots of interesting, new automobile functions, and all of these should be included in the car’s local cloud. Again, if we localize most of the car cloud’s data to the car, privacy is enhanced.
Traffic intersection cloud: There is value in having adjacent cars in limited communication with each other. Organizing a cloud around a traffic intersection is one concrete example. Here all the cars that enter the geographic neighborhood of a particular traffic signal, join the cloud, and share data about input and output directions, exact arrival times, urgency, etc. The traffic intersection cloud would use this to adjust (physical or virtual) traffic light timings. The primary compute node is physically located in that intersection. Cars leave the local cloud when they leave the intersection.
A different example is forming local clouds around groups of adjacent cars traveling down an interstate. The cars intercommunicate to smooth and optimize local traffic flow. There are no physical nodes dedicated to this kind of traveling cloud; each car provides compute resources and interconnects with other cars.
House cloud: Houses and apartments provide another great example of local clouds. There could be one or more compute nodes in the house that interconnect with refrigerators, other heavy appliances, security systems, entertainment systems, Christmas lights, etc. All kinds of businesses will want to get their hands on pieces of this data, but why should we let them?
Neighborhood cloud: A group of adjacent houses could get together to form a neighborhood cloud. Many neighborhood clouds will have no nodes dedicated to the neighborhood; all nodes are associated with one of the member houses. But wealthy neighborhoods might have dedicated security cameras and gate controllers.
Traveling Car cloud: This is a short-lived, variation of the neighborhood cloud. All cars within, say 100 meters of each other dynamically form a cloud. Lead cars transmit traffic and road conditions to following cars. Which corporations REALLY need to get their hands on data in this cloud? What would they do with it that benefits the cars in the group?
In all of these examples, there is no reason to send all of this data to some single, giant, centralized giga-cloud. No reason other than to allow the giga-cloud owner to mine all that data and sell your information to advertisers and other buyers for who knows what purposes.
I realize there is not a black-and-white distinction between local and global clouds; the situation is gray because clouds can and will be interconnected. But the local vs. global terminology emphasizes that we don’t need or want massive global clouds for many, many kinds of data. Data, and the clouds that contain it, should be as local as possible.
Unfortunately, local clouds do not automatically protect data — they are just an enabling conceptual element. This inevitability leads to the “measures & counter-measures” games: for each measure we implement, spies will implement new counter-measures. And for every counter-measure, we need to respond with yet a new measure. This is a game we have to play.