Edge vs Cloud Computing: A Guide for Modern Developers

The Evolution of Content Delivery Networks (CDNs)

Initially focused on caching and protecting origin servers, CDNs began evolving with the rise of serverless computing. A new idea became popular very quickly: developers could define an atomic “function” that runs on-demand in response to an event, such as a new image upload or a new database record, without having to own and maintain the underlying physical or virtual infrastructure.

AWS Lambda was the first example of this new paradigm in 2015. AWS Lambda@Edge followed in 2016, allowing you to adopt the same approach with functions running on top of Amazon CloudFront - AWS’s CDN service.

Popular CDNs followed suit, introducing services such as Cloudflare Workers in 2017, Fastly Compute@Edge in 2019, and Akamai EdgeWorkers in 2019.

And they didn’t stop there! As we said at the beginning of this article, edge computing isn’t just about bringing compute capabilities to the edge. In most cases, you also need some sort of data storage. So CDNs kept evolving and shipped new edge services such as key-value stores, object storage, SQL databases, image resizing, AI inference, and more!

For example:

• Cloudflare’s development platform includes edge services such as Workers KV for key-value storage, D1 for relational SQL databases with point-in-time recovery, R2 for object storage with no egress fee, and Queues for asynchronous task execution. 
• Similarly, on Fastly you find KV Store for storing key-value pairs, secrets, and config data, and Fanout for bi-directional asynchronous pub/sub at the edge.
• And you guessed it, Akamai offers EdgeKV.
• Amazon CloudFront introduced its CloudFront KeyValueStore in 2023.

Today, CDNs offer services that you’d normally expect to run only in a cloud region (or data center), from serverless functions to key-value stores to object storage, queues, and relational databases. Coincidentally, queues, object storage, and compute capacity were the very first cloud services announced back in 2006, now debuting at the edge in a globally distributed fashion.

Under the hood, these new edge compute platforms use different technologies and support different programming languages. For instance, Cloudflare uses the Chrome V8 engine, which initially supported only JavaScript but began incorporating WebAssembly in 2018. On the other hand, Fastly decided to use WebAssembly from the beginning for their environment sandboxing to avoid some of the startup latency limitations of V8. This allows Fastly to support many programming languages, such as TypeScript, Rust, Go, .NET, Ruby, and Swift.

Let’s open a quick parenthesis about WebAssembly.

WebAssembly at the edge

WebAssembly (or Wasm in short) might be the most interesting development in this space. Since it was announced in 2017 and then became a W3C recommendation in 2019, a lot of folks talk about it for browser execution of Wasm binaries, but there is also a lot of potential for server-side execution, including the edge.

Wasm allows you to write business logic in various supported languages and compile it into a binary file that runs on Wasm runtimes like Bytecode Alliance’s wasmtime.

Together with WASI (WebAssembly System Interface), it allows you to compose software written in different languages with a standardized interface by W3C.

If this sounds familiar to something very popular in the cloud world, check out this 2019 tweet from the founder of Docker:

So, the expectations for Wasm + WASI are very high. I highly encourage you to keep an eye on the Bytecode Alliance and its efforts to create secure and open compilers, runtimes, and tooling for WebAssembly. The nonprofit organization was founded in 2019 by Mozilla, Fastly, Intel, and Red Hat. Today, its members include other cloud and edge players such as Amazon, Arm, Cisco, Docker, Fermyon, Microsoft, Nginx, Shopify, Siemens, and VMware.

Edge and Cloud Computing Comparison

Now, back to our exploration of edge computing.

One of the most interesting and notable differences with respect to cloud computing is that the edge is globally distributed by design. Your code and data storage natively runs on hundreds of edge servers. That’s a big difference compared to cloud architectures that typically start as centralized applications running in a single data center (or across 2-3 availability zones within a cloud region).

While many applications can easily run in a centralized way, if you’re building a website or product with a global audience, your architecture will definitely involve some sort of caching and content distribution. And with edge computing that happens automatically, your edge app is globally distributed with a click (or CLI command) and it runs as close as possible to your users for optimized latency.

So here comes the rhetorical question.

Do you still need the cloud?

In other words, is the cloud still the best option for designing and building well-architected, scalable applications in 2024?

Well, yes!

The reality is that for most use cases, the edge still needs some kind of origin to depend on. The origin is where the code business logic runs, whether it’s your website backend or other complex workloads that need to remain centralized (for convenience, technical limitations, or cost).

Let’s have a look at which workloads are likely to remain in the cloud (for now):

