Edge vs cloud computing: een gids voor moderne developers

De evolutie van Content Delivery Networks (CDN’s)

Aanvankelijk gericht op caching en het beschermen van origin-servers, begonnen CDN’s zich te ontwikkelen met de opkomst van serverless computing. Een nieuw idee werd razendsnel populair: developers konden een atomische “functie” definiëren die on-demand draait als reactie op een event, zoals een nieuwe upload van een afbeelding of een nieuw databaserecord, zonder de onderliggende fysieke of virtuele infrastructuur te hoeven bezitten en onderhouden.

AWS Lambda was in 2015 het eerste voorbeeld van dit nieuwe paradigma. AWS Lambda@Edge volgde in 2016, waardoor je dezelfde aanpak kon hanteren met functies die draaien bovenop Amazon CloudFront – de CDN-service van AWS.

Populaire CDN’s volgden dit voorbeeld en introduceerden diensten zoals Cloudflare Workers in 2017, Fastly Compute@Edge in 2019 en Akamai EdgeWorkers in 2019.

En daar bleef het niet bij! Zoals we aan het begin van dit artikel al zeiden, draait edge computing niet alleen om rekenkracht naar de edge brengen. In de meeste gevallen heb je ook een vorm van dataopslag nodig. Dus bleven CDN’s zich ontwikkelen en verscheepten ze nieuwe edge-diensten zoals key-value stores, objectopslag, SQL-databases, image resizing, AI-inference en meer!

Bijvoorbeeld:

• Cloudflare’s ontwikkelplatform omvat edge-diensten zoals Workers KV voor key-value-opslag, D1 voor relationele SQL-databases met point-in-time recovery, R2 voor objectopslag zonder egresskosten en Queues voor asynchrone taakverwerking. 
• Op Fastly vind je KV Store voor het opslaan van key-value-paren, secrets en configdata, en Fanout voor bidirectionele asynchrone pub/sub aan de edge.
• En inderdaad, Akamai biedt EdgeKV.
• Amazon CloudFront introduceerde zijn CloudFront KeyValueStore in 2023.

Tegenwoordig bieden CDN’s diensten die je normaal alleen in een cloudregio (of datacenter) zou verwachten, van serverless functies tot key-value stores, objectopslag, queues en relationele databases. Toevallig waren queues, objectopslag en rekencapaciteit de allereerste clouddiensten die in 2006 werden aangekondigd, nu voor het eerst aan de edge in wereldwijd gedistribueerde vorm.

Onder de motorkap gebruiken deze nieuwe edge compute-platforms verschillende technologieën en ondersteunen ze verschillende programmeertalen. Zo gebruikt Cloudflare de Chrome V8-engine, die aanvankelijk alleen JavaScript ondersteunde maar sinds 2018 ook WebAssembly is gaan integreren. Fastly koos er daarentegen vanaf het begin voor om WebAssembly te gebruiken voor hun omgevingssandboxing om enkele opstartlatency-beperkingen van V8 te vermijden. Hierdoor kan Fastly veel programmeertalen ondersteunen, zoals TypeScript, Rust, Go, .NET, Ruby en Swift.

Laten we kort een uitstapje maken naar WebAssembly.

WebAssembly aan de edge

WebAssembly (of kortweg Wasm) is misschien wel de meest interessante ontwikkeling op dit gebied. Sinds de aankondiging in 2017 en de W3C-aanbeveling in 2019 gaat het vaak over het uitvoeren van Wasm-binaries in de browser, maar er is ook veel potentieel voor server-side uitvoering, inclusief aan de edge.

Met Wasm kun je bedrijfslogica in diverse ondersteunde talen schrijven en compileren naar een binair bestand dat draait op Wasm-runtimes zoals Bytecode Alliance’s wasmtime.

Samen met WASI (WebAssembly System Interface) kun je software, geschreven in verschillende talen, componeren met een door W3C gestandaardiseerde interface.

Klinkt dit bekend van iets dat in de cloudwereld erg populair is, bekijk dan deze tweet uit 2019 van de oprichter van Docker:

