|By Tim Park||
|March 27, 2014 02:03 PM EDT||
End-user computing devices have followed a trajectory of faster, smaller, and cheaper for several decades: adding better connectivity, more natural interfaces, but largely remaining a device with a screen and human input device. This model is breaking down as computation and connectivity collide with ordinary real-world things. These things often have existing physical methods of interacting with them that we culturally don't want to change or no interface at all.
I've been involved with devices for much of my professional career, starting with television set top boxes at Microsoft for the better part of a decade, then working in mobile as part of the Android team at Google, and most recently in the Internet of Things at Nest Labs before rejoining Microsoft as part of our platform strategy team. In my current role, one of my focus areas has been to think about so called Internet of Things and what that means for the industry, for Microsoft, and for enterprises and consumers.
It's clear to me that the future of computing lies in these things. The screens in our lives will slowly start to take a back seat to a model of computing that operates off of the context that we generate. In this sense, computing will take a much more active role in our lives but at the same time much more invisible. That said there are substantial challenges in getting from where we are today to this future, and I thought I'd survey those problems and potential solutions.
In the broader Internet, we've started to think about connectivity as a given. The pervasiveness of networks and the consolidation of the industry around cellular standards like LTE and wireless standards like 802.11 mean that, for our computing devices, we are almost always connected and the design of applications has shifted from primarily offline to primarily online to match this.
One of the key challenges in the Internet of Things is that it doesn't fit cleanly into this. The existing set of wireless and cellular standards are wholly unsuited for long longevity battery use - they are designed for devices, like our computer or phone, that are always or frequently connected to a power plug.
A door lock is a good example of a real-world device. It isn't connected to a power plug. While one solution could be to change or charge the batteries in your door lock once a month so that it can use Wi-Fi, when you step back and realize that there are hundreds of these devices in the home, it's clear that this would quickly limit our desire to manage more than a handful of these in our houses.
Rethinking then how we connect these devices is one of the key challenges facing the industry. There are a number of efforts to solve this, including new protocols like Zigbee, but the most promising of these are the efforts to create highly efficient variants of existing protocols like 802.11 with 802.11ah or Bluetooth with Bluetooth Low Energy (now branded Bluetooth Smart). These technologies hold the promise to overcome rapid power consumption in these devices.
In many ways, Bluetooth Smart is already here. As part of the Bluetooth 4.0 spec, it has piggybacked its way into many of the latest Bluetooth chipsets and from a software platform perspective (Windows 8, iOS, and Android platforms all include support for it). Given this, it is starting to become prevalent with the latest wave of devices. It also promises multi-year battery life levels of efficiency and provides an abstraction mechanism for exposing data and control through its characteristics and services. I wouldn't be surprised to see Bluetooth Smart move front and center in 2014 as it gains critical mass as a key way of bridging to these real-world things.
The simplicity of these devices implies that what it means to be an application will also change. In this world, applications shift from being something with a user interface that runs on our devices and backed by the cloud to a model where an application analyzes the context provided by potentially a large number of these devices. The application will begin to present itself less on a screen and more in the state changes in the real world. These applications will not run on any one of these devices but between them.
One potential model for this that we are experimenting with at Microsoft is a messaging-based approach. You can conceptually think about this as "Twitter for devices" where devices and applications communicate using messages through a message broker. The schema for these messages is well known among the principals in the system, enabling applications and devices to communicate that otherwise have no knowledge of each other.
This is a key advantage because devices in this new world are shifting from being consumption and creation devices to devices that provide context and control. A messaging-based approach allows you to leverage the message stream from one of these devices for multiple applications without correspondingly taxing this device with multiple requests for state. For example, a proximity sensor in your office hallway provides very interesting context for a security application for the building but is equally interesting to an application that uses them to make dynamic climate control decisions. A messaging model enables this with one set of state. It also provides a clean archiving and auditing model, enabling you to look back over this data two years later, for instance, when you want to build an occupancy model for your building across all of its proximity sensors.
The quantity and sensitivity of these devices will also mean that we need to rethink how we manage them and their data streams.
We currently manage an increasingly large number of computing devices in our lives, and while application stores have made it easier for us to install and upgrade applications and operating systems, we still spend a significant amount of time managing our devices.
As we increase the number of devices by an order of magnitude, we won't be able to provide this same level of love and care for every device in our lives. These devices are going to need to be largely autonomous. One of the core challenges of Internet of Things will be building the infrastructure to enable this level of autonomy.
Our current conception of devices working with services is largely a two-tier model. For many applications that require precise control, the 200ms latency involved in doing a round-trip from a home in Oklahoma to a data center in Virginia where multiple devices' message streams are combined may be too much. This means that applications that require this level of low latency will need to execute much closer to the edge. That said, there are many applications that will require the computational capacity and flexibility that only a larger public or private cloud data center can provide. One of the key challenges we face is providing a single abstraction for developers such that both these classes of application use the same interfaces and the infrastructure is smart enough to satisfy them transparently.
The data streams involved in the Internet of Things are also typically highly sensitive, either in the context that they provide on us or the sensitivity of the equipment that they control. One of the things we must demand as individuals and enterprises is control on what set of data we send to a centralized public cloud versus retain within systems under our control.
I believe these factors will drive a distributed approach to the Internet of Things, where applications move to the data instead the current direction of all of our data moving to the applications in the public cloud. At Microsoft we are currently experimenting with this hybrid approach, where there are several hierarchical tiers of increasing computation and storage as you go toward the cloud. Applications and data in this model flow between these tiers to the appropriate level that balances computational, latency, and privacy concerns. This distributed approach is also another key reason that an immutable messaging-based approach makes sense - it enables you to replicate these message streams between these tiers in the system while applying permission-based controls to filter them down to the messages you are comfortable sharing with another application or computational tier.
One thing that is clear is that the volume of data that is generated from these much more numerous devices will be staggering. For example, capturing all of the data from a single car's lifetime in an enterprise fleet requires upwards of 100GB on a relatively spacious once-a-second resolution. For an enterprise like Avis, which has on the order of 150,000 cars, this means managing nearly 15PB of information over the lifetime of one generation of cars.
As an industry we have established batch algorithms and platforms like map/reduce and Hadoop and newer near real-time platforms like Storm to process these large streams of information - but these still require substantial data science and DevOps investments to operate, which put them out of the reach of smaller organizations. A key challenge is making it easier to run data pipelines that operate on the context these devices generate and building abstractions that make them easier to develop for and to use with existing information worker tools.
We are at the very beginning of this transformation and are all still trying to get our heads around the right model that solves the problems in this space. Although I've posed a number of potential solutions in this post, you should take these more as strawmen to start a discussion than any concrete recommendation. I'd love to talk with you if working on any problems in this space - feel free to reach out to me at [email protected] or @timpark on Twitter.