Google non fa “libro aperto”. Mantengono la loro architettura interna sotto stretta chiave. Non troverai un progetto pubblico per il motore che alimenta Google Docs. Ma non stiamo volando alla cieca. Possiamo esaminare gli altri progetti di Google e le loro note abitudini ingegneristiche per decodificare il modo in cui probabilmente funzionerà questa cosa.
Cominciamo con ciò che è confermato. Il lavoro pesante sul lato server, ovvero la logica di backend che elabora le tue richieste, è scritto in Java. Questa non è una sorpresa. Java è un linguaggio orientato agli oggetti originario di Sun Microsystems. Google lo utilizza da anni come elemento fondamentale. È robusto. È scalabile. Si adatta alle loro esigenze.
Dall’altro lato dello schermo, il tuo browser gestisce il resto. Questo è il lato client. Si basa su JavaScript per mantenere l’interfaccia reattiva. Non confondere Java e JavaScript. Condividono un nome ma sono tecnologie distinte. Java crea applicazioni autonome. JavaScript migliora l’esperienza web all’interno del browser. Non funziona fuori da quella finestra.
Al di là di questi due fatti, le specifiche sono il segreto di Google. Ma possiamo fare ipotesi plausibili in base a come hanno gestito problemi simili in precedenza. Nello specifico, esamina il Google File System. Ci fornisce una tabella di marcia.
Hardware economico, su larga scala
Google ha una lunga storia di acquisto di hardware economico e standardizzato. Di solito non acquistano i singoli server più potenti. Ne comprano migliaia di modesti. I server che eseguono Google Docs sono probabilmente macchine “cavalli di battaglia”. Niente di speciale.
Perché? Perché la ridondanza è più economica dell’hardware premium. Se un singolo server costoso fallisce, l’attività si ferma. Se un server economico muore, Google ne crea un altro. Questo approccio crea un sistema scalabile. Puoi aggiungere capacità facilmente. Non è necessario aggiornare l’intera infrastruttura quando il traffico aumenta.
Dove risiedono i tuoi file?
La configurazione probabilmente assomiglia a questa. Disponi di server applicazioni che eseguono il software Google Docs effettivo. Poi hai dei server di database che memorizzano i tuoi dati. Probabilmente è presente un controllo o un server amministrativo che funge da gatekeeper, gestendo il traffico e gli aggiornamenti.
Poiché l’hardware economico si rompe, Google presume il fallimento. Costantemente. Usano la ridondanza. Il tuo documento non è archiviato in un unico posto. Viene copiato su più server di database. Se un nodo si oscura, Google Docs estrae le informazioni da un altro. I server comunicano con un punto di controllo centrale per mantenere tutto sincronizzato.
La realtà fisica
Quante macchine sono coinvolte? Non conosciamo il numero esatto. Ma sappiamo che utilizzano enormi datacenter. Un data center è semplicemente un edificio pieno di apparecchiature informatiche. I server si trovano in scaffalature metalliche chiamate rack. Una grande struttura potrebbe ospitare migliaia di questi server.
È un puzzle enorme e distribuito. Google Docs non è solo una pagina web. È un ecosistema complesso costruito su Java, JavaScript e sul presupposto che prima o poi tutto si romperà. E questa è la chiave. Il sistema è progettato per sopravvivere a quella rottura senza che tu te ne accorga.
Approfondiremo in seguito dove si sta dirigendo questa tecnologia. Ma per ora, sappi solo che il tuo “semplice” documento probabilmente riposa su dozzine di server economici e ridondanti da qualche parte in una stanza fredda e buia.