De verwachtingen voor Wasm + WASI zijn dus erg hoog. Ik raad je sterk aan om de Bytecode Alliance in de gaten te houden en hun inzet voor het creëren van veilige en open compilers, runtimes en tooling voor WebAssembly. De non-profit werd in 2019 opgericht door Mozilla, Fastly, Intel en Red Hat. Tegenwoordig behoren ook andere cloud- en edge-spelers tot de leden, zoals Amazon, Arm, Cisco, Docker, Fermyon, Microsoft, Nginx, Shopify, Siemens en VMware.

Vergelijking van edge- en cloudcomputing

Terug naar onze verkenning van edge computing.

Een van de meest interessante en opvallende verschillen ten opzichte van cloudcomputing is dat de edge ontwerpen van nature wereldwijd gedistribueerd zijn. Je code en dataopslag draaien standaard op honderden edge-servers. Dat is een groot verschil met cloudarchitecturen die doorgaans beginnen als gecentraliseerde applicaties in één datacenter (of over 2-3 availability zones binnen een cloudregio).

Hoewel veel applicaties prima gecentraliseerd kunnen draaien, zal je architectuur zeker een vorm van caching en contentdistributie bevatten als je een website of product voor een wereldwijd publiek bouwt. En met edge computing gebeurt dat automatisch: je edge-app wordt wereldwijd gedistribueerd met één klik (of CLI-commando) en draait zo dicht mogelijk bij je gebruikers voor optimale latency.

En dan nu de retorische vraag.

Heb je de cloud nog steeds nodig?

Met andere woorden: is de cloud in 2024 nog steeds de beste optie om goed ontworpen, schaalbare applicaties te bouwen?

Jazeker!

De realiteit is dat de edge voor de meeste use-cases nog steeds een soort origin nodig heeft om op te steunen. De origin is waar de bedrijfslogica draait, of dat nu je website-backend is of andere complexe workloads die gecentraliseerd moeten blijven (om redenen van gemak, technische beperkingen of kosten).

Laten we kijken welke workloads waarschijnlijk (voorlopig) in de cloud blijven:

• Backend-API’s + RDMS - Doorgaans de kern van je origin en productiedatabases (er zijn alleen al op AWS zeker 10 verschillende databasediensten).
• Massale opslag - De cloud biedt manieren om kosten te verlagen via cold storage.
• Data-analyse - Je typische datawarehouse, datalake en datapijplijnen hebben een gecentraliseerde datarepository nodig om queries te draaien en rapporten te bouwen.
• AI/ML - Efficiënt en kosteneffectief trainen vereist enorme datasets (terwijl inference al aan de edge kan draaien).
• HPC/simulaties - High-performance computing is van nature gedistribueerd, maar meestal binnen hetzelfde datacenter of dezelfde regio om netwerkoverhead te beperken.
• CI/CD-pijplijnen - Die kunnen overal draaien, maar het is waarschijnlijk handiger en goedkoper om de cloud te gebruiken (inclusief de pijplijnen om je edge-diensten te deployen).

Kortom, de cloud blinkt uit in generieke services die vrijwel elk type workload ondersteunen, met praktisch oneindige opslag en horizontale schaalbaarheid (binnen een regio of over een klein aantal regio’s voor veerkracht en disaster recovery).

De edge vereenvoudigt daarentegen wereldwijde deployments, verbetert de beveiliging en maakt caching voor cloud-origins mogelijk, terwijl latency-geoptimaliseerde features worden ondersteund zonder extra complexiteit aan je hoofdapplicatie toe te voegen.

Met andere woorden: cloudcomputing en edge computing vullen elkaar aan. Ze zullen blijven naast elkaar bestaan en verschillende technische problemen oplossen.

Kostenbewuste architecturen

Een andere interessante invalshoek is kosten. Zoals vaak het geval is bij managed services, is de trade-off die tussen een kant-en-klare oplossing gebruiken en zelf een wereldwijd gedistribueerde oplossing ontwerpen, bouwen en onderhouden.

Omdat de edge is geoptimaliseerd voor wereldwijde contentdistributie, verlaagt die vaak de kosten voor egress. Maar edge-dataopslag moet over honderden edge-servers worden gedistribueerd, waardoor opslag en data-operaties duurder lijken dan regionale clouddiensten, die data doorgaans alleen repliceren over 2-3 availability zones.

Laten we naar wat cijfers kijken, met focus op key-value-opslag voor 3 edge-diensten (Cloudflare Workers KV, Fastly KV, CloudFront KeyValueStore) en 2 clouddiensten (Redis serverless op AWS en DynamoDB on-demand op AWS):

