What is an “edge” and what is a “cloud”? Those questions might have seemed surpassingly dumb even a year ago, but today we’re seeing growing confusion on the topic of future computing and the reason comes down to this pair of questions. As usual, there’s a fair measure of hype involved in the debate, but there are also important, substantive, issues to address. In fact, the details that underpin this question might decide the balance of power in future computing.
The popular definition of “cloud computing” is utility computing services that offer virtual hosting on a public or private data center. In practice, though not as a real requirement, cloud data centers for public providers tend to be in a small number of central locations. To put this in an easier vernacular, cloud computing resources are virtual, a kind of hosting-capability black box. You don’t know, or care, where they are unless your cloud service includes specific regional/location affinities.
“Edge” computing is actually a less concrete concept, because it begs the obvious question “Edge of what?” Again, we have to fall back on popular usage and say that edge computing is computing at the edge of the network, proximate to the point of user connection. Cisco uses the term “fog computing” to be roughly synonymous with “edge computing”, but in my view, there could be a difference. I think that the “fog” notion implies that edge resources are both distributed and logically collectivized, creating a kind of edge-hosted cloud. In contrast, I think that some “edge computing” might rely on discrete resources deployed at the edge, not collected into any sort of pool. Whether you like either term or my interpretation, I’m going to use this definition set here!
The question of whether a given “cloud” should be a “fog” is probably the most relevant of the questions that could arise out of our definitions. Resource pools are more economical than fixed resources because you share them, just as packet trunks are more economical than TDM trunks. The concept of resource-sharing is based on the principle of resource equivalence. If you have a bunch of hosts, any of which will do, one can be selected to optimize operations and capital costs. Greater efficiency, in other words, and efficiency grows with the size of the pool. If your resources are different in a way that relates to how they might be used, then you might not have the full complement of resources available to suit a given need. That means a smaller pool, and lower efficiency.
This is why we’ve tended to see cloud providers build a small number of massive data centers. That breeds lower cost (and greater profit) but it also creates a problem with transit time. An event or transaction that enters the network at a random point might be transported thousands of miles to reach processing resources. That distance might include multiple nodes and trunks, introducing handling delays. In the end, we could be talking tenths of a second in delay.
That might not sound like much, but if we presume that we have a 0.2 second round-trip delay and we’re controlling something like a turnstile, a vehicle at 60 mph would travel about 18 feet in that amount of time. The point is that for applications like process control, a transit delay can be a true killer, and if we could have moved our processing resource to the network edge, we could significantly reduce that delay.
The Internet of Things, to the extent and at the pace that it becomes relevant, is the logical on-ramp for applications sensitive to transit delay. That means that centralized cloud data centers become problematic with higher rates of IoT adoption, and that the trend would likely encourage the migrating of hosting of IoT processes to the edge. That’s the trend that actually divides the broader term “edge” computing from what I think is Cisco’s “fog” value proposition.
Cloud providers like Amazon support IoT event processing already, through their functional/serverless or “Lambda” offering. Obviously, Amazon isn’t about to push out thousands of data centers to the network edge in a field-of-dreams hope of attracting IoT opportunities. Instead, what they’ve proposed to do is allow their event processing to migrate out of the network and onto customer premises, using customer-provided resources and Amazon software, called “Greengrass”. Edge computing, provided by the customer, is used to extend the cloud, but in a specific, facility-linked, way. You can’t think of this kind of edge hosting as a general “fog” because the elements that are distributed are tasked with serving only the general location where they’re found. You could just as easily say they were remote servers. If you remember the notion of “server consolidation” in the cloud, think of Greengrass as “server un-consolidation”. The cloud comes to you, and lives within you.
IoT promotes edge computing, but it doesn’t limit the source of the compute power or whether or not it is collected into the “fog/cloud”. We need to have at least some event processing collected in proximity to the event source, and from there the “inward” requirements won’t be much different from those of traditional transaction processing. Enterprises could do on-prem event processing or cede it to the cloud provider.
The “some event processing” point may be critical here. Event processing isn’t a simple, single-point, task, it’s a series of interlocking processes, primary and secondary events, correlations, and distributions. Eventually it could feed back to traditional transaction processing, and even reshape much of that, and the IT elements that support it, along the way. We have “shallow” events, primary events, close to the surface or edge, and “deep” events that could reside in the traditional more centralized cloud, or the data center. Wherever we have the events, they’re a part of that interlocking process set, and so somebody who wins in one place might well, lacking competition, win in them all.
The cloud providers clearly know this, and they’ve taken the lead in defining event-driven compute models. Nearly fifty enterprises have told me that all three major cloud providers are further along in their thinking on event processing than their software vendors are, and nearly all say the cloud providers are further along than the enterprises themselves. However, the former assertion isn’t true. Vendors are prepared to offer the enterprise just as enlightened an event architecture as the cloud providers could. They’re just not doing the job, either because they fear lengthening their sales cycle or because the sales organization doesn’t understand event processing.
This is the source of the cloud/edge/fog battles we’ll see fought this year. If public cloud providers can offer a strong architecture for “deep events” then they can use the Greengrass strategy, or in the case of Microsoft simply support Windows Server local hosting, to make the edge an extension of the cloud and support “shallow events”. They can then extend their own hosting closer to the edge over time, confident they have grabbed control of event processing.
If they don’t, then eventually the right architecture for both deep and shallow events will be created by software professionals building middleware tools, and this could be used to build a data-center-driven event processing model that wouldn’t use the cloud any more than current transactional or web/mobile applications would. The event cloud could be cut off at the knees.
So far, things are on the side of the cloud providers. As I noted earlier, enterprises aren’t hearing much about event processing from their software vendors, only from their cloud resources. As we evolve toward event-driven computing, with or without the aid of IoT, we can expect it to become the singular focus of technical modernization of IT infrastructure. That’s a very important win…for somebody.