Google doet niet aan ‘open boek’. Ze houden hun interne architectuur strak achter slot en grendel. U zult geen openbare blauwdruk vinden voor de motor die Google Documenten aandrijft. Maar we vliegen niet blind. We kunnen naar de andere projecten van Google en hun bekende technische gewoonten kijken om te reverse-engineeren hoe dit ding waarschijnlijk werkt.
Laten we beginnen met wat is bevestigd. Het zware werk aan de serverzijde (de backend-logica die uw verzoeken verwerkt) is geschreven in Java. Dit is geen verrassing. Java is een objectgeoriënteerde taal, oorspronkelijk van Sun Microsystems. Google gebruikt het al jaren als fundamentele bouwsteen. Het is robuust. Het is schaalbaar. Het past bij hun behoeften.
Aan de andere kant van het scherm handelt uw browser de rest af. Dit is de klantkant. Het is afhankelijk van JavaScript om de interface responsief te houden. Verwar Java en JavaScript niet. Ze delen een naam, maar zijn verschillende technologieën. Java bouwt stand-alone applicaties. JavaScript verbetert de webervaringen in de browser. Het loopt niet buiten dat raam.
Afgezien van deze twee feiten zijn de details het geheim van Google. Maar we kunnen weloverwogen gissingen maken op basis van hoe ze eerder soortgelijke problemen hebben aangepakt. Kijk vooral naar het Google-bestandssysteem. Het geeft ons een routekaart.
Goedkope hardware, grote schaal
Google heeft een lange geschiedenis in het kopen van goedkope, kant-en-klare hardware. Ze kopen meestal niet de krachtigste individuele servers. Ze kopen duizenden bescheiden exemplaren. De servers waarop Google Docs draait, zijn waarschijnlijk ‘werkpaard’-machines. Niets bijzonders.
Waarom? Omdat redundantie goedkoper is dan premium hardware. Als één dure server uitvalt, stopt het bedrijf. Als een goedkope server uitvalt, zet Google een andere op. Deze aanpak creëert een schaalbaar systeem. U kunt eenvoudig capaciteit toevoegen. U hoeft niet de hele infrastructuur te upgraden wanneer het verkeer piekt.
Waar staan uw bestanden?
De opstelling ziet er waarschijnlijk ongeveer zo uit. U beschikt over applicatieservers waarop de daadwerkelijke Google Documenten-software draait. Dan heb je databaseservers die jouw gegevens opslaan. Er is waarschijnlijk een controle of administratieve server die als poortwachter fungeert en het verkeer en updates beheert.
Omdat goedkope hardware kapot gaat, gaat Google uit van een mislukking. Voortdurend. Ze gebruiken redundantie. Uw document wordt niet op één plek opgeslagen. Het wordt gekopieerd naar meerdere databaseservers. Als een knooppunt donker wordt, haalt Google Documenten de informatie van een ander knooppunt. De servers praten met een centraal controlepunt om alles gesynchroniseerd te houden.
De fysieke realiteit
Om hoeveel machines gaat het? Het exacte aantal weten we niet. Maar we weten dat ze enorme datacenters gebruiken. Een datacenter is slechts een gebouw vol computerapparatuur. De servers bevinden zich in metalen rekken die racks worden genoemd. Een grote faciliteit zou duizenden van deze servers kunnen huisvesten.
Het is een enorme, gedistribueerde puzzel. Google Documenten is niet alleen een webpagina. Het is een complex ecosysteem gebouwd op Java, JavaScript en de veronderstelling dat alles uiteindelijk kapot zal gaan. En dat is de sleutel. Het systeem is ontworpen om die breuk te overleven zonder dat u het merkt.
We zullen dieper ingaan op waar deze technologie naartoe gaat. Maar weet voor nu dat uw ‘eenvoudige’ document waarschijnlijk op tientallen goedkope, redundante servers ergens in een koude, donkere kamer staat.
