Introducing The Programmable Edge

Consider an airplane that generates terabytes of collective data while it is enroute. Once the plane lands, it can take hours to ship the terabytes of data to the core application environment thousands of miles away to figure out if the plane is fit to fly again today. Or the data can be pushed to a nearby environment that can ingest the data, process it and generate results within minutes so the plane can be on its way within the hour. But consider that if an airline has flights servicing 50 airports, the company would need to maintain 50 highly available data centers. That’s a serious burden! Wouldn’t it be better if the data processing workloads could run closer to each airport, without the company’s operations team having to build out so many application environments?

Another example is a group of friends that is playing a multiplayer, first person shooter game from their respective homes. All of them live within 50 miles of each other. To make the end user experience better, the gaming platform somehow has to publish each player’s moves to every other player (along with the moves of each of the adversaries) as quickly as possible. It would be incredibly hard to get each endpoint to talk to every other endpoint to share information in a peer-to-peer fashion because of the number of connections that would need to be securely maintained in the user mesh. If the rendezvous point for all this interaction is hundreds of miles away from the players in the core application environment, the end user experience will be impacted because data will first need to be pulled from each end user’s environment into the core, and will then be published to all the other end users.

It would clearly be better for the rendezvous point to be closer to the user group playing the game. But if the gaming platform wants to provide a superior experience to tens of thousands of users all over the world, it would need to deploy application stacks in a large number of locations, leading to potentially cost prohibitive operational costs. The problem will only be exacerbated with AR/VR type features being added to gaming platforms because more data will then need to be shuttled around, faster. Wouldn’t it be better for the rendezvous point to be automatically selected based on the user group’s relative geolocation without the gaming platform having to invest in application platforms in a large number of locations?

These two examples represent a growing trend: Rich, interactive applications are fused with workloads that are ill-suited to be executed on the two types of real estate (the “core” and the “endpoint”) that developers have access to today.

This is why the industry needs a new platform – a third type of real estate – that we are calling Programmable Edge. This platform must exist closer to endpoints and devices, and must be programmable to the point that application owners can run bespoke logic near endpoints. And they should be able to do so without needing to solve for a swath of critical application infrastructure requirements.

If you would like to learn more, or have long believed the industry needs a Programmable Edge, we’d love to talk to you (Web | Twitter | LinkedIn). It’s going to be a great ride, and we are always looking for early adopters and engineering super stars to partner with us to deliver on the promise.