Technical Blueprint — Infrastruttura SaaS a bassa latenza

In questo articolo analizzo le difficoltà tecniche che deve affrontare chiunque voglia risolvere il problema delle applicazioni SaaS distribuite a bassa latenza. E come, in parte, sia possibile superarle.

I criteri di successo prevedono applicazioni stateful, con la latenza più bassa possibile, condivise tra un gruppo di utenti geograficamente vicini. L'applicazione deve essere ospitata dal provider SaaS per due motivi: la validazione dei calcoli da parte del provider stesso e l'alta disponibilità per tutti i partecipanti.

Come è facile immaginare, oggi questo problema viene affrontato in vari modi: ricorrendo ai cloud provider per l'elaborazione in alcune aree densamente popolate, alle Content Delivery Network per estendere la connessione verso le località più remote e a infrastrutture on-premises nelle zone non coperte dai cloud provider.

Collegare e gestire un sistema di questo tipo, però, è un'operazione complessa che solo le aziende più grandi, come Valve, scelgono di affrontare in prima persona. La situazione potrebbe presto cambiare: vediamo insieme come.

Il vero limite invalicabile per gli utenti delle applicazioni a bassa latenza sono le reti fisiche. E sebbene le CDN siano eccellenti nel garantire connessioni tra provider diversi, gli utenti restano in larga parte abbandonati a sé stessi: i numerosi hop di rete aumentano la latenza e impediscono esperienze di alta qualità. Si tratta di un limite invalicabile: per alcune aree geografiche, solo nuovi progetti infrastrutturali a terra e sottomarini possono risolvere il problema. Tecnologie rivoluzionarie come Starlink portano connettività in zone molto più remote, ma la loro latenza resta proibitiva per le applicazioni a bassa latenza.

Il limite superabile, invece, è di natura operativa: interconnettere il traffico tra cloud provider, CDN e hardware diversi. Questa barriera è già stata abbattuta ed è subito disponibile.

Per superare il limite fisico imposto dalla velocità e dalla connettività di rete, occorre eseguire il provisioning dell'hosting delle applicazioni SaaS il più vicino possibile agli utenti. Tutto questo ha un costo e pone la questione di come gestire un'infrastruttura del genere.

Una soluzione universale potrebbe essere un cluster Kubernetes con nodi distribuiti in molte località. Secondo questi benchmark, i container hanno mostrato prestazioni inferiori solo dello 0,12% rispetto ai processi nativi.

Per il provisioning on-demand dei nodi servirebbe una soluzione infrastrutturale come Terraform, capace di richiamare le API dei cloud provider (AWS, GCP, Azure), dei data center basati su VMware e di altri hypervisor. Una porzione consistente del lavoro sarebbe assorbita dalla manutenzione di questa soluzione.

Un progresso introdotto dai cloud provider e ormai dato per scontato è il modello Pay-As-You-Go. Si può iniziare a utilizzare una macchina virtuale su AWS non appena si associa la propria carta di credito. Senza alcun vincolo.

Eppure molti data center tradizionali stanno ancora cercando di colmare il divario nel rendere disponibile online il provisioning dei propri ambienti tramite strumenti di private cloud. Uno degli ostacoli principali riguarda le prestazioni di queste macchine e la misurazione del rapporto qualità-prezzo. In ogni caso, eseguire un pilot resta il modo migliore per ottenere un benchmark specifico sui propri workloads.