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

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:

More from Cloud

Get ready for change with IBM Cloud Training

2 min read - As generative AI creates new opportunities and transforms cloud operations, it is crucial to learn how to maximize the value of these tools. A recent report from the IBM Institute for Business Value found that 68% of hybrid cloud users already have a formal, organization-wide policy or approach for the use of generative AI. That same report also noted that 58% of global decision makers say that cloud skills remain a considerable challenge. Being proactive in your learning can significantly…

Data center consolidation: Strategy and best practices

7 min read - The modern pace of data creation is staggering. The average organization produces data constantly—perhaps even continuously—and soon it’s investing in servers to provide ample storage for that information. In time, and probably sooner than expected, the organization accrues more data and outgrows that server, so it invests in multiple servers. Or that company could tie into a data center, which is built to accommodate even larger warehouses of information. But the creation of new data never slows for long. And…

Hybrid cloud examples, applications and use cases

7 min read - To keep pace with the dynamic environment of digitally-driven business, organizations continue to embrace hybrid cloud, which combines and unifies public cloud, private cloud and on-premises infrastructure, while providing orchestration, management and application portability across all three. According to the IBM Transformation Index: State of Cloud, a 2022 survey commissioned by IBM and conducted by an independent research firm, more than 77% of business and IT professionals say they have adopted a hybrid cloud approach. By creating an agile, flexible and…

Tokens and login sessions in IBM Cloud

9 min read - IBM Cloud authentication and authorization relies on the industry-standard protocol OAuth 2.0. You can read more about OAuth 2.0 in RFC 6749—The OAuth 2.0 Authorization Framework. Like most adopters of OAuth 2.0, IBM has also extended some of OAuth 2.0 functionality to meet the requirements of IBM Cloud and its customers. Access and refresh tokens As specified in RFC 6749, applications are getting an access token to represent the identity that has been authenticated and its permissions. Additionally, in IBM…

IBM Newsletters

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