Fog Computing: cos'è e differenze con il cloud

Il fog computing occupa da qualche tempo una posizione tecnica precisa nell'architettura delle reti distribuite, eppure continua a essere descritto in modo approssimativo nei contesti in cui dovrebbe invece essere compreso con esattezza: quello delle infrastrutture industriali, dei sistemi IoT ad alta densità, delle reti di trasporto intelligente. La confusione con il cloud computing è comprensibile — entrambi i modelli trattano risorse computazionali distribuite, entrambi fanno uso di virtualizzazione e orchestrazione — ma le differenze operative sono sostanziali e ignorarle porta a scelte architetturali costose da correggere a posteriori.

Il termine "fog" è stato introdotto da Cisco nel 2014 come metafora spaziale: il cloud è lontano, in alto; la nebbia è vicina al suolo, diffusa, presente nel punto in cui si genera il dato. In pratica, il fog computing porta capacità di elaborazione, storage e networking ai margini della rete — non sull'endpoint finale (quello è l'edge computing in senso stretto), ma su nodi intermedi fisicamente prossimi ai dispositivi: gateway industriali, switch con capacità computazionale, server collocati in cabine stradali o in impianti di produzione. Questa collocazione intermedia è la chiave per capire sia le potenzialità del modello sia i suoi vincoli.

Nel 2026, con la diffusione capillare dei sensori industriali connessi, dei veicoli a guida autonoma in fase di deployment su scala urbana e delle reti 5G/6G che abbassano la latenza radio ma non eliminano il collo di bottiglia verso il datacenter centrale, il fog computing ha smesso di essere un'architettura di nicchia per diventare un elemento strutturale di molte infrastrutture critiche. Comprenderne la logica operativa — non solo la definizione — è il presupposto per progettare sistemi che reggano sotto carico reale.

Posizionamento architetturale: dove si colloca il nodo fog

Nella gerarchia delle architetture distribuite, il nodo fog si colloca tra il dispositivo finale — il sensore, l'attuatore, la telecamera — e il datacenter cloud, svolgendo funzioni di pre-elaborazione, filtraggio, aggregazione e decisione locale che altrimenti richiederebbero un transito verso l'infrastruttura centrale. Questo posizionamento non è arbitrario: risponde a un problema concreto di latenza e di volume. Un impianto manifatturiero con tremila sensori attivi genera un flusso di dati che, se inviato grezzo al cloud, satura la banda disponibile e introduce ritardi incompatibili con il controllo in tempo reale. Il nodo fog riceve quel flusso, applica logiche di filtraggio predefinite, trattiene localmente i dati necessari alla reazione immediata e invia al cloud solo gli aggregati significativi — log strutturati, anomalie, metriche di sintesi.

A differenza di un semplice gateway, il nodo fog esegue workload computazionali complessi: può ospitare container, eseguire modelli di inferenza addestrati altrove e distribuiti in locale, gestire code di messaggi, applicare regole di orchestrazione. La piattaforma OpenFog Reference Architecture — oggi assorbita nell'IEEE 1934 — definisce sette attributi fondamentali del nodo fog: sicurezza, scalabilità, apertura, autonomia, programmabilità, affidabilità e gerarchia. Quest'ultimo punto è spesso sottovalutato: i nodi fog possono organizzarsi in livelli, dove un nodo di livello superiore aggrega i risultati di più nodi subordinati prima di inoltrarli al cloud. Si tratta di un'architettura a cascata che distribuisce non solo la computazione ma anche la responsabilità decisionale.

Differenze operative rispetto al cloud computing

Ridurre il confronto tra fog e cloud a una questione di latenza è tecnicamente corretto ma incompleto: ci sono almeno tre dimensioni operative in cui i due modelli divergono in modo che impatta direttamente la progettazione dei sistemi. La prima è la continuità di servizio in assenza di connettività: un nodo fog ben progettato continua a operare anche quando il collegamento verso il datacenter centrale è interrotto, mantenendo la logica applicativa locale e sincronizzando quando la connessione si ristabilisce; un'architettura puramente cloud-dipendente, in quelle stesse condizioni, si blocca o degrada in modo non controllato.

La seconda dimensione riguarda la governance del dato: con il fog computing, i dati sensibili — biometrici, industriali, relativi a infrastrutture critiche — possono essere elaborati localmente senza mai lasciare il perimetro fisico dell'impianto, il che semplifica notevolmente la conformità normativa in ambiti regolamentati come quello sanitario o energetico. La terza dimensione è il costo di trasmissione: il modello di pricing dei principali provider cloud prevede tariffe per il dato in uscita (egress cost) che, su volumi industriali, diventano voci di spesa rilevanti; spostare l'elaborazione sul nodo fog riduce il volume di dati trasmessi e, di conseguenza, la spesa operativa, a fronte di un investimento iniziale in hardware distribuito.

Relazione con l'edge computing e rischio di sovrapposizione concettuale

