Eclipse Hono: ''Connect. Command. Control.'' Even on OpenShift!

The Eclipse Foundation is the main open source community that has a great focus on the Internet of Things world. The related Eclipse IoT ecosystem involves a lot of different projects and partners like Red Hat, Bosch, Eurotech, IBM, and many more. Recently, publishing this white paper, they showed a full stack with all the available tools for building a complete IoT solution from devices to the cloud through the gateways.

In relation to the cloud side, one of the main problems in the IoT world is the ability to handle millions of connections from devices (and gateways) in the field, their registration for managing authentication and authorisation and, last but not least, the ingestion of the data received from them like telemetry or events. Finally, the last point is related to controlling these devices, sending them commands in order to execute actions in the environment around them or upgrading their software and configuration.

The Eclipse Hono project is the answer to these problems!

From the official web site, we can read:

Eclipse Hono provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

The mantra from the landing page of the web site project is “Connect. Command. Control” which is made a reality through a well-defined API for:

• Registration for handling requests related to registration (creation) of a new device so that it can be authorized to connect. It’s also possible to retrieve information about registered devices or delete them.
• Telemetry for the ingestion of a large volume of data from devices (i.e sensors) available for analysis to backend applications.
• Event for receiving specific events (i.e. alarms, notifications, etc.) from devices for making decisions on the cloud side. This API is quite similar to a telemetry path, but it uses a “different” channel in order to avoid such events going through the overwhelmed telemetry portion.
• Command and control for sending commands to the devices (from a backend application) for executing operations and actions in the field (receiving the related response) and/or upgrading local software and configuration.

All the above APIs are accessible through the AMQP 1.0 protocol (the only standardized AMQP version!) and it means that they are defined in terms of addresses on which devices need to connect for interacting with the system and the properties/content of the messages; of course, that's true not only for devices but even for business and backend applications, which can receive data from devices or send them commands. In any case, it doesn’t mean that devices that aren’t able to speak the protocol can’t connect. They can leverage the protocol adapters provided by Hono; the current implementation provides an MQTT and HTTP REST adapter.

All these APIs are though in order to allow multi-tenancy so that, using a single deployment, it’s possible to handle channels for different tenants so that each of them can’t see data or exchanged messages from the others.

The Architecture

The main components that build the Eclipse Hono architecture are:

1. Protocol adapters: These components adapt a device protocol to the first-class citizen used in Hono, AMQP 1.0. Today, MQTT and HTTP REST adapters are provided out of box, but thanks to the available interfaces, users can develop a new adapter even for some custom protocols.
2. Hono server: This is the main component to which devices can connect directly through AMQP 1.0 or through the protocol adapters. It’s in charge of exposing the APIs in terms of endpoints and handling the authentication and authorization of devices.
3. Qpid dispatch router: This is an AMQP 1.0 router, part of the Apache Qpid project, which provides the underlying infrastructure for handling millions of connections from devices in the field. The simpler deployment can use only one router, but in order to guarantee reliability and high volume ingestion, a router network should be used.
4. ActiveMQ Artemis: This is the broker mainly used for handling the command and control API — for storing commands that have to be delivered to devices.

While the devices connect directly to the Hono Server (or through protocol adapters), the backend applications connect to the Qpid Dispatch Router, leveraging direct addressing for receiving telemetry data (if no application is online, no devices are able to send data) or sending commands (the queues in the broker are reachable through the router).

All the artifacts from the project are provided as Docker images for each of the above components that can be run using Docker Compose (Docker Swarm support will be available soon) or using a more focused cloud platform like OpenShift (compatible with Kubernetes deployments as well).

Regarding the OpenShift deployment, the building process of the Hono project provides a bunch of YAML files that describe the objects to deploy, like deployment configurations, services, persistent volumes, and related claims. All you need is an accessible OpenShift platform instance for you to deploy those objects. That's how Eclipse Hono runs in a full-featured cloud environment with all the related scaling capabilities.

The example deployment is based on four pods, one for each of the main components. There is the router pod, the Hono Server pod, and one pod for each protocol adapter; of course if you need the command and control path, the broker pod needs to be deployed.

In order to try it, an OpenShift Origin instance can be used on a local PC for deploying the entire Hono solution; for example, the above picture is related to my tests where you can see all the pods running on OpenShift (left side) with simulated devices that interact with MQTT and HTTP REST (on the right side).

Conclusion

In my mind every IoT solution should be made of three different layers (a little bit different from the Eclipse vision): the devices/gateways, the connectivity layer, and the service layer.

While the Eclipse Kura project fits into the gateway layer and Eclipse Kapua tackles the service layer, Eclipse Hono is the glue between them in order to handle the connections from devices and making their data available to backend services (and vice versa in the opposite direction for command and control). Thanks to API standardization and the usage of a standard protocol like AMQP 1.0, Hono can be used for connecting any kind of device with any kind of service; of course, leveraging these three projects has the big advantage of having big companies working on them, mainly Red Hat, Bosch, and Eurotech.

Finally, the solution is always the same …. open source and collaboration!