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:
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.
Node
Provided at registration by the node owner.
Nodes monitor changes to the node policy and reevaluate existing agreements when the node policy changes.
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.
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.
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.