Cos'è l'edge computing e quando serve davvero

"Edge" è una di quelle parole che compaiono ovunque nel marketing delle piattaforme cloud, di solito accanto a "velocissimo", senza che sia mai chiaro cosa cambi concretamente. Dietro c'è un'idea semplice e una fisica che non si può aggirare, ma anche parecchi casi in cui non serve a niente. In questo articolo trovi cosa significa davvero, quando fa una differenza misurabile e quando è solo una complicazione.

Cos'è

L'edge computing consiste nell'eseguire il codice su server distribuiti geograficamente, vicini a chi fa la richiesta, invece che in un unico data center centrale.

Il modello tradizionale ha un server in un posto solo — mettiamo Francoforte. Chi visita da Milano riceve una risposta rapida, chi visita da Sydney molto meno, perché i dati devono attraversare mezzo pianeta.

Con l'edge, il codice è replicato su decine o centinaia di località. La richiesta da Sydney viene servita da un server in Australia.

Il vincolo che sta sotto è fisico, non tecnologico. La luce in fibra percorre circa 200.000 km al secondo, e un giro di andata e ritorno Europa-Australia costa intorno ai 250-300 millisecondi solo di viaggio — prima ancora che qualcuno elabori qualcosa. Nessun server più veloce e nessun codice più efficiente possono ridurre quel numero. L'unico modo di eliminare la distanza è non percorrerla.

Non è la stessa cosa di una CDN

Distinzione che genera confusione, perché le due cose girano sulla stessa infrastruttura.

Una CDN distribuisce file già pronti: immagini, CSS, JavaScript, pagine statiche. Copia e serve, senza eseguire nulla.

L'edge computing esegue codice in quelle stesse località: legge la richiesta, decide, calcola, genera una risposta diversa a seconda di chi sta chiedendo.

La CDN è un magazzino distribuito, l'edge è un piccolo ufficio distribuito. Le CDN moderne offrono entrambe le cose, ed è per questo che i confini si sono sfumati.

Cosa ci si fa davvero

I casi in cui l'edge è la risposta giusta hanno tutti la stessa forma: decisioni semplici e rapide che devono avvenire prima possibile.

Reindirizzamenti e instradamento. Mandare l'utente alla versione linguistica giusta, gestire i domini, spostare vecchi URL. Farlo all'edge evita completamente il viaggio verso l'origine.

Autenticazione e controllo degli accessi. Verificare un token e respingere chi non ha diritto, senza disturbare il server principale. Una richiesta non autorizzata viene fermata nel paese di chi la fa.

Test A/B e personalizzazione leggera. Decidere quale variante mostrare in base a un cookie o alla provenienza geografica.

Trasformazione delle risposte. Aggiungere intestazioni di sicurezza, riscrivere HTML, adattare immagini.

Limitazione della frequenza e filtro. Bloccare traffico indesiderato dove arriva, prima che consumi risorse — logica affine a quella descritta in cos'è un attacco DDoS.

Il filo conduttore: operazioni che durano millisecondi e non hanno bisogno di consultare un database centrale.

Il limite che ribalta il ragionamento

Qui sta la cosa che quasi nessuna presentazione entusiasta dice, ed è decisiva.

Se la tua funzione edge deve interrogare un database che sta in un posto solo, hai peggiorato la situazione.

Immagina la funzione che gira a Sydney e il database a Francoforte. La richiesta arriva veloce al server australiano, poi quello attraversa il pianeta per leggere i dati, e magari lo fa più volte. Hai aggiunto un giro invece di eliminarlo. Il risultato è più lento del modello centralizzato, dove funzione e database sono nella stessa stanza.

La regola pratica: il calcolo va tenuto vicino ai dati. Spostare il codice all'edge conviene solo se all'edge ci sono anche i dati che gli servono — o se non gliene servono affatto.

Esistono database progettati per replicarsi geograficamente, e gli archivi chiave-valore distribuiti risolvono il caso della configurazione letta spesso e scritta di rado. Ma sono strumenti da scegliere consapevolmente, con i loro compromessi sulla coerenza dei dati: la scelta si inquadra in quale database scegliere.

Cosa cambia nel modo di scrivere il codice

