Edge vs Cloud Computing: una guida per gli sviluppatori moderni

L’evoluzione delle Content Delivery Network (CDN)

Inizialmente focalizzate sul caching e sulla protezione dei server di origine, le CDN hanno iniziato a evolversi con l’ascesa del serverless computing. Una nuova idea è diventata rapidamente popolare: gli sviluppatori potevano definire una “funzione” atomica che viene eseguita on-demand in risposta a un evento, come un nuovo upload di un’immagine o un nuovo record in un database, senza dover possedere e mantenere l’infrastruttura fisica o virtuale sottostante.

AWS Lambda è stato il primo esempio di questo nuovo paradigma nel 2015. AWS Lambda@Edge è arrivato nel 2016, consentendoti di adottare lo stesso approccio con funzioni in esecuzione su Amazon CloudFront, il servizio CDN di AWS.

Le CDN più diffuse hanno seguito l’esempio, introducendo servizi come i Cloudflare Workers nel 2017, Fastly Compute@Edge nel 2019 e Akamai EdgeWorkers nel 2019.

E non si sono fermate lì! Come detto all’inizio, l’edge computing non riguarda solo il portare capacità di calcolo all’edge. Nella maggior parte dei casi serve anche una qualche forma di archiviazione dati. Così le CDN hanno continuato a evolversi e hanno rilasciato nuovi servizi edge come archivi key-value, object storage, database SQL, ridimensionamento immagini, inferenza AI e altro ancora!

Per esempio:

• Cloudflare offre una piattaforma di sviluppo con servizi edge come Workers KV per lo storage key-value, D1 per database SQL relazionali con ripristino point-in-time, R2 per object storage senza costi di egress e Queues per l’esecuzione asincrona di task. 
• Allo stesso modo, su Fastly trovi KV Store per archiviare coppie key-value, secret e dati di configurazione, e Fanout per pub/sub asincrono bidirezionale all’edge.
• E, come avrai intuito, Akamai offre EdgeKV.
• Amazon CloudFront ha introdotto il suo CloudFront KeyValueStore nel 2023.

Oggi le CDN offrono servizi che normalmente ti aspetteresti di eseguire solo in una regione cloud (o in un data center), dalle funzioni serverless agli archivi key-value, all’object storage, alle code e ai database relazionali. Curiosamente, code, object storage e capacità di calcolo sono stati i primissimi servizi cloud annunciati nel 2006, ora al debutto all’edge in modalità distribuita a livello globale.

Sotto il cofano, queste nuove piattaforme di edge compute usano tecnologie diverse e supportano linguaggi di programmazione differenti. Per esempio, Cloudflare utilizza il motore Chrome V8, che inizialmente supportava solo JavaScript ma ha iniziato a incorporare WebAssembly nel 2018. Fastly invece ha scelto di usare WebAssembly sin dall’inizio per il loro sandboxing dell’ambiente per evitare alcune limitazioni di latenza di avvio di V8. Questo permette a Fastly di supportare molti linguaggi, come TypeScript, Rust, Go, .NET, Ruby e Swift.

Apriamo una breve parentesi su WebAssembly.

WebAssembly all’edge

WebAssembly (o Wasm in breve) potrebbe essere lo sviluppo più interessante in questo ambito. Da quando è stato annunciato nel 2017 e poi è diventato una raccomandazione W3C nel 2019, molti ne parlano per l’esecuzione in browser di binari Wasm, ma c’è anche molto potenziale per l’esecuzione lato server, incluso l’edge.

Wasm ti consente di scrivere la logica di business in vari linguaggi supportati e compilarla in un file binario che gira su runtime Wasm come il wasmtime della Bytecode Alliance.

Insieme a WASI (WebAssembly System Interface), ti permette di comporre software scritto in linguaggi diversi con un’interfaccia standardizzata dal W3C.

Se questo ti suona familiare rispetto a qualcosa di molto popolare nel mondo cloud, dai un’occhiata a questo tweet del 2019 del fondatore di Docker:

