Apparently I missed the memo but somewhere in between 2020 and now, edge computing became cool again.
The old-school definition of edge compute was to bring processing power closer to where the data is instead of trying to lug all the data back to a datacenter. This included use cases like point-of-sale systems, automated retail, smart equipment, IoT devices, self-driving cars, autonomous robots… you get the idea. When I was at VMware, this was definitely the edge we referred to. We had to figure out how to do more with less at the edge because there isn’t that much compute available (compared to a full-fledged datacenter), and if you have limited network connectivity, that is yet another hurdle to design around.
There is now however a new version of the Edge (with an uppercase E) that’s being defined by companies like Vercel and Cloudflare. The gist is that even with the existence of the cloud, there is still too much latency between code hosted in a cloud region (like us-west-1) and where the consumption of web content is actually happening (a device). So the answer being proposed by this new Edge is to run code closer to users; a new kind of “serverless” if you will.
This diagram is a straightforward representation of most web apps. The origin is where your code is hosted and running, and the CDN (content delivery network) is where apps can cache images and files near users. The CDN is a part of the Edge. The new addition though is that some Edge servers can now also run code in addition to caching static data. This minimizes the back and forth with your server/origin.
Cloudflare pioneered this with Cloudflare Workers. Cloudflare has a network of over two hundred edge locations worldwide, which means when a user deploys a Worker, it can be handled at a location that is milliseconds away from that user. The magic of it all is that JavaScript is the technology underpinning this, so the same code that runs in a browser can also run in a Cloudflare server at the Edge. In essence, Cloudflare customers can build “serverless” applications that rely entirely on web APIs. Picking and choosing which pieces of the code run where can allow for highly-optimized and performant apps.
Vercel is not far behind with its library called Edge Runtime. Using technology called middleware in Next.js, they’ve made the process of running in the Edge easy and automated for developers (sidenote: Next.js is an open-source React framework created by Vercel)
edge-runtime: a toolkit for developing, testing, and defining the runtime web APIs for edge infrastructure. The Edge Runtime is designed to help framework authors adopt edge computing and provide open-source tooling built on Web standards. It’s designed to be integrated into frameworks (like Next.js) and not for usage in application code. This runtime is purposefully minimal and designed for security and speed. The term “Edge” refers to the orientation toward instant serverless compute environments and not a specific set of locations.
I’m still new to the world of offering serverless Edge compute that’s centered around Javascript but based on rave reviews I hear from users of Cloudflare and Vercel as well as AWS Lambda’s entry into the space with Lambda@Edge, I’m intrigued and I’m going to keep a close eye out.
I thought this infographic was a really great tl;dr of the space overall. The distinctions between edge/multi-regional/regional are still a little fuzzy to me although the author seems to mean
- regional == cloud regions
- edge == CDNs/edge
- multi-regional == mix of both