Le piattaforme edge non eseguono un ambiente server completo. Girano in ambienti isolati e leggeri, e questo comporta vincoli concreti:

Tempo di esecuzione molto limitato. Sono pensate per millisecondi, non per elaborazioni lunghe.

Niente file system. Non scrivi file temporanei.

Librerie limitate. Molti pacchetti che presuppongono un ambiente server completo non funzionano. È lo scoglio pratico che si incontra per primo.

Nessuno stato tra una richiesta e l'altra. Ogni invocazione è indipendente, come per le serverless functions classiche.

In compenso l'avvio è quasi immediato, perché non c'è un container da accendere: è il vantaggio principale rispetto alle funzioni serverless tradizionali, dove la prima chiamata dopo un periodo di inattività paga un ritardo sensibile.

Edge, serverless o server classico

	Server classico	Serverless	Edge
Dove gira	Una macchina	Una regione	Ovunque
Latenza di rete	Alta se lontano	Media	Minima
Ritardo all'avvio	Nessuno	Presente	Quasi nullo
Durata dell'esecuzione	Illimitata	Minuti	Millisecondi
Librerie disponibili	Tutte	Quasi tutte	Limitate
Vicinanza al database	Massima	Buona	Problematica

Non sono alternative in competizione: quasi ogni applicazione seria le combina. Edge per instradamento e controlli, serverless o server per la logica applicativa vera, database dove serve.

Quando NON ti serve

La sezione onesta, e riguarda la maggioranza dei casi.

Se il tuo pubblico è italiano, non ti serve. Un server in Europa risponde a un utente italiano in poche decine di millisecondi. L'edge ti farebbe risparmiare una frazione impercettibile, a fronte di vincoli reali sul codice. Per un pubblico concentrato in un'area geografica, il modello centralizzato è la scelta corretta.

Se il tuo sito è statico, ti basta una CDN. Le pagine sono già distribuite e non c'è codice da eseguire. Il tema è coperto in come velocizzare un sito web.

Se il problema è altrove. Un sito lento per immagini non ottimizzate, query mal scritte o troppo JavaScript non guarisce spostando il calcolo: quei difetti viaggiano insieme al codice. Prima si misura — vedi i Core Web Vitals — poi si interviene sulla causa vera. Rincorrere l'edge mentre il collo di bottiglia è il database è il modo più elegante di perdere tempo.

Se stai iniziando. Metti online la cosa, guarda da dove arrivano gli utenti, poi decidi. L'ottimizzazione geografica è un problema da avere, non da prevenire.

Ha senso quando hai utenti realmente distribuiti su più continenti e la latenza è un problema misurato, non ipotizzato.

Errori comuni

Ottimizzare senza misurare. Se non sai da dove arriva il traffico e quanto pesa la latenza rispetto al resto, non sai se l'edge cambierà qualcosa.

Mettere all'edge codice che interroga un database lontano. L'errore descritto sopra, e il più frequente.

Confondere disponibilità geografica e coerenza dei dati. Replicare i dati in più continenti significa affrontare il problema di cosa succede quando due località vengono aggiornate contemporaneamente. Non è un dettaglio implementativo: è una decisione di progetto.

Dare per scontato che le librerie funzionino. Verificalo prima di riprogettare, non dopo.

In sintesi

L'edge computing esegue il codice vicino a chi lo richiede, per aggirare l'unico limite che nessuna ottimizzazione supera: la distanza fisica.

Funziona benissimo per operazioni brevi e autosufficienti — reindirizzamenti, autenticazione, personalizzazione leggera, filtri — e male per tutto ciò che deve consultare dati che stanno da un'altra parte.

La regola da ricordare: il calcolo va tenuto vicino ai dati. Spostare la funzione lontano dal database peggiora le cose invece di migliorarle.

E per la maggior parte dei progetti italiani non serve. Con un pubblico concentrato in Europa, un server europeo e una CDN davanti danno già il risultato migliore, senza i vincoli di ambienti di esecuzione limitati.

Se stai valutando dove mettere la tua applicazione, il quadro generale è in cos'è il cloud computing e il confronto pratico in come fare il deploy di un sito.