VMware and the Internet of Things: Motivating the Three-Tier Architecture
This is the first CTO blog post on VMware and the Internet of Things (‘IoT’) that right now is placed at the top of the Gartner Hype Cycle. In this first post in this series, I’ll lay out the latest thinking on the high-level structure of an IoT Infrastructure we see beginning to be established. Following installments will cover VMware’s strategy and how I see IEEE 1451 (Transducer Electronic Data Sheets) and the SI Units specification playing important roles.
Certainly, these days there is no hiding from the IoT craziness now flooding our industry. Reasoned estimates vary widely but, however one looks at it, or whichever estimate one believes, within the next five years we will see an explosion of connected devices (the ‘Things’ of the IoT) coming on-line within an emerging new infrastructure. The Things will generate a tremendously large stream of data (this is often referred to as ‘telemetry’); analytics on this telemetry will consume vastly more compute, network, and storage capacity than we have today, and generate trillions of additional value in and to society. Many refer to IoT as the integration of (traditional) IT and Operations Technology (‘OT’). OT is a catch-all term for compute, networking, and storage existing to control, manage, and operate the physical machines of our world (such as elevators, trains, factory robots, automobiles, rockets, etc.).
The modern term used for these types of physical machines that employ some form of digital control is a Cyber-Physical System (‘CPS’), a single machine instance in the OT world. Some say the acronym IoT is a shortened form of IT<—>OT. Yes, IT-OT convergence is a big part of the IoT, but IoT is also much more in that new parts of our world are being instrumented where no OT existed previously (e.g., automobile parking spaces). Underlying and enabling this analytic side of the IoT resides what I call the IoT-Infrastructure (‘ITI’) ITI comprises both the integration point where legacy IT and OT infrastructures meet and new infrastructures specifically created for IoT. In both these places, systems that have come to be known as ‘IoT Gateways’ will play a crucial role.
In the late 1990’s the term IoT first arose. Initially it was used to imply that every small CPS in the future would have its own connection to the Internet. Since then, many have realized that the two-tier architecture that connectivity implied would not meet the needs of the IoT. As a result, now the IoT is often thought of as a three-tier architecture: Cloud or Data Center, IoT Gateways, and the Things or CPSs. IoT Gateways do the following:
- bridge layer-0 media
- reduce CPS power demand requirements
- reduce CPS compute capacity requirements
- mitigate the vastly different expected lifetimes of IT and CPS
- dramatically reduce the attack surface exposed to malicious activities, given lower compute capacity on the CPS
We will look at each of these tiers in turn. For the legacy case of IT-OT integration, the layer-0 protocols in OT are unknown to the IT world. These arose from early control system field buses. There is a slow movement toward IT layer-0 media, but even then there are still differences because OT typically exists in much harsher environments. Thus, for some time systems will still be necessary to bridge across the media. For the newer ITI we see layer-0 bridging between Long Range WAN (‘LoRa WAN’) or other wide-area, low-power wireless and cellular networks. These types of IoT wireless networks are now being deployed in many places worldwide. An IOT gateway is required at the intersection.
Many CPS systems have strict power limitations (because they are battery powered) and compute capacity limitations. Compute capacity limits arise from power limitations, but also from the business model of their manufacturers. Consider home durable goods on which profit margins are razor thin and revolve primarily around the cost-of-goods per unit (aka ‘BOM costs’). Thus, in many CPSs very low cost wireless networking capability (e.g., Zigbee) may be preferred over higher cost wireless networking capability (e.g., WiFi) for some time to come. Once again the IoT gateway enables the low-cost, low-demand technologies to be bridged.
In the IT/Web/Internet/Mobile environment our understanding of the expected lifetime of a piece of software or hardware can range from as short as a few days to as long as a dozen months. Software updates and device replacements are the norm. However, on the OT/CPS side of IoT expected lifetimes are measured in years, if not decades. Consider your refrigerator–my favorite example! How often would you consider it reasonable to replace a refrigerator? I’ll claim most of us would keep a refrigerator for at least 10-15 years. Or consider the sensor in a parking space used to determine if the space is occupied or not. Here, the expected lifetime is about five years without attention (unless the sensor had failed and needs replacement). The IoT gateway can serve to mitigate this mismatch in expected lifetimes. Layer-0 connectivity to its attached Things can be maintained for an indefinite time while applications, web-side security, and communications protocols can evolve at a rate with which we are familiar.
Finally, and potentially most importantly, a vast reduction in attack surface is enabled with IoT gateways. To see this quickly consider the locations of the layer-4 and layer-5 endpoints in the two-tier and three-tier IoT architectures introduced above. In the two-tier architecture these endpoints reside in the Thing and in the Cloud or Data Center. In order to keep up with the rapidly evolving security protection environment of the Web, the applications and protocols on the Thing will be required to evolve at the same rate. This evolution may indeed require compute, storage, and networking capacities unimagined when the Thing was originally manufactured. Thus, if the layer-4/5 connection has to be maintained at a back-level version that’s been compromised because of the inability of the compute capacity to keep up then the attack surface is the full connection, i.e., the connection can be attacked from essentially anywhere on the planet.
Conversely, in the three-tier architecture the web side applications and protocols of the IoT gateway can evolve along with the web. In this case the attack surface of the outdated protocol is limited to the gateway-Thing link which is typically very small and local. Some people counter this argument by imagining that the compute, storage, and networking capability of the Things will increase substantially to follow that on the web side. Or, they offer another argument– that Thing manufacturers will provide enough capacity to keep up with the evolution of the web. I, and many others, do not see either of these as likely near-term solutions. Not only not for the legacy systems but neither for the newer CPSs. There will be continued downward price pressure on the Thing-side business models and designs. Mostly, this will arise from scale but also practically. E.g., who would consider an architecture in which all 5000+ sensors in a modern wind turbine have their own layer-4/5 connections to a cloud-side component? Rather, having these sensors communicate on their internal OT network to an IoT gateway makes more sense. The parking spot sensors mentioned before likely will opt for the local long-range, low-power wireless IoT network rather each sensor become a cellular endpoint as the former is much less expensive and has very low power demands but, requires an IoT gateway.
Next time I’ll discuss VMware’s IoT strategy.