In this blog series on edge computing, we have talked about deploying small-footprint apps onto Edge devices, but there have to be some rules and/or constraints surrounding their deployment.

The previous post in this series (“DevOps at the Edge”) alluded to the nuances associated with edge applications and their deployment—scaling, types of devices, application footprint, operating speed, and disconnected scenario.

We know edge devices come in different shapes and sizes, from high-quality video cameras to small sensors that are used to measure temperature, pressure, acceleration, etc. There are also industrial robots and connected cars which are a collection of different edge devices and are special use cases. It is impossible for an administrator to manage thousands of devices, and that is where policies come in handy.

Remember the HelloWorld app which outputs “Hello World” every three seconds? It was shown to run on a Raspberry Pi, and it probably could also run on an audio device. But it doesn’t quite lend itself to run on a camera and, as such, a policy could dictate that.

In this blog post, we take a look at the deployment policies available in the IBM Edge Computing for Devices product as an exemplar.

Please make sure to check out all the installments in this series of blog posts on edge computing:

Services and patterns

An edge service is a microservice or a workload. It is a containerized piece of logic that is deployed to an edge node. A service has a configuration (i.e., parameters that affect the container and/or the logic inside the container). A service can depend on other services, and that dependency can be captured in the configuration of a service.

A pattern is a way to deploy services to a node. A pattern is a somewhat static set of services that run together on a node. A node declares that it wants to run a given pattern, and IBM Edge Computing will deploy the services in that pattern to the node. This is the easiest way to deploy service, but it is not the most flexible way:

Figure 1: Edge pattern is made of one or more Edge services.

Exchange, agbots, and agents

There is an entity called the exchange that enables edge machine owners to register edge nodes for software lifecycle management.

Each edge node must be registered with the exchange under the edge machine owner’s organization. The registration consists of an ID and security token that is applicable only to that node. When you register an edge node with the exchange, you specify the deployment pattern for the edge node.

An autonomous agent process runs on each edge node and it enforces policies set by the edge machine owner. Simultaneously, autonomous agreement bots (or agbots) are assigned deployment policies that they use to deploy services to the edge nodes.

The agbots use the policies to seek out the edge node agents that have a compatible policy. Independently, these autonomous agbots and agents follow the edge machine owner policies to negotiate formal agreements to collaborate. Whenever the agbots and agents are in an agreement, they cooperate to manage the software lifecycles of the corresponding edge nodes:

Agent and agbot processes collaborate on the software management of all registered edge nodes. The agbots and agents use the exchange to find each other, establish trust, and communicate securely.


Policies are rules or constraints that provide much finer control over deployment placement of edge services by edge node owners, service code developers, and deployment owners. Policies are used to describe where a service can be run, if it requires a particular hardware setup (such as CPU/GPU constraints), memory constraints, specific sensors, actuators, or other peripheral devices. Policy is expressed through a flexible language that is applied to models, nodes, services, and deployments.

The policy engine runs in the agbot. During configurable timed intervals, the agbot searches for nodes that have a compatible policy. It also analyzes existing agreements to ensure that they remain compliant with defined policy parameters. An agreement is in compliance when the node, service, and deployment policies that originally created the agreement remain in effect. The agreement is still compliant when changes to one of those policies does not affect policy compatibility, and the policies remain compatible.

The following are the four types of policies available with IBM Edge Computing for Devices and which component monitors the policies.

  1. Node
    • Provided at registration by the node owner.
    • Nodes monitor changes to the node policy and reevaluate existing agreements when the node policy changes.
  2. Service
    • Can be applied to a published service in the exchange.
    • Agbot monitors service policy changes and reevaluates existing agreements only when those policies change.
  3. Deployment
    • Sometimes referred to as business policy, it defines the policy for how and where to deploy a given service.
    • Agbot monitors deployment policy changes and reevaluates existing agreements only when those policies change.
  4. Model
    • Used to deploy AI models to edge nodes.
    • This will be covered in another blog post dealing with model management.

Creating policies

To reiterate, policies provide more control over deploying services on edge nodes. Policies are coded as JSON files and typically contain properties and constraints. The JSON files are stored in the exchange and have their own lifecycle.

