Cloudless IoT: The Internet of Things, without the Cloud

Whether you like it or not, the cloud has become an integral part of the Internet of Things. But sometimes it is not practical, or desirable, to rely on an external cloud service to operate your IoT system. Regardless if your devices are tiny wireless sensors or street lights.

With our latest release of the Thingsquare IoT platform, we are adding the ability to run the Thingsquare IoT platform off the grid – away from the cloud.

We are not alone in believing in the idea of a cloudless IoT. In the IoT community, the concept is often called edge or fog computing. There are entire software platforms, such as the Litmus LoopEdge platform, Microsoft Azure Edge, and the Crosser IoT edge analytics suite, that are built to run off the grid. There are even custom hardware chips designed to support off-the-cloud computation, usually speech processing.

There also an old adage that the Internet of things without the Internet is just … things. This is not true: there are many situations where IoT systems without Internet can be as valuable as Internet-enabled IoT systems.

We at Thingsquare have built and deployed several cloudless IoT systems with the no-cloud version of our IoT platform, including:

• Electrical generators. These are deployed in a remote location where there is little or no Internet access.
• Industrial machinery. These are deployed as a completely standalone product with a separate touch screen on the local controller.
• Industrial lighting. These are run in places where customers want a completely siloed system.

For more background on how IoT platforms work, see our article on why you should use an IoT platform and the page about the Thingsquare IoT platform.

But let’s first look at why we use the cloud at all. Because there are good reasons for doing so.

Why IoT in the cloud?

There are good reasons for why the backend logic of an IoT system is run in the cloud:

• Data storage: The cloud can store an almost unlimited amount of data.
• Computation: Some mechanisms needs an abundance of computational power, which is something that the cloud can provide an almost unlimited amount of.
• Remote access: To provide users with remote access to the data generated by the IoT devices, or to control the devices themselves, you need to have a cloud service that connects the devices with their users.
• Access control: The cloud can provide effective access control mechanisms for your users.
• Data cross-referencing: To be able to run effective machine learning algorithms, you sometimes need access to a wide range of data. The cloud lets you collect data from more than one site to cross-reference and combine this data.
• Application integration: IoT systems rarely run on their own. Integration with other software systems is much easier if the backend is located in a single place: the cloud.
• Security updates: when the IoT backend is run in the cloud, a dedicated security team can keep track of and apply security updates as needed.

These reasons, which are good reasons, are why most IoT systems today are provided through the cloud. Thingsquare is no exception.

The backend portion of the Thingsquare IoT platform is originally designed to be run in the cloud. Sometimes the backend is running on a typical cloud provider like Amazon Web Services, and sometimes the backend is installed on a hosted machine, as a traditional on-premise software package.

But the running the IoT backend in cloud does come with some drawbacks.

Why cloudless IoT?

There are good reasons to not rely on an always-on cloud connection for every IoT project:

• Stability: cloud services may go down so avoiding the cloud may therefore increase stability.
• Persistence: cloud services may go away so avoiding the cloud may allow the IoT system to run for ever, without relying on the hosting company to persist.
• Data privacy: sometimes data should not leave the location where it is generated.
• Security: fewer network connections means fewer attack vectors.
• Necessity: sometimes there just isn’t Internet access.

Any cloud-based software may become unreachable if the cloud goes down. This can happen even for companies like Google, who arguably has state-of-the-art cloud infrastructures and one of the best cloud teams in the world. Any IoT solution that wholly depends on the cloud will suffer an outage if the cloud goes down.

Because the cloud service is a living thing, it may die. This can happen if the company that runs the service goes away or if it simply decides that it is no longer economical to keep it running. There are several real-world examples of this.

But the most compelling reason to why use a cloudless IoT system is when Internet access is unavailable. At Thingsquare, we have been working with projects where the IoT system is deployed in rural Africa, where Internet access is spotty at best. And with projects in countries Internet access has been generally available, but where the IoT system has been inside a deep cellar where 4G access was impossible.

The challenges of cloudless IoT

Moving the IoT backend away from the cloud, closer to the IoT devices presents a number of challenges:

• Authentication: authentication is significantly easier with the cloud, thanks to mechanisms such as 2 factor authentication.
• Remote access: providing remote access without the cloud is very difficult and in most cases impossible.
• Data processing: crunching numbers without having access to the abundance of storage and computation that the cloud provides is significantly harder.
• Software deployment: many IoT systems need data processing or similar mechanisms, and these systems are often designed to be run in the cloud.
• Software updates: software is a living thing and needs to be kept up to date.

These issues result in trade-offs. Any IoT system that is deployed away from the cloud must be prepared to deal with them.

A practical approach to a cloudless IoT

Thingsquare takes a deliberately simple approach to the cloudless IoT:

• We run our IoT backend on a non-connected local controller
• Deal with resulting the trade-offs on a case-by-case basis

The local controller can run on a piece of hardware similar to a Raspberry Pi. The local controller is deployed on an on-site network and we provide a user interface over that network only. The user interface is accessible through a smartphone app, which can detect nearby local controllers via Bluetooth, and let users interact with devices.

The backend logic of the IoT application, which would normally run in the cloud, also runs on the local controller. This also means that the backend application must be scaled down to the limits of a Raspberry Pi-class device.

Since we cannot expect the local controller hardware to be as robust as a cloud host, particularly if the local controller is based on an SD drive, we limit disk writes by storing volatile data in memory. This means that software that runs on top of the API must be prepared to deal with having access to less data.

User authentication

To authenticate users, we use a two-tiered approach. The first tier is to leverage the existing access control to the local WiFi. If a user is authenticated to the local WiFi, this tier assumes that the user also should have access to the local controller and its devices. It is possible to configure the access level that such non-authenticated local users should have.

The second tier uses a hybrid approach: we use the cloud to authenticate the user and provide an access token to the local controller. The local controller announces its presence with encrypted Bluetooth beacons that the smartphone app uses to authenticate each user. This requires the users to have an account in the cloud. The app checks with the cloud server to match the encrypted beacon and the user account. If the user has access, the server responds with an access key to the local controller.

Device authentication

Device authentication is comparatively easier than user authentication, because devices can be preprogrammed with TLS certificates. We there

Software delivery with a git repository

We deliver all software over a managed git repository. This repository can be updated by connecting the local controller to the Internet and requesting an update, or manually via a USB stick.

Firmware updates

Signed firmware update files are included in the git repository. Devices may request updates from the local controller, just as they do when they are connected to a cloud backend.

Because we use the full IoT backend software, full-network OTA updates work as usual.

User interface

The local controller may present a user interface with a touch screen physically connected to the controller, or over the WiFi to smartphone apps on the same network. By default, the user interface is implemented via HTML5/JS/CSS and is updated via the git repository.

Conclusions

The cloud is an integral part of the Internet of Things. But there are situations in which the cloud is not the best choice.

Thingsquare provides a local, cloudless IoT solution, based on the same software that is backing our cloud-based offering, that solves the problems with software delivery, user interface access, and firmware updates for the cloudless IoT.