Il tema dell'edge caching e' un tema estremamente intrigante e sotto molti punti di vista complesso. Si parte dalla soluzione null cache, dove in pratica non si mette nulla in cache, per proseguire alla cache uniformemente distribuita, in stile ASP.NET per intenderci, fino ad arrivare alle collaborative edge cache networks.

Qual'e' la soluzione ideale? Tutte e nessuna. Dipende totalmente dal contesto, ed in particolare dalla dinamicita' delle modifiche dei dati, dalla loro dimensione e quantita', dal modo di essere consumati, dal livello di sicurezza, dalla scalabilita', dalla topologia di rete del sistema di distribuzione, dall'uniformita' di distribuzione dei dati sull'edge, consistenza e delays.

1. Dinamicita' di modifica

Vi e' una notevole differenza fra dati che variano in tempo reale e dati che cambiano a scadenze prolungate (una volta al giorno o una volta alla settimana). I primi si adattano poco ad essere messi in cache, i secondi decisamente. Mi pare solamente una basilare regola i buon senso :-)

2. Dimensione e quantita'

Immaginiamo di avere un catalogo prodotti. Mettere il catalogo in cache porta sicuramente dei vantaggi, ma dipende dalla dimensione dei catalogo. Immaginate di mettere tutto il catalogo di Amazon in cache su ogni singolo server! Non ha senso ovviamente. Si puo' quindi ragionare in termini di partizionamento dei dati frammentandoli con algoritmi statistici. Ad esempio caricare in memoria solamente i piu' venduti/consultati e leggere on demand i meno venduti/consultati.

3. Modalita' di consumo

Se abbiamo una applicazione ASP.NET sicuramente l'opzione memoria e' difficilmente sostituibile, ma se abbiamo uno smart client perche' non pensare ad un file precompilato? Sicuramente una chiamata HTTP GET su IIS sara' decisamente piu' performante e scalabile di qualsiasi web service.

4. Livello di sicurezza

Trattare la lista dei codice fiscale piuttosto che i risultati delle partite di calcio e' molto diverso. Si possobo adottare algoritmi di crittografia e/ firma digitale. Da questo punto di vista l'erogazione attragerso una HTTP GET piuttosto che un web service o la memoria fa poca differenza.

5. Scalabilita'

Immaginate di avere il vostro catalogo prodotti che cambia una volta al giorno ed e' salvato nel DB. Avere 1000 o piu' server che richiedono la nuova lista nello stesso momento potrebbe afere un impatto negativo nel DB. Ecco allora che produrre con un agent la cache su file e renderal disponibile ai fari edge via HTTP GET os network share potrebbe risolvere il problema.

6. Topologia di rete del sistema di distribuzione

In alcuni ambienti distribuiti l'edge non ha accesso diretto alla fonte informativa. Ecco allora che si possono introdurre delle cache intermedia, o dei beacon points in stile collaborative edge cache. In pratica si suddivide la rete in rings, all'interno dei quali ci sono dei server privilegiati (beacon points) che fanno da 'ponte'.

7. Uniformita' di distribuzione dei dati sull'edge

Non sempre abbiamo bisogno di tutti gli stessi dati su tutti i server dell'edge. Ecco quindi che dobbiamo razionalizzare i dati e decidere a design time come definire le regole di partizionamento in modo da distribuire partizioni differenti su server differenti.

8 Consistenza e delays

In sistemi distribuiti e' perfettamente accettabile vi siano dei delay, lo e' meno la mancanza di consistenza. Ad esempio e' accettabile che quando si cambi un prodotto nel catalogo questa modifica arrivi sui server anche con minuti o ore di ritardo, ma e' fondamentale che tutti i server propongano le stesse modifiche in modo consistente. Immaginate due server in NLB che prima propongono 10 euro e al secondo click 11 euro! La soluzione consiste nella collaborazione fra i server e nel versioning dei dati.

In questa lista ho ovviamente guardato al problema solamente in modo superficiale e ogni singolo aspetto andrebbe analizzato in profondita'. Diciamo che e' uno spunto di pensiero :-)