The second application challenge for distributed edge clouds

I spend my days thinking about the value edge-applications can bring to my users and business, but I had not given any thought about the implications of not having a platform for them. But now it strikes me as important.

This is a made-up quote synthesised from several C-level conversations we had over the last couple of months. It captures the gist of their view on how to take on edge application strategy and priorities.

Many enterprises already have applications running on the edge. The traditional IoT-flavored scenario is simply some computer program running on vendor specific hardware. Enterprises starting just now think either in terms of cloud-out, i.e. moving applications to edge locations or edge-in deploying applications in edge locations, and integrate them with services running in private or public clouds.

But the understanding that the edge brings value to enterprises is pervasive. Done.

Now then, is the time to take a step back and look at one of challenges we see as enterprises execute on their edge strategy. We call it the second edge application challenge.

The second edge application challenge

Top of mind for all software-driven enterprises is the speed of innovation. And this means the expectation of being able to move at the speed of software across all platforms that contribute to the success of the company. Including at the distributed edge.

On one hand, there is value in quickly launching a self-contained first application to prove the value of edge-placed applications to internal stakeholders and create early operational experiences.

But there is also great risk in not considering the operational situation down the line where each edge location will host a multitude of applications. The worst-case scenario includes getting stuck with many operational stove-pipes, one per application, and the significant cost and operations overhead associated with that.

We call this over-rotation on quickly deploying a first application, and ignoring the ramifications on the second (and beyond) application the second application challenge.

It leads to some interesting effects both on how edge application vendors behave, but also a set of follow-on effect for the application operations teams.

The application vendor challenge

The industry is still in a phase where the first-application position is dominant. One side effect of this is that many edge-application vendors today ship their own software stack to deploy, update and monitor their applications. I.e. they ship significant infrastructure along with their applications.

This leads to a situation where the vendors over time will:

• Only develop the bare minimum in terms of infrastructure and operations features. Since it is hygiene and not core to their value proposition (which is in the application themselves). They will tend to meet, but not necessarily exceed the expectations of the market.
• Focus on building infrastructure and operations features that are specific to their own application. There is no incentive for them to make the infrastructure components general enough to be able to host and operate third party applications. And in the worst case risk being held accountable for feature interaction with applications they themselves do not own.

The follow-on operational challenge

Trying to build application operations processes on top of the type of vertically integrated vendor solutions we covered about in the previous section is challenging. The main problem is that it will create a separate set of operational domains each with it’s own approach to deployment, monitoring, observability and security.

This leads to a situation where the application teams over time must:

• Endure the fact that the infrastructure brings a bare minimum of operational features which will not meet best practices at any point in time. This means they will not be able to evolve their ability to efficiently operate these applications.
• Come to terms with the fact that each vendor will bring their own infrastructure and that they will have significant overlap and create operational stovepipes per application. No reuse means they will eventually need to spend resources on recreating an operational view across all these platforms based on the set of least-common features.

Addressing the second edge application challenge

We can avoid the significant costs associated with the second application challenge by thinking of the edge as a distributed platform as a service (PaaS) for multiple applications both in-house developed as well as commercial third-party applications. This is in contrast with thinking about the edge as a set of separate applications running in their own.

Traditionally, edge environments has required very specific and vertically integrated tooling. Application teams that are used to working in public cloud, may find the whole idea of taking on deploying to distributed edge clouds downright scary and uncomfortable.