Le aspettative per Wasm + WASI sono quindi molto alte. Ti incoraggio vivamente a tenere d’occhio la Bytecode Alliance e i suoi sforzi per creare compilatori, runtime e tool sicuri e aperti per WebAssembly. L’organizzazione no-profit è stata fondata nel 2019 da Mozilla, Fastly, Intel e Red Hat. Oggi tra i suoi membri ci sono altri attori del cloud e dell’edge come Amazon, Arm, Cisco, Docker, Fermyon, Microsoft, Nginx, Shopify, Siemens e VMware.

Confronto tra Edge e Cloud Computing

Torniamo ora alla nostra esplorazione dell’edge computing.

Una delle differenze più interessanti e notevoli rispetto al cloud computing è che l’edge è distribuito globalmente per progettazione. Il tuo codice e il tuo storage dati girano nativamente su centinaia di server edge. È una grande differenza rispetto ad architetture cloud che in genere partono come applicazioni centralizzate in un singolo data center (o su 2-3 zone di disponibilità all’interno di una regione cloud).

Sebbene molte applicazioni possano funzionare facilmente in modo centralizzato, se stai creando un sito o un prodotto con un pubblico globale, la tua architettura includerà sicuramente qualche forma di caching e distribuzione dei contenuti. E con l’edge computing questo avviene automaticamente: la tua app edge è distribuita a livello globale con un clic (o un comando CLI) e gira il più vicino possibile ai tuoi utenti per una latenza ottimizzata.

Ecco quindi la domanda retorica.

Ti serve ancora il cloud?

In altre parole, il cloud è ancora la scelta migliore per progettare e costruire applicazioni ben architettate e scalabili nel 2024?

Ebbene sì!

La realtà è che per la maggior parte dei casi d’uso l’edge necessita ancora di un’origine su cui fare affidamento. L’origine è dove gira la logica di business del codice, che si tratti del backend del tuo sito o di altri carichi complessi che devono restare centralizzati (per praticità, limitazioni tecniche o costi).

Vediamo quali carichi probabilmente rimarranno nel cloud (per ora):

• Backend API + RDMS - Tipicamente il cuore della tua origine e i database di produzione (solo su AWS ci sono almeno 10 servizi database diversi).
• Storage massivo - Il cloud offre modi per ridurre i costi tramite cold storage.
• Data analytics - I tipici data warehouse, data lake e pipeline dati hanno bisogno di un repository dati centralizzato per eseguire query e creare report.
• AI/ML - Il training efficiente e conveniente richiede dataset massivi (mentre l’inferenza può già girare all’edge).
• HPC/Simulazioni - L’high-performance computing è distribuito per natura ma di solito all’interno dello stesso data center o regione per ridurre l’overhead di rete.
• Pipeline CI/CD - Potrebbero girare ovunque, ma probabilmente è più comodo ed economico usare il cloud (incluse le pipeline per distribuire i tuoi servizi edge).

In sintesi, il cloud eccelle nei servizi general-purpose, supportando quasi ogni tipo di carico esistente, con storage virtualmente infinito e scalabilità orizzontale (all’interno di una regione o su un piccolo numero di regioni per resilienza e disaster recovery).

Al contrario, l’edge semplifica le distribuzioni globali, migliora la sicurezza e abilita il caching per le origini cloud supportando funzionalità ottimizzate per la latenza senza aggiungere complessità alla tua applicazione principale.

In altre parole, cloud computing ed edge computing si completano a vicenda. Continueranno a coesistere e a risolvere problemi tecnici diversi.

Architetture consapevoli dei costi

Un altro aspetto interessante da considerare è il costo. Come spesso accade con i servizi gestiti, il trade-off è tra usare una soluzione pronta all’uso e progettare, costruire e mantenere una soluzione distribuita globalmente in proprio.

Poiché l’edge è ottimizzato per la distribuzione globale dei contenuti, spesso riduce i costi di egress. Tuttavia, i dati all’edge devono essere distribuiti su centinaia di server, facendo sembrare storage e operazioni sui dati più costosi rispetto ai servizi cloud regionali, che in genere replicano i dati solo su 2-3 zone di disponibilità.

