You’re Already Using the Edge (and may not know it)

It’s hard to not read a tech article these days without seeing something about Edge Computing. It reminds me of the hype around “The Cloud” in 2009, including the confusion about what the “cloud” was useful for.  What seems to be missing now is a good explanation of what the Edge is really good for and why you should care.

To understand how we got here, let’s look back in time to understand what problems the cloud promised to solve:

1. It is just too slow to respond to the day-to-day business needs, especially as applications become more mission critical and as the speed of business accelerates.
2. Applications are becoming more complex and need to call upon infinite compute, networks and storage resources.
3. Applications increasingly need more compute and storage than they can access on their own machines, especially in a burst scenario.
4. Applications running at a single location could become choke-points for information, either by being network constrained, or by being storage or CPU constrained.
5. Enterprises are tiring of the CapEx, OpEx and staffing resource issues associated with running their own data center. Pay as you go is the way to go.

When we realized what cloud computing could deliver, many of us changed how we deployed our applications and pushed them out to Amazon Web Services (AWS) or Heroku or Google Cloud Platform (GCP).  Moving to the cloud may have helped solve some of the problems, but not all of them. Many of us then found that we needed additional cloud services, like using a CDN to accelerate and improve user experiences.

What you didn’t realize is that many of the “Cloud” services you use today are really “Edge” services.  CDN repositories, for example, exist on the edge in order to deliver static content to users, resulting in a fast, responsive web experience. CDNs have been around for years. It’s what I would call Edge 1.0.

Today, we are in the midst of Edge 2.0, which goes way beyond support for static content. While many CDN vendors offer some form of “scripting” or may offer TLS termination for you to plant your certificates on their servers, these are still static services. Edge 2.0 is the non-static edge where you control the compute using your own code, data, config, and containerized application. It’s not just canned JavaScript, minified css files, pictures and videos.

If latency is an issue for your application because it makes multiple round-trips to core servers, you will want to learn more about Edge 2.0. It can also enable you to move your auth or facial recognition closer to your users. It can allow you to shift your datasift or log filtering closer to users.  Or shift IoT data aggregation processing closer to the field deployment locations. Edge 2.0 is about compute at scale across the globe, instead of just in one or two AWS regions. It is about moving the compute to where the data is, instead of moving data to where the compute is.

If you’ve already done the work to make your application deployable to a remote datacenter via Docker Containers, you’re ready for Edge 2.0. Edge 2.0 lets you deploy one or more of your docker containers to as many different edges as your users need.  Instead of deploying static content, it’s deploying executable code.

In future articles, I’ll discuss in more detail the kinds of executable services that make sense to deploy to the edge.

Again, the good news is that you’re already using the edge. You just didn’t necessarily realize it. Now you can start to think about what parts of your applications to take to the edge to make them even faster and stickier for your users.