• Backend APIs + RDMS - Typically the core of your origin and production databases (there are at least 10 different database services on AWS alone).
• Massive storage - The cloud provides ways to reduce costs via cold storage.
• Data analytics - Your typical data warehouse, data lake, and data pipelines need a centralized data repository to run queries and build reports.
• AI/ML - Training efficiently and cost-effectively requires massive datasets (while inference can already run at the edge).
• HPC/Simulations - High-performance computing is distributed by design but usually within the same data center or region to reduce network overhead.
• CI/CD pipelines - These could run anywhere, but it’s probably more convenient and cheaper to use the cloud (including the pipelines to deploy your edge services).

To summarize, the cloud excels at general-purpose services, supporting almost every possible workload type out there, with virtually infinite storage and horizontal scalability (within a region or across a small number of regions for resiliency and disaster recovery).

Conversely, the edge simplifies global deployments, enhances security, and enables caching for cloud origins while supporting latency-optimized features without adding complexity to your main application.

In other words, cloud computing and edge computing complement each other. They will continue to coexist and solve different technical problems.

Cost-aware architectures

Another interesting angle to consider is cost. As often happens with managed services, the tradeoff is between using an off-the-shelf solution and designing, building, and maintaining your own globally distributed solution.

Since the edge is optimized for global content distribution, it often reduces costs for egress fees. However, edge data storage must be distributed across hundreds of edge servers, making storage and data operations look more expensive than regional cloud services, which typically replicate data only across 2-3 availability zones.

Let’s look at some numbers, focusing on key-value storage for 3 edge services (Cloudflare Workers KV, Fastly KV, CloudFront KeyValueStore) and 2 cloud services (Redis serverless on AWS and DynamoDB on-demand on AWS):

* for each KB 

** the first 25 GB are free

A few interesting differences and observations:

1. Cloudflare doesn’t charge for data transfer but delete operations cost like write operations.
2. Fastly doesn’t charge for delete operations, but you’re limited to 250k writes and 5M reads per month (unless you pay for an add-on).
3. CloudFront KeyValueStore seems crazy optimized for reads, but writes are incredibly expensive compared to the other options.
4. Redis looks pretty cheap, but you have to keep in mind that it’s $0.0038 per KB, so if you’re reading or writing 5KB, it will be 5x more expensive (which is still pretty cheap).
5. DynamoDB is not just a key-value store, but it can definitely be used that way, and it still seems an order of magnitude cheaper than the edge services.

Although cloud services may seem cheaper, it’s crucial to note that they don’t operate on a global scale by default. You can enable DynamoDB Global Tables or Amazon ElastiCache Global Datastore (although it’s not compatible with ElastiCache serverless, so you’ll need to manage multiple clusters, too).

For example, if you enable DynamoDB Global Tables on 10 regions, the write and storage cost is multiplied by 10, so it becomes $7.60 per 1M writes and $3 for 1GB/month. That’s already more expensive than the edge alternatives and only for 10 regions (compared to the hundreds of edge servers).

Real-world Use Cases for Edge Computing

So, what can actually be done at the edge? There are many interesting use cases, and I’m hopeful this article will help you determine which one makes sense for your product.

A few examples:

• Authentication: Implementing edge-based CAPTCHA, passwordless authentication, or JWT validation can reduce the origin load by performing stateless operations at the edge that don’t require database access or other origin resources.
• Data collection: Integrate with external data sources or data destinations, offloading client-side and server-side tracking to the edge to avoid heavy SDKs in the browsers or performance bottlenecks on the server.
• Geo-based enrichment: Enhance your website with ‘near you’ content stored at the edge, implement localized redirects (/en -> /fr), geofencing or per-country throttling using geolocation APIs.
• Content personalization: Store and display recently viewed articles or recommended products at the edge, implement paywalls for premium content, or use A/B testing to provide personalized, contextualized content while minimizing complexity at the origin.
• SEO optimizations: Manipulate HTTP headers and HTML responses directly at the edge to implement custom caching policies, content stitching, or ad-hoc compression algorithms.
• Security: Integrate custom WAFs (Web Application Firewalls) or implement secret headers and custom access control logic.

Or you could design an entire product or suite of products that operates almost entirely at the edge—exactly what we’re doing at Edgee.

Takeaways

I hope this article clarified that CDNs are no longer limited to caching and DDoS protection - they now provide a wealth of valuable services for developers. The edge is a new way to build apps or integrate new features while keeping the origin fast and straightforward.

WebAssembly has a lot of potential, not only for the browser but also for server-side and edge binary execution. 

The cloud is here to stay, and the edge complements its limitations by enabling the creation of globally distributed applications with optimized latency and cost. My personal recommendation is to design and build cost-aware architectures, as it’s a key skill for becoming a more effective developer or architect.