* per KB 

** de eerste 25 GB zijn gratis

Een paar interessante verschillen en observaties:

1. Cloudflare rekent geen datatransferkosten, maar delete-operaties kosten evenveel als write-operaties.
2. Fastly rekent geen kosten voor delete-operaties, maar je bent beperkt tot 250k writes en 5M reads per maand (tenzij je voor een add-on betaalt).
3. CloudFront KeyValueStore lijkt extreem geoptimaliseerd voor reads, maar writes zijn ongelooflijk duur vergeleken met de andere opties.
4. Redis lijkt erg goedkoop, maar houd er rekening mee dat het $0.0038 per KB is; als je 5KB leest of schrijft, is het 5x zo duur (nog steeds vrij goedkoop).
5. DynamoDB is niet alleen een key-value store, maar kan zeker zo gebruikt worden, en lijkt nog steeds een orde van grootte goedkoper dan de edge-diensten.

Hoewel clouddiensten goedkoper kunnen lijken, is het cruciaal om op te merken dat ze niet standaard op wereldschaal opereren. Je kunt DynamoDB Global Tables of Amazon ElastiCache Global Datastore inschakelen (al is die niet compatibel met ElastiCache serverless, dus moet je ook meerdere clusters beheren).

Als je bijvoorbeeld DynamoDB Global Tables inschakelt op 10 regio’s, worden de schrijf- en opslagkosten keer 10 vermenigvuldigd, dus wordt het $7.60 per 1M writes en $3 voor 1GB/maand. Dat is al duurder dan de edge-alternatieven en dan heb je het nog maar over 10 regio’s (vergeleken met honderden edge-servers).

Praktische use-cases voor edge computing

Wat kun je nu daadwerkelijk aan de edge doen? Er zijn veel interessante use-cases, en ik hoop dat dit artikel je helpt te bepalen welke voor jouw product logisch is.

Enkele voorbeelden:

• Authenticatie: Edge-gebaseerde CAPTCHA, passwordless authenticatie of JWT-validatie implementeren kan de origin-belasting verlagen door stateless operaties aan de edge uit te voeren die geen database- of andere origin-resources vereisen.
• Dataverzameling: Integreer met externe databronnen of -bestemmingen en verplaats client-side en server-side tracking naar de edge om zware SDK’s in de browser of performanceknelpunten op de server te vermijden.
• Geo-based enrichment: Verrijk je website met ‘bij jou in de buurt’-content die aan de edge is opgeslagen, implementeer gelokaliseerde redirects (/en -> /fr), geofencing of per-land throttling met geolocatie-API’s.
• Contentpersonalisatie: Sla recent bekeken artikelen of aanbevolen producten op en toon ze aan de edge, implementeer paywalls voor premium content of gebruik A/B-testen om gepersonaliseerde, contextuele content te leveren terwijl je de complexiteit bij de origin minimaliseert.
• SEO-optimalisaties: Manipuleer HTTP-headers en HTML-responses direct aan de edge om aangepaste caching policies, content stitching of ad-hoc compressie-algoritmen te implementeren.
• Beveiliging: Integreer custom WAF’s (Web Application Firewalls) of implementeer secret headers en aangepaste toegangscontrolelogica.

Of je kunt een volledig product of een suite van producten ontwerpen die bijna volledig aan de edge draait—precies wat we doen bij Edgee.

Conclusies

Ik hoop dat dit artikel duidelijk maakt dat CDN’s niet meer beperkt zijn tot caching en DDoS-bescherming—ze bieden nu een schat aan waardevolle diensten voor developers. De edge is een nieuwe manier om apps te bouwen of nieuwe features te integreren, terwijl de origin snel en eenvoudig blijft.

WebAssembly heeft veel potentieel, niet alleen voor de browser, maar ook voor server-side en edge-binaire uitvoering. 

De cloud blijft bestaan, en de edge vult de beperkingen ervan aan door het mogelijk te maken wereldwijd gedistribueerde applicaties te bouwen met geoptimaliseerde latency en kosten. Mijn persoonlijke aanbeveling is om kostenbewuste architecturen te ontwerpen en te bouwen, want dat is een sleutelvaardigheid om een effectievere developer of architect te worden.