posted

0 Comments

Bask Iyer, in this article from Aug ’16, discussed VMware’s entry into the IoT market: “IoT is said to be the largest addressable market since the advent of the Internet, and the true potential of IoT has yet to be realized in the enterprise. As a company that has been delivering technology innovations to enterprises for nearly 20 years, we will leverage our core strengths around device management, operational analytics and security to help bring specific IoT offerings to customers,”

VMware’s IoT products are based on a three-tier architecture, where an IoT gateway function acts as a proxy for devices with respect to services; see Figure 1. For a simple device, this function may reside on a separate system, while for a complex one it may reside on the device itself. This architecture avoids device direct exposure to the Internet by fronting them with secure gateways, hardened with the latest and greatest security mechanisms and patches. (Case in point: “The 10/21 attacks were made possible by the large number of unsecured internet-connected digital devices, such as home routers and surveillance cameras.”)

Figure 1 – The three-tier IoT architecture

 

The services that process the data could be on prem, private or public clouds, or combinations thereof (hybrid clouds). Edge computing (services on-prem, aka fog computing) is important for IoT, motivated by corporate data privacy, and by avoiding WAN latency and traffic. An example of a hybrid on-prem/cloud service is a surveillance system, where incident detection is performed locally through the costly continual analysis of camera feed; however, incident footage is archived remotely. Only the occasional incident footage is transmitted on the WAN, and thus is protected for future access in case an intruder vandalizes the local equipment.

 

The IoT landscape today is diverse and complex, with no dominating platform or standard, as discussed and illustrated in this Harvard Business Review article: “In an emerging ecosystem, integration of devices and services and interoperability between competing platforms are significant challenges.” The included illustration shows about 30 IoT platforms, each with dozens of related solutions. Furthermore, in a survey by the IIC presented in the Coronado Dec ‘16 meeting, 70% of respondents cited “interoperability” as the main impediment for deploying IoT systems, while “security” came at a distant second at 14%.

In June ‘16, VMware announced Liota (Little IoT Agent), a vendor-neutral open source software development kit (SDK) for building IoT applications. Liota provides a framework, terminology, discipline, set of APIs, etc., based on the three-tier IoT architecture, to address the interoperability challenge. Liota embraces the diversity of device standards, instead of waiting for one to dominate. It provides a solid starting point for harmonization across these standards, and a recipe on how to extend towards industrial scale IoT systems.

An important characteristic of Liota is its simplicity and minimalist approach. Liota runs on the gateway, and has a small footprint of dependencies. It should run on any gateway that supports Python, independently of what OS or what processor architecture it is based on. It ran on all gateways we tried it on, including the minimalist/low cost Raspberry Pi.

APIs provide contracts, where a developer (a handler) interfaces a device to a published API; while another (a solution provider), accesses the device and its data through this API. Therefore, Liota’s APIs provide for integration and interoperability across platforms and devices.

Figure 2 – the six main APIs in Liota and how they interrelate

 

Liota defines six main APIs, three that correspond to the components in the three-tier architecture (Device, Edge System, Data-Center Component), two for communication between them (Device Comm & DCC Comm), and the final one for the data flow from device to service (Metric); see Figure 2. This provides a minimal set to represent a data flow from device to a data center component through a gateway. In future blogs, I will discuss the details of these APIs and their interworking.

Complementing its APIs, Liota deploys the open source process for addressing interoperability. Now that we are in Liota’s early days, building solutions will require implementing specific device standards to access their data. With the power of the collective, Liota will be enriched with community-contributed implementations, so that future adopters will need to do less to get started towards their industrial scale systems. Also, a growing set of implementations will inform us on how to enhance and extend Liota and its APIs.

In addition, Liota includes a package manager that supports the dynamic loading and unloading of Python components into a running process. This provides the flexibility to keep running Python programs nimble, and the ability to respond to changing conditions without disrupting a running system.

Furthermore, Liota provides for simulating large systems of virtual gateways and attached devices with attributes of real devices, which could be in the thousands and even millions, by using Docker containers on VMs. This enables testing IoT system components (e.g., data center storage or analytic services) at large scale, thus verifying their robustness and reliability before field deployment. It is very difficult to perform such large-scale robustness testing using physical devices.

With this series of blogs, I hope to clarify the workings of Liota and other VMware IoT products, and discuss its momentum as an open source project. You may visit https://github.com/vmware/liota for downloading Liota, and for more details and examples.