Five things to consider during an edge computing pilot

Before embarking on the edge pilot, your organization must clearly define why you are doing this. What are the business goals of moving workloads to the edge? Skunk projects can help validate technical components, but edge technology impacts the organization’s digital business. Therefore you need a…

✅ …clear definition and communication of why we are moving workloads to the edge before starting the pilot.

If not, there is a risk the whole pilot might become a waste. The pilot should be the stepping stone to the next phase in the overall edge strategy. Also, this is a prerequisite for setting goals for the pilot.

Consideration 1: What is your edge environment?

Make sure that you paint the picture for a target edge site landscape: what are the ideal number of edge sites, connectivity characteristics, compute infrastructure at the edges? This will set up the constraints that your pilot must be validated against.

Also, build your first candidate list of applications that shall run at the edge. This can be a chicken or egg activity since it might depend on platforms and edge infrastructure. But start from a top-down business requirements perspective. Which applications would benefit your organisation by running at the edge?

Consideration 2: Setup relevant goals

A pilot needs a goal: what shall be proven?

⛔ Pitfall: prove that you can make a single cluster run on a few resource-constrained hosts

💡 Valuable: pilot for benefits, characteristics and challenges specific for your edge environment (see above)

A common mistake for edge POCs is to technically prove that you can run your cloud workload platform on resource constrained hosts. Popular Youtube videos shows how to run Kubernetes on RPIs. This is a highly irrelevant activity since you are missing to validate the critical points with edge.

The most common reason that edge computing POCs tend to fail in production is the inability to efficiently scale (in terms of number of nodes and number of locations).

Source: Gartner: Building an Edge Computing Strategy, Thomas Bittman, ID G00753920

A pilot should attempt to evaluate how a project will operate and how it can be monitored and managed at full scale and meet goals and requirements. Of course the pilot will likely not be able to run in full scale but you have to find way to simulate or calculate KPIs for the target environment.

It is good to set up a number of measurable KPIs like:

• We shall be able to deploy an application to targeted edge sites directly from our pipeline
• A version update of our application X across the 300 national sites shall be done within X minutes.
• Upgrading the site clusters shall be a fully automated process without manual steps
• Upgrading the edge host OS shall not impact applications on the site

Consideration 3: Use-case driven or platform-driven?

When you know the overall goals for the pilot as well as an outline of the edge environment and candidate applications, it can normally become tricky to pick the strategy for the pilot. Shall we strive for a platform-driven or use-case driven pilot?

• Platform-driven: In this approach you focus on general features to deploy applications at the edge. You know that you have many different applications but they are fairly similar in behaviour and requirements. With one generic application you can prove that the edge pilot will work in the general case for all applications.
• Use-case driven: in this scenario you know that you have a few challenging use cases that you need to prove end to end. It might be strict latency requirements, heavy data and compute load at the edge or similar. Here you need to put weight into making these applications running in a realistic environment to prove the case.

Consideration 4: Consider the complete stack and associated lifecycles

The value of edge computing is nothing without real applications running at the edges. It is a common pitfall in edge pilots not to consider the complete stack and the implications on the goals. This also connects back to Consideration 1: what are the goals that you want to prove?

The illustration below outlines various candidate layers in the stack that needs consideration:

Walking the stack from the bottom:

At the edge you have a stack from the local site infrastructure all the way up to your running edge applications. Not to forget the hosts and associated OS. In order for the edge applications to run on the sites you have picked a cluster manager for the sites. And your analysis of the application needs also identified a couple of edge services like data management and security for example.

In the central part of your solution you need to manage all the clusters at all sites. The edge site services also need a central counterpart, for example data analytics. And, finally the value for your organisation, managing the application lifecycle from a central solution.

The central and edge layers have dependencies. Lifecycle events at one layer might have an impact on other layers. Also many scenarios must study requirements end to end from central application deployment all the way to the containers running on hosts.

Add to this important lifecycle events like the below flowing through all layers

• Application deployment across sites
• Application monitoring and troubleshooting
• Site maintenance like site rollout, OS upgrades and adding/removing hosts
• Cluster updates
• Network outages

With the above as a backdrop you could simulate or implement a couple of the scenarios and make sure your pilot proves the goals across the complete stack and relevant lifecycle events. While this might seem daunting for a pilot, you have not really proved a working solution until you have covered slices of the above full picture.

Consideration 5: Wrapping up the pilot

As always when running pilots, the evaluation must not be forgotten. Uplift your learnings to a summary around the most important topics. Share it with your stakeholders. Example topics can be:

• Goals and KPIs: Have we proven the goals that the business units want to achieve? Any major challenges
• Technology recommendations: give recommendations for components in the full stack outlined above
• Recommendations and next steps: give a clear recommendation on how to continue the move towards running applications at the edge.

☕ And you can have your coffee when you have shown that you can manage the edge scale, and the full stack all the way up to the applications