January 22, 2020 By Ashok Iyengar 6 min read

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": [

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\""

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:

Was this article helpful?

More from Cloud

Enhance your data security posture with a no-code approach to application-level encryption

4 min read - Data is the lifeblood of every organization. As your organization’s data footprint expands across the clouds and between your own business lines to drive value, it is essential to secure data at all stages of the cloud adoption and throughout the data lifecycle. While there are different mechanisms available to encrypt data throughout its lifecycle (in transit, at rest and in use), application-level encryption (ALE) provides an additional layer of protection by encrypting data at its source. ALE can enhance…

Attention new clients: exciting financial incentives for VMware Cloud Foundation on IBM Cloud

4 min read - New client specials: Get up to 50% off when you commit to a 1- or 3-year term contract on new VCF-as-a-Service offerings, plus an additional value of up to USD 200K in credits through 30 June 2025 when you migrate your VMware workloads to IBM Cloud®.1 Low starting prices: On-demand VCF-as-a-Service deployments begin under USD 200 per month.2 The IBM Cloud benefit: See the potential for a 201%3 return on investment (ROI) over 3 years with reduced downtime, cost and…

The history of the central processing unit (CPU)

10 min read - The central processing unit (CPU) is the computer’s brain. It handles the assignment and processing of tasks, in addition to functions that make a computer run. There’s no way to overstate the importance of the CPU to computing. Virtually all computer systems contain, at the least, some type of basic CPU. Regardless of whether they’re used in personal computers (PCs), laptops, tablets, smartphones or even in supercomputers whose output is so strong it must be measured in floating-point operations per…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters