Overview of how IBM Edge Computing for Devices works

IBM Edge Computing for Devices is designed specifically for edge node management to minimize deployment risks and to manage the service software lifecycle on edge nodes fully autonomously.

IBM Edge Computing for Devices architecture

Other edge computing solutions typically focus on one of the following architectural strategies:

The former focuses authority centrally, creating a single point of failure, and a target that attackers can exploit to control the entire fleet of edge nodes. The latter solution can result in large percentages of the edge nodes not having the latest software updates installed. If edge nodes are not all on the latest version or have all of the available fixes, the edge nodes can be vulnerable to attackers. Both approaches also typically rely upon the central authority as a basis for the establishment of trust.

Illustration of the global reach of edge computing.

In contrast to those solution approaches, IBM Edge Computing for Devices is decentralized. IBM Edge Computing for Devices manages service software compliance automatically on edge nodes without any manual intervention. On each edge node, decentralized and fully autonomous agent processes run governed by the policies that are specified during the machine registration with IBM Edge Computing for Devices. Decentralized and fully autonomous agbot (agreement bot) processes typically run in a central location, but can run anywhere, including on edge nodes. Like the agent processes, the agbots are governed by policies. The agents and agbots handle most of the edge service software lifecycle management for the edge nodes and enforce software compliance on the edge nodes.

For efficiency, IBM Edge Computing for Devices includes two centralized services, the exchange and the switchboard. These services have no central authority over the autonomous agent and agbot processes. Instead, these services provide simple discovery and metadata sharing services (the exchange) and a private mailbox service to support peer-to-peer communications (the switchboard). These services support the fully autonomous work of the agents and agbots.

Lastly, the IBM Edge Computing for Devices console helps administrators set policy and monitor the status of the edge nodes.

Each of the five IBM Edge Computing for Devices component types (agents, agbots, exchange, switchboard, and console) has a constrained area of responsibility. Each component has no authority or credentials to act outside their respective area of responsibility. By dividing responsibility and scoping authority and credentials, IBM Edge Computing for Devices offers risk management for edge node deployment.

Discovery and negotiation

IBM Edge Computing for Devices, which is based on the Open Horizon project, is primarily decentralized and distributed. Autonomous agent and agreement bot (agbot) processes collaborate on the software management of all registered edge nodes.

An autonomous agent process runs on each Horizon edge node to enforce the policies that are set by the edge device owner.

Autonomous agbots monitor the deployment patterns and policies in the exchange and seek out the edge node agents that are not yet in compliance. Agbots propose agreements to edge nodes to bring them into compliance. When an agbot and agent reach an agreement, they cooperate to manage the software lifecycle of edge services on the edge node.

The agbots and agents use the following centralized services to find each other, establish trust, and communicate securely on IBM Edge Computing for Devices:

Centralized and decentralized services

Horizon exchange

Horizon exchange enables edge device owners to register edge nodes for software lifecycle management. When you register an edge node with Horizon exchange for IBM Edge Computing for Devices, you specify the deployment pattern or policy for the edge node. (At its core, a deployment pattern is simply a pre-defined and named set of policies for managing edge nodes.) The patterns and policies must be designed, developed, tested, signed, and published in the Horizon exchange.

Each edge node is registered with a unique ID and security token. Nodes can be registered to use a pattern or policies provided by their own organization, or a pattern that is provided by another organization.

When a pattern or policy is published to Horizon exchange, the agbots seek to discover any edge nodes that are affected by the new or updated pattern or policy. When a registered edge node is found, an agbot negotiates with the edge node agent.

While Horizon exchange enables agbots to find the edge nodes that are registered to use patterns or policies, Horizon exchange is not directly involved in the edge node software management process. The agbots and agents handle the software management process. Horizon exchange has no authority over the edge node and does not initiate any contact with edge node agents.

Horizon switchboard

When an agbot discovers an edge node that is affected by a new or updated pattern or policy, the agbot uses the Horizon switchboard to send a private message to the agent on that node. This message is an agreement proposal to collaborate on the software lifecycle management of the edge node. When the agent receives the message from the agbot in its private mailbox on the Horizon switchboard, it decrypts and evaluates the proposal. If it is within its own node policy, the node sends an acceptance message to the agbot. Otherwise the node rejects the proposal. When the agbot receives an agreement acceptance in its private mailbox in the Horizon switchboard, the negotiation is complete.

Both agents and agbots post public keys in the Horizon switchboard to enable secure and private communication using perfect forward secrecy. With this encryption, the Horizon switchboard serves as only a mailbox manager. It is incapable of decrypting the messages.

Note: Because all communication is brokered through the Horizon switchboard, the IP addresses of the edge nodes are not revealed to any agbot until the agent on each edge node chooses to reveal this information. The agent reveals this information when the agent and agbot successfully negotiate an agreement.

Edge software lifecycle management

After the agbot and agent reach an agreement for a particular pattern or set of policies, they collaborate to manage the software lifecycle of the pattern or policy on the edge node. The agbot monitors the pattern or policy as it evolves over time, and monitors the edge node for compliance. The agent locally downloads software on the edge node, verifies the signature for the software and, if verified, runs and monitors the software. If necessary, the agent updates the software and stops the software when appropriate.

The agent pulls the specified edge service Docker container images from the appropriate registries and verifies the container image signatures. The agent then starts the containers in reverse dependency order with the configuration specified in the pattern or policy. When the containers are running, the local agent monitors the containers. If any container unexpectedly stops running, the agent relaunches the container to attempt to keep the pattern or policy in compliance on the edge node.

The agent has a limited tolerance for failures. If a container is repeatedly and rapidly crashing, the agent will give up restarting the perpetually failing services, and will cancel the agreement.

Horizon service dependencies

An edge services can specify in its metadata dependencies on other edge services that it uses. When an edge service is deployed to an edge node as a result of a pattern or policy, the agent will also deploy all of the edge services that it requires (in reverse dependency order). Any number of levels of service dependencies is supported.

Horizon Docker networking

Horizon uses Docker networking features to isolate Docker containers such that only the services that require them can connect to them. When a service container is started that depends on another service, the service container is attached to the private network of the dependent service container. This facilitates running edge services authored by different organizations, because each edge service can only access other services that a listed in its metadata.