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:

• Part 1: “Cloud at the edge”
• Part 2: “Rounding out the edges”
• Part 3: “Architecting at the edge”
• Part 4: “DevOps at the edge”
• Part 5: “Policies at the edge”
• Part 6: “Models Deployed at the edge”
• Part 7: “Security at the edge”
• Part 8: “Analytics at the edge”
• Part 9: “5G at the edge”
• Part 10: “Clusters at the edge”
• Part 11: “Automation at the edge”
• Part 12: “Network slicing at the edge”
• Part 13: “Data at the edge”
• Part 14: “Architectural decisions at the edge”
• Part 15: “GitOps at the edge”
• Part 17: “Storage services at the edge”
• Part 18: “Cloud services at the edge”
• Part 19: “Distributed cloud: Empowerment at the edge”
• Part 20: “Data sovereignty at the edge”
• Part 21: “Solutioning at the edge”
• Part 22: “Connected products at the edge”
• Part 23: “Foundational models at the edge”

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:

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

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:

• Part 1: “Cloud at the edge”
• Part 2: “Rounding out the edges”
• Part 3: “Architecting at the edge”
• Part 4: “DevOps at the edge”
• Part 5: “Policies at the edge”
• Part 6: “Models Deployed at the edge”
• Part 7: “Security at the edge”
• Part 8: “Analytics at the edge”
• Part 9: “5G at the edge”
• Part 10: “Clusters at the edge”
• Part 11: “Automation at the edge”
• Part 12: “Network slicing at the edge”
• Part 13: “Data at the edge”
• Part 14: “Architectural decisions at the edge”
• Part 15: “GitOps at the edge”
• Part 17: “Storage services at the edge”
• Part 18: “Cloud services at the edge”
• Part 19: “Distributed cloud: Empowerment at the edge”
• Part 20: “Data sovereignty at the edge”
• Part 21: “Solutioning at the edge”
• Part 22: “Connected products at the edge”
• Part 23: “Foundational models at the edge”
• IBM Cloud Adoption and Transformation
• Horizon Hello World Example Edge Service
• What is Edge Computing?
• IBM Edge Computing Reference Architecture
• Emerging Innovation Spaces dimension