The edge of a network, as you may know, is the furthest extent of its reach. A cloud platform is a kind of network overlay that makes multiple network locations part of a single network domain. It should therefore stand to reason that an edge cloud is a single addressable, logical network at the furthest extent of a physical network. And an edge cloud on a global scale should be a way to make multiple, remote data centers accessible as a single pool of resources -- of processors, storage, and bandwidth.
The keyword in the above paragraph is "should." Many IT producers stand to benefit from the type of technology from which an edge cloud is built. Theoretically, every user of distributed applications should stand to gain from such a concept coming to fruition. But the world, as evidenced by the recent pandemic, is huge, and perhaps in the social sense, growing larger. The edge of a network run by the operators of hyperscale data centers would, it would seem, be nearer to their customers. The edge of a telecommunications network, you might think, would be at or near their most distant transmitters and base stations. And the edge of a network of colocation facilities might be in small buildings, remote campuses, and even a few closets and basements.
At least that's what you'd think. But none of these locations necessarily intersect with one another. And these locations are not necessarily where it makes the most sense, from a business perspective, to stand up a cluster of servers. So, as it turns out, an edge cloud may turn out to be the set of all locations distributed away from its operator's core, which may be collectively addressable from the same virtual network.
"Edge doesn't exist unto its own," explained Matt Baker, senior vice president of strategy and planning at Dell Technologies, during a press conference earlier this year. "Edge is a part of broader environment: Edge to core to cloud."
The edge cloud your organization may end up using, therefore, may depend on a number of variable factors:
The typical networked application has a single address point that is accessible through one location. In the public cloud, that location may shift, and it may even be transferred across availability zones, but there's still a central server. Distributed applications have functions that may reside in many places in a network, including in domains nearer to databases or customers.
The dream of IT engineers and architects -- or, where that dream is closer to reality, their objective -- is to distribute the functions that collectively comprise applications, in those "edge" locations where latency may be reduced for the benefit of users or of servers (often one or the other, since they're on different ends of the distribution chain). Originally, the edge cloud concept was a means to this end: a way to choose the point on a map where functions make the most sense to be deployed, strategically speaking, and place them there.
One of the first references to an edge cloud appeared in 2014, as a submission by Nokia Bell Labs to an IEEE communications conference. An edge node, the paper explained, would be a point-of-presence (PoP) offering direct access to compute and storage resources at the edge of the network. The collection of all edge nodes would be an edge zone, and what would make these nodes interoperable would be some kind of network namespace federation with the core data center.
Given that setup, Bell Labs envisioned things would go this way:
The Edge Cloud is the federation of the data center nodes along with all the edge zones. The Edge Cloud operator is assumed to have a pre-existing, traditional IaaS data center cloud. By adding Edge Cloud functionality, the Edge Cloud operator can now extend the cloud's capabilities to deploy applications at the edge networks.
But "applications" in the telecommunications sense doesn't mean SAP, Oracle, or Microsoft Exchange. They are generally network functions, the virtual form of which (VNF) populates telco data centers today. Already, telco network schedulers distribute VNFs to where they need to be. The advantages of distributing these services to a broader number of disparate locations is, at least for now, theoretical -- and among at least some telco network engineers, questionable.
There's not just one answer to the question of the definition of "edge cloud," like the correct answer to a multiple-choice question on a quiz. Each definition spells out a unique and important concept in the world's computing infrastructure. It's just that, in the typically non-concerted efforts by stakeholders to establish a new and lucrative market, they will end up applying the same, catchy name to their own respective business models.
"Driven by a need to get data and applications closer to the user," reads one definition posted on the corporate Web site of communications infrastructure provider Ciena, "the edge cloud will be composed of orders of magnitude more data centers, scaled-down and a short distance from end-users."
The common element in all definitions of edge cloud, including those printed below, is the acknowledged need among the administrators of applications to specify where on a map (not the network map, but the planetary one) they are deployed. Rather than a typical public cloud, where availability zones (e.g., western US, eastern US, Australia) give you about as much locality as you're going to get, an enterprise may prefer an option where the distances between the workloads and the places where they are put to use, are minimized.
1. As a virtual infrastructure platform, one kind of edge cloud enables a software workload to become deployable among a variety of strategic locales, one of which may offer minimum latency with respect to how it's used, and who is using it.
2. As a physical infrastructure platform, to which ZDNet first introduced you in June, an edge cloud may be a collection of geographically dispersed data centers that are interconnected in such a way that they may be perceived at one level of the network as a single domain.
3. A completely separate class of physical infrastructure platform -- in this case, smaller facilities operated by public cloud providers such as Amazon AWS -- locates smaller quantities of cloud-connected servers (much smaller than the providers' own hyperscale facilities) in greater numbers of locations, interconnected using telecommunications companies' fiber-optic lines -- for instance, Verizon's. This concept of edge cloud offers users a way to implement existing public cloud services in strategic locations.
4. In the telecommunications industry, there is an emerging concept of a central office distributing its network functions and customer applications to remote locations without altering their functionality, enabling a distribution of resources to more rural and remote areas. China Telecom, among others, calls this concept its edge cloud. One vendor, Juniper Networks, has adopted this concept as a genuine product, called Contrail Edge Cloud. The GSMA public/private telecom industry cooperative pictures this concept [shown above] as an "operators' cloud." The US Federal Communications Commission appears to have adopted this concept as the official version of edge cloud for government purposes [PDF]. (Although some have said the 3GPP organization's Multi-Access Edge Computing, or MEC, is its own edge cloud, 3GPP chooses not to refer to it as such.)
5. Another permutation of an edge cloud model is entirely private, even going so far as to re-architect fully-cooled, self-contained servers as edge cloud appliances, so they can be more easily installed on-premises. One example of a company building such appliances is Hivecell. The "cloud" aspect of this architecture comes from the company's business model: Effectively selling the use of these appliances, rather than the appliances themselves, as "platform-as-a-service" (PaaS).
"The term 'edge' is relative," explained Wen Temitim, the CTO of edge cloud infrastructure platform maker StackPath at the time of this interview, now VP of Technology and Edge Architectures at StackPath's partner company, Juniper Networks.
"If you're hyper-focused on your enterprise data center use case, it may be more towards a data center provider," Temitim continued. "If you're hyper-focused on end-user experience, then you're thinking more about mobile operators and wireline providers."
Today, your public cloud-based services and applications are sourced in hyperscale data centers. And your streaming multimedia is sourced from a different set of data center facilities, but still, one that is highly connected using fiber optic cable. By "hyperscale" in this context, we mean a large building whose architecture makes it possible for its tenants to deploy greater amounts of compute, storage, memory, bandwidth, and electrical power very rapidly (usually a matter of days) in measured, planned increments. Amazon Web Services (AWS) can scale up capacity in any of its facilities quite rapidly.
An edge data center (for example, a micro data center or µDC) is a different beast -- a velociraptor, if you will, to hyperscale's tyrannosaurus. It's smaller, nimbler, and capable of being deployed in a wider variety of locations, especially including the metropolitan areas of medium- and even small-sized towns. It could bring computing capacity closer to the users of data center resources, minimizing latency, and improving service quality. Or, it could bring that capacity closer to telecommunications and Internet service providers eager to compete with the Amazons and Azures of the world, presumably with their own quality-of-service value proposition.
But these smaller facilities can't just be parachuted into place from the sky. They still need connectivity and power -- not the same electrical plug that powers your electric lawnmower, but three-phase power, which is more adaptable and more stable in variable climates and operating conditions.
"As companies are moving to virtualization, not just in virtualization but in the network layer as well," explained Cole Crawford, CEO of edge system provider Vapor IO, in a recent interview, "where you put a virtual network function [VNF], where you terminate an ASN [Autonomous System Number route] to expose an SD-WAN capability back to some location. . . you have to think at the edge about things you can take for granted in a Tier-3 facility. The edge is not always as fault-tolerant as a big Tier-3 facility.
"So if you're on single-phase power, if you're on only an N+1-capable [having a backup power source] physical data center platform, then all of a sudden, the things that an OpenStack or a Tanzu or an OpenShift, or anything that can be queried from a telemetry standpoint, now needs to include what we call an OT cloud -- an operational technology capability. Here, the orchestrator that is used to carving up CPU, memory, disk, and network, is now thinking about, 'What's the SLA? Am I running on UPS power? On generator power? On primary power? What latency profiles exist for me?'"
Here's what Crawford essentially said, translated into something more resembling a common language: There are conveniences associated with having every part of your computing infrastructure in one building. You can deploy necessary functions of the network, such as VNFs, in almost any convenient server you can provision, or you can enable a scheduler such as OpenStack (or, in the case of CNFs, an orchestrator such as Kubernetes, of which OpenShift is Red Hat's commercial incarnation), to do this for you.
Once you decouple everything and distribute the parts across multiple, interconnected, facilities, the logistics issue that was previously solved by centralizing everything around a single building, becomes an actual problem that has to be solved. Crawford believes (and admittedly may, to some degree, be counting on) this decentralization is inevitable. But these parts can't be made cohesive again without the introduction of a new element, to replace the convenience of centralization. This is the OT cloud, a platform of hubs that make this distributed network as functional as a hyperscale cloud.
Here, at last, is the open question: Who runs the OT cloud? The answer could determine, in the near term, who sends the customer the bill. In the long term, Crawford believes, it could remodel the Internet as a whole.
"That, I believe, is the panacea of what we're ultimately trying to build as an industry," he stated. "At some point -- and I don't know when that is, I feel like it's sooner than later -- we're going to stop being able to mechanically-turk the internet, which we do today."
One edge cloud deployment option -- which has been around for surprisingly longer than most folks realize -- comes from owners and operators of existing, smaller data center facilities. Since 2009, Herndon, Virginia-based EdgeConneX has been building a global network of what it calls "hyper-local data centers" -- facilities that are interconnected with public cloud providers via private, fiber optic connections. It was founded with funding from cable TV providers Comcast and Charter Communications, to provide cloud DVR storage capacities closer to their viewers.
"Round-about 2015, just as we brought content closer to the consumer," remarked EdgeConneX CEO Randy Brouckman in a recent interview, "the cloud providers certainly recognized they needed to get the cloud closer to the enterprise, if they were to get the 'cloud edge' deployed. Working with the world's biggest hyperscalers opened up the opportunity for EdgeConneX to bring our data centers closer to where our customers needed -- technically, where our customers' customers need them. This concept of location-sensitive data centers is critical, whether you're building out big core nodes near the edges of their clouds, or 'edge-edge' nodes, as we might think about them. We were able to demonstrate that the core architecture and design of data centers could scale up from 2 – 10 megawatts to many tens of megawatts."
Brouckman added that CSPs and enterprise data center customers have three common needs: lower latency, higher performance, and decreased cost. Theoretically, engineering for the latter group may not be all that different from engineering for the former one, especially since both may be equally invested in applications classes such as industrial IoT, 5G, AI/ML, and cloud gaming.
There are at least a handful of architectures for constructing a network of what Brouckman calls "location-sensitive data centers." These will be facilities that are closer to customers, closer to data, closer to interconnectivity routes -- closer to something, and for a good reason. At the moment, exactly what that reason will be, is a jump ball.