Why the Cloud Needs an Edge, and Vice-Versa

Some years ago I stumbled across an article with the colorful (and arguably mixed metaphorical) title, “The Edge Will Eat the Cloud.” This title implies cloud and edge computing are competing models with edge computing being the superior of the two.

Indeed, it’s tempting to think that edge computing is the same as cloud computing but in many more locations. In reality, cloud and edge computing are fundamentally different-yet-complementary models that address distinct use cases. Not only do they need each other, they need to be connected to each other.

Beyond the difference in site density and distribution, cloud and edge computing differ profoundly in the way the computation is located. Cloud computing is “location bound”, whereas edge computing is “unbound” and “ubiquitous”. To keep the modern applications you and I use everyday up and running, it’s necessary to have the cloud and edge work together.

Cloud and Edge

If you’re part of the 94% of organizations that use a cloud computing service, then you know that when provisioning the resources (usually either virtual machines or Kubernetes clusters) one of the very first things to do is select from among the available regions-- typically identified by major metros like Dallas, Frankfurt, or Tokyo. The point is that as a user, once you have selected and provisioned resources in a region, those resources do not move beyond those boundaries. Any computation that you run on those resources is bound to that location.

In contrast, edge computing doesn’t require users to pick regions or provision resources. Instead, you deploy your code in any language that the edge computing service accepts. Based on user and device demand, the service will run that code in the appropriate regions, automatically instantiating computation in the right place. With edge computing, your computation is not bound to any one location.

So, which is better, location-bound cloud computing or unbound edge computing? In reality, one is not objectively better than the other. Rather, there are certain use cases where it makes sense to use cloud or edge, depending on whether the data handled is at rest or in motion.

Follow the Data

How do you choose between cloud and edge? Follow the data. As a rule of thumb, it is better to move the computation to the data rather than vice-versa.

Consider the case of computing on data stored in a database, data warehouse, or data lake. For e-commerce, this could be product searches, recommendations, or order tracking and updates. In these cases, the data is in one location or replicated across a small number of fixed locations. The data does not move. It makes sense, then, to bind the computation to those same locations, so location-bound cloud computing is what’s called for.

In contrast, consider the case of computing on data that is in the flow of traffic. Most often we’re dealing with web traffic flows, so we’re talking about data that is in the URL query strings, in HTTP headers, and in HTTP bodies. In cybersecurity, examples include executing web application firewall (WAF) rules to block attacks and classifying requests based on whether or not they’re coming from bots and, if so, the types of bots.

In these cases, rather than backhauling the traffic to some fixed, faraway location, it’s better to run this computation right at the source of the traffic, that is, as near as possible to the users and devices. We’re dealing with data in motion, coming from anywhere and everywhere, which calls for location-unbound edge computing.

In summary, we have two complementary computing services for different use cases: location-bound cloud computing for data at rest, and location-unbound edge computing for data in motion. Cloud computing connects your computation to your data and to other fixed-location resources. Edge computing connects your computation to your users and devices, which can be located anywhere or everywhere.

Making Connections

As I noted above, cloud and edge don’t just complement one another, they need to connect to each other. It’s not about one or the other; it’s about both. That’s because modern applications are not monoliths. Rather, they are increasingly built as collections of services or microservices. It’s with regard to these services that cloud-or-edge decisions must be made.

A modern application will likely span both cloud and edge, with some services running in the cloud core and others at the distributed edge. Moreover, application services need to communicate with each other, making it critical that the cloud core and edge are tightly connected with high scalability, high reliability, high bandwidth, and low latency.

To truly enable innovation, the cloud is no longer enough. The edge is no longer enough. The future is connected: a single application platform combining traditional cloud computing with a highly distributed edge and a high-performance communication fabric to connect it all.