Vediamo alcuni numeri, concentrandoci sullo storage key-value per 3 servizi edge (Cloudflare Workers KV, Fastly KV, CloudFront KeyValueStore) e 2 servizi cloud (Redis serverless su AWS e DynamoDB on-demand su AWS):

* per ogni KB 

** i primi 25 GB sono gratuiti

Alcune differenze e osservazioni interessanti:

1. Cloudflare non addebita il trasferimento dati, ma le operazioni di delete costano come le write.
2. Fastly non addebita le operazioni di delete, ma sei limitato a 250k write e 5M read al mese (a meno che non paghi un add-on).
3. CloudFront KeyValueStore sembra estremamente ottimizzato per le read, ma le write sono incredibilmente costose rispetto alle altre opzioni.
4. Redis sembra piuttosto economico, ma va tenuto presente che è $0.0038 per KB, quindi se leggi o scrivi 5KB sarà 5 volte più costoso (che è comunque piuttosto economico).
5. DynamoDB non è solo un archivio key-value, ma può sicuramente essere usato così, e sembra comunque un ordine di grandezza più economico dei servizi edge.

Anche se i servizi cloud possono sembrare più economici, è fondamentale notare che non operano su scala globale di default. Puoi abilitare DynamoDB Global Tables o Amazon ElastiCache Global Datastore (anche se non è compatibile con ElastiCache serverless, quindi dovrai gestire anche più cluster).

Per esempio, se abiliti DynamoDB Global Tables su 10 regioni, il costo di write e storage si moltiplica per 10, quindi diventa $7.60 per 1M write e $3 per 1GB/mese. È già più costoso delle alternative edge e solo per 10 regioni (rispetto alle centinaia di server edge).

Casi d’uso reali per l’Edge Computing

Quindi, cosa si può fare concretamente all’edge? Ci sono molti casi d’uso interessanti, e spero che questo articolo ti aiuti a capire quali abbiano senso per il tuo prodotto.

Alcuni esempi:

• Autenticazione: Implementare CAPTCHA all’edge, autenticazione passwordless o validazione JWT può ridurre il carico sull’origine eseguendo operazioni stateless all’edge che non richiedono accesso al database o ad altre risorse dell’origine.
• Raccolta dati: Integra con fonti o destinazioni dati esterne, spostando il tracciamento client-side e server-side all’edge per evitare SDK pesanti nei browser o colli di bottiglia di performance sul server.
• Arricchimento basato sulla geolocalizzazione: Migliora il tuo sito con contenuti “vicino a te” archiviati all’edge, implementa redirect locali (/en -> /fr), geofencing o throttling per paese utilizzando API di geolocalizzazione.
• Personalizzazione dei contenuti: Archivia e mostra all’edge articoli visualizzati di recente o prodotti consigliati, implementa paywall per contenuti premium o usa A/B test per offrire contenuti personalizzati e contestualizzati riducendo al minimo la complessità all’origine.
• Ottimizzazioni SEO: Modifica intestazioni HTTP e risposte HTML direttamente all’edge per implementare policy di caching personalizzate, content stitching o algoritmi di compressione ad hoc.
• Sicurezza: Integra WAF personalizzati (Web Application Firewall) o implementa header segreti e logiche personalizzate di controllo degli accessi.

Oppure potresti progettare un intero prodotto o una suite di prodotti che operano quasi interamente all’edge —esattamente ciò che stiamo facendo in Edgee.

Takeaway

Spero che questo articolo abbia chiarito che le CDN non si limitano più al caching e alla protezione DDoS: ora offrono un’ampia gamma di servizi preziosi per gli sviluppatori. L’edge è un nuovo modo di costruire app o integrare nuove funzionalità mantenendo l’origine veloce e semplice.

WebAssembly ha molto potenziale, non solo per il browser ma anche per l’esecuzione di binari lato server e all’edge. 

Il cloud è qui per restare, e l’edge ne completa le limitazioni permettendo di creare applicazioni distribuite globalmente con latenza e costi ottimizzati. Il mio consiglio personale è di progettare e costruire architetture consapevoli dei costi, perché è una competenza chiave per diventare sviluppatori o architetti più efficaci.