La distinzione tra fog computing ed edge computing è una delle aree in cui la letteratura tecnica è meno uniforme, con alcuni autori che trattano i due termini come sinonimi e altri che li separano con criteri variabili. La lettura più coerente con le specifiche IEEE è quella che riserva "edge" ai dispositivi finali o ai nodi immediatamente adiacenti — il microcontrollore integrato nel sensore, il modulo di elaborazione montato sulla telecamera — e "fog" ai livelli intermedi con capacità computazionale più strutturata, collocati a una distanza maggiore dall'endpoint ma ancora all'interno del perimetro locale. In questa lettura, l'edge genera il dato e applica logiche minimali; il fog aggrega, correla, decide; il cloud archivia, addestra modelli, fornisce visibilità globale.

Questa gerarchia a tre livelli — edge, fog, cloud — è quella adottata dai principali standard industriali per l'Industrial Internet of Things (IIoT) e riflette una realtà operativa precisa: non tutti i dispositivi hanno le risorse per ospitare logica applicativa complessa, e non tutti i processi decisionali richiedono la latenza minima garantita dall'elaborazione sull'endpoint. Il fog occupa quello spazio intermedio con un compromesso tecnico ben calibrato: latenza nell'ordine dei millisecondi anziché dei microsecondi, ma capacità di elaborazione enormemente superiore a quella di un dispositivo edge.

Casi d'uso in cui il fog computing è determinante

Le applicazioni in cui il fog computing dimostra il vantaggio più netto rispetto alle alternative sono quelle che combinano alta frequenza di campionamento, requisiti di latenza stretti e vincoli di connettività intermittente; il caso paradigmatico è quello dei sistemi di controllo industriale in ambienti con copertura di rete non garantita, come miniere, piattaforme offshore o impianti in aree remote. In questi contesti, il nodo fog non è una scelta architetturale preferibile ma una necessità funzionale: senza elaborazione locale, il sistema non può operare in sicurezza.

Un secondo dominio di applicazione significativo è quello delle smart grid e della gestione distribuita dell'energia: con la proliferazione di impianti di generazione distribuita — fotovoltaico residenziale, accumuli stazionari, veicoli elettrici come risorse di rete — la rete di distribuzione ha bisogno di prendere decisioni di bilanciamento su scala locale con tempi di risposta che il cloud non può garantire. I nodi fog collocati nelle cabine di distribuzione o negli aggregatori locali svolgono qui una funzione di controllo primario, mentre il cloud gestisce la pianificazione a medio termine e l'ottimizzazione globale.

Nel settore della mobilità autonoma, dove le architetture V2X (vehicle-to-everything) richiedono coordinamento tra veicoli, infrastruttura stradale e centri di gestione del traffico, il fog computing abilita la comunicazione a bassa latenza tra veicoli e infrastruttura locale senza dipendere dalla disponibilità di un collegamento al datacenter centrale; è una distinzione che ha implicazioni di sicurezza dirette, perché un sistema di prevenzione collisioni che dipende da una risposta cloud introduce un margine di incertezza temporale inaccettabile.

Sfide di deployment e gestione dell'infrastruttura fog

Distribuire nodi fog su larga scala comporta una serie di sfide operative che chi progetta queste architetture incontra sistematicamente: la prima riguarda l'aggiornamento del software. In un datacenter cloud, il patching è centralizzato e relativamente semplice; su una rete di centinaia o migliaia di nodi fog distribuiti geograficamente, lo stesso processo richiede un sistema di gestione remota robusto, procedure di rollback affidabili e la capacità di gestire versioni eterogenee del software durante le finestre di transizione. Strumenti come KubeEdge — l'estensione di Kubernetes per i nodi distribuiti — o il framework EdgeX Foundry affrontano parte di questo problema, ma la complessità operativa rimane significativamente superiore a quella di un'architettura centralizzata.

La sicurezza fisica dei nodi è un secondo tema che nei datacenter tradizionali non si pone con la stessa urgenza: un nodo fog installato in una cabina stradale, in un magazzino automatizzato o in un'area industriale condivisa è fisicamente accessibile a soggetti non autorizzati, il che richiede misure di hardening dell'hardware — secure boot, TPM, cifratura del storage locale — che aggiungono costo e complessità alla fase di provisioning. A questo si aggiunge la questione della superficie di attacco: ogni nodo fog è un punto di ingresso potenziale nella rete, e la sua compromissione può avere effetti laterali su sistemi adiacenti se la segmentazione di rete non è implementata con rigore.

Infine, la dimensione della standardizzazione rimane aperta: nonostante IEEE 1934 e le specifiche OpenFog Consortium, l'ecosistema dei vendor offre soluzioni spesso proprietarie nei livelli di orchestrazione e comunicazione tra nodi, il che rende complessa la costruzione di infrastrutture multi-vendor coerenti. Nell'orizzonte del 2026, con la maturazione delle piattaforme di orchestrazione distribuita e l'adozione crescente di standard aperti per la comunicazione machine-to-machine, questa frammentazione tende a ridursi — ma rimane un fattore da considerare nelle scelte di architettura a lungo termine.