Let’s look at some sample policies.

Node policy

If we were to add a node policy to the HelloWorld app so that it runs only on a particular model of Raspberry Pi, the corresponding node_policy.json file contents would look something like what is shown below. It provides values for three properties (model, serial, and configuration). It has no constraints, so any appropriately signed and authorized code can be deployed on this edge node:

  "properties": [
    { "name": "model", "value": "Raspberry Pi 4" },
    { "name": "serial", "value": 9123456 },
    { "name": "configuration", "value": "Model B" }
  "constraints": [
Scroll to view full table

When the node is registered using the above file, the node policy becomes effective.

Service policy

We could also add a service policy to the HelloWorld app where the constraints can be used to restrict where this service can be run. The service developer could, for example, assert that this service requires a particular hardware setup, such as CPU/GPU constraints, memory constraints, specific sensors, actuators, or other peripheral devices.

A sample service policy JSON file would look something like what is shown below. It doesn’t have any properties but it does have a constraint:

  "properties": [
  "constraints": [
    "model == \"Raspberry Pi 3\" OR model == \"Raspberry Pi 4\""
Scroll to view full table

In the node policy used above, the model property was set to Raspberry Pi 4, so this service should be compatible with our edge node.

The service_policy.json file is added to the HelloWorld service, thus enforcing the constraint that it can only run on Raspberry Pi models 3 or 4.

Deployment policy

The deployment policy (or the business policy) is what ties together edge nodes, published services, and the policies defined for each. It also contains a set of properties and a set of constraints in a deployment_policy.json file. Additionally, it can explicitly identify the service it will cause to be deployed onto edge nodes if negotiation is successful.

An example of a deployment policy can be found here.

The link to instructions on how to deploy workloads to the edge with specific policies can be found in the references section.

The IBM Cloud architecture center offers up many hybrid and multicloud reference architectures. Look for the newly published edge computing reference architecture there.

We would like to know what you think.

Thanks to David Booz for reviewing the article and Glen Darling for providing his expert thoughts.

Learn more

For more information on edge computing, see the other installments in this series, as well as a few other resources:

More from Cloud

Clients can strengthen defenses for their data with IBM Storage Defender, now generally available

2 min read - We are excited to inform our clients and partners that IBM Storage Defender, part of our IBM Storage for Data Resilience portfolio, is now generally available. Enterprise clients worldwide continue to grapple with a threat landscape that is constantly evolving. Bad actors are moving faster than ever and are causing more lasting damage to data. According to an IBM report, cyberattacks like ransomware that used to take months to fully deploy can now take as little as four days. Cybercriminals…

2 min read

Integrating data center support: Lower costs and decrease downtime with your support strategy

3 min read - As organizations and their data centers embrace hybrid cloud deployments, they have a rapidly growing number of vendors and workloads in their IT environments. The proliferation of these vendors leads to numerous issues and challenges that overburden IT staff, impede clients’ core business innovations and development, and complicate the support and operation of these environments.  Couple that with the CIO’s priorities to improve IT environment availability, security and privacy posture, performance, and the TCO, and you now have a challenge…

3 min read

Using advanced scan settings in the IBM Cloud Security and Compliance Center

5 min read - Customers and users want the ability to schedule scans at the timing of their choice and receive alerts when issues arise, and we’re happy to make a few announcements in this area today: Scan frequency: Until recently, the IBM Cloud® Security and Compliance Center would scan resources every 24 hours, by default, on all of the attachments in an account. With this release, users can continue to run daily scans—which is the recommended option—but they also have the option for…

5 min read

Modernizing child support enforcement with IBM and AWS

7 min read - With 68% of child support enforcement (CSE) systems aging, most state agencies are currently modernizing them or preparing to modernize. More than 20% of families and children are supported by these systems, and with the current constituents of these systems becoming more consumer technology-centric, the use of antiquated technology systems is archaic and unsustainable. At this point, families expect state agencies to have a modern, efficient child support system. The following are some factors driving these states to pursue modernization:…

7 min read