A question I get asked, with increasing frequency is “how much will it cost to compute at the edge?”. The answer is not that straight forward, and with a typical engineering perspective I often reply with “it depends”. “It depends”, because the edge is not simply a smaller version of the public cloud or central cloud where the resources of the public cloud are for all intents and purposes considered infinite. Of course, they are not infinite, but an application developer doesn’t really concern themselves with the finite limitations of public cloud resources, they state their base level requirements on the infrastructure, and how far they are prepared to scale-up based on the on-demand requirements of their application.
So why is the edge not simply a smaller version of the public cloud?, Well I tend to see edge resources as not being infinite, I think of them as a premium resource, and when we consider the service provider edge, those resources are highly distributed and typically hierarchical in nature depending on the network topology.
We might consider, that as compute environments are placed at various points between (and including) public centralised clouds, and the deep edge of service provider networks, the developer community, and application providers will make decisions about where specifically they need portions of their solution to be executed to reap the most benefit.
I’m not suggesting that they (application developers) will suddenly place all workloads at the edge, that doesn’t seem like a good use in my mind; having huge big-data analytics processes running at the deep edge wouldn’t provide any tangible benefit. However, if an application requires a low latency transaction, some element of security, or even sovereignty, locality or personalisation, network integration, or an increase in “performance” then placing those workloads at the edge will make a lot of “engineering” sense. But how do we consider the cost to compute at the edge if it is indeed a premium resource or location?
Imagine cloud computing is the hotel industry. The public or centralised clouds always have room, you can book yourself in and out, and if your requirements change you can be accommodated without issue, if you decide to have more guests stay, that’s no problem, if you decide to throw a party, don’t worry about it, stay as long as you want, you will just be billed at the end of the month. The edge might be thought of as a little more boutique in nature, sure they have many desirable locations, but the rooms are more limited in supply and they typically cater for more specific requirements and shorter stays, and at busy periods may cost slightly more to attract only those guests that truly require that level of service on offer.
Ok, sorry about the hotel analogy. But my point is that I can imagine a scenario where the cost to compute at the edge is dynamic in nature, any workloads placed at the edge will carry a weighting based on their target performance requirements (latency, security, sovereignty, locality, personalisation, network integration and so on) and those workloads will be dynamically distributed across the hierarchy of edge compute nodes. To aid in this “multiplexing” of workloads, the deeper edge will favour less persistent software functions and processes, leaving those that require a more prolonged existence to more central locations.
But what about the cost to compute? I see the cost of compute becoming a little bit like the Uber surge pricing, yes I am aware I jumped from hotel to taxi analogies, but please bear with me. One way to balance the need to execute workloads at the edge with performance weightings will be surge type pricing. If an application truly needs to have functions executed somewhere across edge points of presence, then the cost-to-compute will play a large factor in how load balancing multiple independent application functions at across those locations will work and be costed.
For more information on edge computing and the challenges or infrastructure decisions reach out to the EDGE GRAVITY team at email@example.com.