Dopo aver accennato qualcosa sulla scalabilità verticale, proponiamo, dall'articolo dello stesso autore, una disamina anche sulla scalabilità orizzontale (scale out) delle applicazioni enterprise di Java. L'autore assicura che l'architettura detta share nothing cluster è la migliore per assicurare alta scalabilità alle nostre applicazioni cluster: in questa architettura ogni nodo espleta tutte le funzioni e prescinde dall'esistenza dell'altro, e la scalabilità del servizio è demandata ad un load balancer con semplice sticky session attiva e semplice logica di bilanciamento (round robin, ad esempio).

Tuttavia a volte è necessario implementare anche una sequenza di HttpSession failover, per permettere la continuità del servizio e questo violerebbe l'architettura sopra citata. Per ovviare a questo inconveniente ci sono anche altre soluzioni che l'autore approfondisce nell'articolo, fra le quali alcune sono inerenti la scalabilità delle applicazioni enterprise di Java, purché non influiscano sull'efficienza e sulle performance del prodotto stesso.

La prima è Memcached, che non è un prodotto Java, ma fornisce client API, attraverso le quali si è in grado di alleggerire delle richieste su un database per i dati in condivisione. Purtroppo per usare questo strumento bisogna mettere mano al codice.

L'altro prodotto è Terracotta, di cui si è avuto modo di parlare, un progetto open source in grado di fare il deploy di una stessa applicazione in più JVM, senza dover mettere mano al codice per sfruttarlo.

Altri prodotti invece hanno lo scopo di poter lavorare su moli di dati in modo distribuito. Questi si basano sul modello Map Reduce. Un esempio di questa tipologia di prodotti è Hadoop: tale framework è in grado di dividere il lavoro in tanti piccoli sottoblocchi unitari di lavoro in modo da lavorare in parallelo.

MPI è, invece, un protocollo usato per la programmazione parallela, e anche in Java si trovano implementazioni di questo protocollo, quali MPJ o mpiJava.

Ultimo esempio citato è il file system distribuito usato da Google, GFS, delle API per utilizzarlo e del database distribuito Bigtable, ingegnerizzato per risolvere l'enorme mole di dati che il colosso dei motori di ricerca deve gestire. Bigtable è altamente scalabile e affidabile ma ha il trade-off nella complessità che si va ad aggiungere quando lo si utilizza.