How do DevOps and Edge computing interact?
Several people have pointed out, rightfully so, that edge computing blogs mainly deal with the operational side of things, such as device registration and operations, network management, etc.
This fourth blog in the series on edge computing touches on DevOps in an attempt to answer questions like the following:
- Is there any coding to be done when it comes to edge computing solutions?
- What do edge applications look like?
- Is there a programming model for edge applications?
If the distributed architecture of edge computing means running applications and services on those edge devices, there has to be a methodology to code, test, deploy, and run those apps.
For more background on edge computing, please see the following video:
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”
Non-functional requirements (NFRs)
The non-functional requirements (NFRs) for DevOps or DevSecOps are well known—continuous integration, continuous delivery, continuous testing, and continuous deployment, all in a secure framework.
There are a few nuances when it comes to developing and deploying edge applications and solutions—scaling, types of devices, application footprint, operating speed and disconnected.
While there is a need for providing a framework to securely deliver consistent and reliable software to the devices quickly, something unique to edge is the scaling factor. Imagine the second largest bank in the United States—which has 16,220 ATMs across the country—wanting to apply an update to its ATMs.
There are a plethora of edge devices. They come in different shapes, sizes, makes, and models from hundreds of manufacturers. Coding to the lowest common denominator makes things interesting. Some are audio devices, some are visual devices, while others have audio-visual capabilities. But the mantra developers have to keep in mind is “write once, deploy everywhere.”
Then, there is the size of edge applications. We have all heard of cloud-native development when dealing with the cloud. With edge, we are looking at edge-native applications, which tend to have a smaller footprint. And, more importantly, they have to operate at very high speeds, especially when it comes to inferencing at the edge. Note that there are hardware accelerators that significantly improve the performance of inference applications on the edge.
Finally, the edge, unlike the cloud, can be unstable and even disconnected by design. There can be many points of failure in an edge solution. “Keep it simple” is not a cliché, but a rule of edge-native applications since they have to be ready to scale back to the cloud at any point. Any and all data at the edge should be considered ephemeral.
Tools, toolchains, and frameworks
Providing tools and a framework for securely delivering consistent and reliable software as fast as possible to all connected devices will be key. The previous blog in this series, “Architecting at the Edge,” showed the IBM Edge Computing Reference Architecture:
In it, you will see that Linux and Docker containers are the most common technologies in vogue when it comes to edge-based applications, along with Kubernetes for container orchestration.
One could avail of any toolchain that deploys to Kubernetes or Docker (examples can be found here). A Git repository, an Eclipse or Web IDE, and a delivery pipeline with Jenkins and Terraform would be the main components in the toolchain.
There are two very distinct endpoints in an edge computing solution—edge servers and edge devices. We envision two toolchains. The first toolchain would be used to deploy the edge server infrastructure:
The second toolchain would have at least two pipelines that would be used to deploy applications to the edge servers (which are Kubernetes-based container platforms) and the other would deploy to edge devices based on ARM architecture (running Docker-based applications):
Edge applications
Let’s look at developing our first edge app—you guessed it, a Hello World service, running on a device like Raspberry Pi. One needs a Docker Hub ID and access to GitHub. The following are the high-level deployment steps:
- Set up IBM edge infrastructure
- Install Edge Exchange and Agreement Bot (agbot)
- Develop Edge application
- Build, test, push, and publish the service to the IBM Edge Exchange
- Deploy edge application
- Register edge node to run this pattern
- Install the agent on edge device and configure it to point to the Edge Exchange
- Device will make an agreement with one of the Edge Exchange agbots
- Run the pattern and observe the output
Given that the Hello World is a simple application, it would only be deployed to the edge devices. If it were an artificial intelligence (AI) application, the full-blown version of it would be deployed on the edge server while a leaner version would get deployed on the Edge devices.
The code for the simple Hello World service is shown below. It outputs a line that says “Hello World” every three seconds:
The detailed steps and code for the HelloWorld service can be found on GitHub.
The link to instructions on how to deploy workloads to the edge can be found in the references section.
Edge 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 restrict where a service can be run, requiring a particular hardware setup such as CPU/GPU constraints, memory constraints, specific sensors, actuators, or other peripheral devices.
With the Exchange created, the Service coded, the Node registered, and Policies specified, the device—in this case the Raspberry Pi—should be continuously transmitting the Hello World message as shown below:
The IBM Cloud architecture center offers up many hybrid cloud and multicloud reference architectures, including the newly published edge computing reference architecture.
For more information on edge computing, the other parts of this series and a few other important references:
- 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”
- Emerging Innovation Spaces dimension
- Cloud adoption
- Horizon Hello World Example Edge Service
- 7 Rules for Edge-Native Applications
- DevOps is Essential for Your Journey to Edge Computing: A Case for Mobile and 5G
Thanks to David Booz and Steven Cotugno for reviewing the article.
Was this article helpful?
YesNo