Seattle and Fog Computing: Bringing the Cloud Closer to the IoT

There is no doubt that cloud computing, in one form or another, is here to stay. In 2017, Gartner, a prominent research firm, estimated an 18% growth in worldwide revenue from the technology by year’s end, to a total of $246.8 billion. In the light of this growth, it is perhaps not surprising that cloud computing has already birthed a number of alternative configurations. Unfortunately, the alternative configurations have also given birth—to a messy hodgepodge of terminology, such as edge computing, mist computing, cloudlets and fog computing.

The problem with this situation is that these terms are often used interchangeably, even when the systems they describe have significant differences. In addition, without standardized terminology, it is difficult to establish a timeline for the development of a technology. For example, while the term “fog computing” may have been commonly used only in the last two to three years, incarnations of what could be called the basic principle of fog computing—replacing a centralized cloud with distributed units that can do all the necessary computation in a data hub on a smart device, or in a smart router or gateway—have been around almost since the beginning of the cloud itself. One such example is SSL’s own Seattle Testbed, which for close to a decade has allowed researchers to securely run code on a variety of device (laptops, tablets, smartphones) using computation power and storage donated by universities and individuals.

Last year, the National Institute of Standards and Technology stepped in to “clear the fog” and provide some needed clarity to how we talk about this technology by publishing a document of accepted definitions, characteristics, acronyms and abbreviations. The brief report, called simply “The NIST Definition of Fog Computing,” sets out to provide “clear distinction” between “fog computing…and related concepts.” The official definition for fog computing put forward in the document is:

Fog computing is a horizontal, physical or virtual resource paradigm that resides between smart end-devices and traditional cloud or data centers. This paradigm supports vertically-isolated, latency-sensitive applications by providing ubiquitous, scalable, layered, federated, and distributed computing, storage, and network connectivity.

The NIST document could not be more timely as fog technologies will be relied on to support the growing computing needs of smart devices on the Internet of Things (IoT). The “fog computing” label is a playful interpretation of the way the architecture of such systems “brings the cloud down to the ground,” by closing the gap between where data is created and where it is acted upon. In principle, fog computing systems can perform tasks faster and more efficiently, as they eliminate the need to send everything to the cloud for processing. And, with the Gartner firm estimating that, in just two years time, there will be more than 20 billion smart devices, the flexibility and distributed nature of fog computing systems will be needed to support that growth.

The researchers involved with the aforementioned Seattle made the case last fall for why it is in a good position to support the “vertically-isolated, latency-sensitive applications” cited in the NIST definition. Fog computing comes with a number of challenges. The first is the rapidly expanding variety of smart devices.Yi et al. note that the variety of resources that can act as servers in a fog system range from “resource-poor devices such as set-top boxes, access points, routers, switches, base stations, and end devices, or resource-rich machines such as Cloudlet…a ‘cloud in a box’ available for use by nearby mobile devices.” As noted in a paper presented by SSL research professor Albert Rafetseder at the inaugural Fog World Congress last November, Seattle is already running on a variety of heterogeneous nodes, or alternative platforms, such as Android devices, resource-limited structures like Raspberry Pis, or routers and embedded devices running OpenWrt. In addition, the “loose coupling and precise trust boundaries” of Seattle’s components enable “deployments with minimal mutual trust requirements,” and allow new infrastructure components to be “introduced freely to replace or augment existing ones, as long as the component interfaces are adhered to.” This supports the distributed nature of fog systems.

Most importantly, according to the paper’s authors — Rafetseder, Lukas Pühringer, and Justin Cappos —Seattle’s proven track record in protecting the safety of host devices and the security of any data on them as a plus for its use in fog computing applications. Seattle’s sandboxed environment, which isolates code run on the devices from other applications and data, also imposes strict usage quotas for all resources of the hosting system, including Central Processing Unit (CPU) time and memory, used disk space, and even IP addresses and port numbers on network interfaces. And, from a security standpoint, isolation keeps buggy or deliberately destructive code from harming the host machine.

Since fog computing is still in its infancy, it may be too soon to predict what components or systems will ultimately become standard. In a conversation conducted shortly before the paper was presented, Rafetseder described the “uncertainty” attached to the Fog concept. “We don’t know if it will be widely deployed, what deployments will actually look like, or what companies and use cases there will be. However, we know from experience with Seattle that our architecture is quite well prepared for whatever shape the landscape will turn out to take.”

Note: The final version of the NIST publication must be purchased, but the draft circulated for comment last August is available free of charge at (https://csrc.nist.gov/csrc/media/publications/sp/800-191/draft/documents/sp800-191-draft.pdf). The final draft, released by the 4th Watch Publishing Co. in November, can be ordered in both Kindle and print formats from Amazon.