Google no hace “libro abierto”. Mantienen su arquitectura interna bajo llave. No encontrará un modelo público para el motor que impulsa Google Docs. Pero no estamos volando a ciegas. Podemos observar los otros proyectos de Google y sus hábitos de ingeniería conocidos para realizar ingeniería inversa sobre cómo probablemente funcione esto.
Empecemos por lo confirmado. El trabajo pesado del lado del servidor (la lógica de backend que procesa sus solicitudes) está escrito en Java. Esto no es ninguna sorpresa. Java es un lenguaje orientado a objetos originario de Sun Microsystems. Google lo ha utilizado como elemento fundamental durante años. Es robusto. Es escalable. Se adapta a sus necesidades.
Al otro lado de la pantalla, tu navegador se encarga del resto. Este es el lado del cliente. Se basa en JavaScript para mantener la capacidad de respuesta de la interfaz. No confunda Java y JavaScript. Comparten un nombre pero son tecnologías distintas. Java crea aplicaciones independientes. JavaScript mejora las experiencias web dentro del navegador. No corre fuera de esa ventana.
Más allá de esos dos hechos, los detalles son el secreto de Google. Pero podemos hacer conjeturas basadas en cómo han manejado problemas similares antes. Específicamente, mire el Sistema de archivos de Google. Nos da una hoja de ruta.
Hardware barato, gran escala
Google tiene un largo historial de compra de hardware barato y disponible en el mercado. No suelen comprar los servidores individuales más potentes. Compran miles de modestos. Los servidores que ejecutan Google Docs probablemente sean máquinas “caballo de batalla”. Nada especial.
¿Por qué? Porque la redundancia es más barata que el hardware premium. Si falla un único servidor costoso, el negocio se detiene. Si un servidor barato muere, Google pone en marcha otro. Este enfoque crea un sistema escalable. Puede agregar capacidad fácilmente. No es necesario actualizar toda la infraestructura cuando aumenta el tráfico.
¿Dónde residen tus archivos?
La configuración probablemente se parezca a esta. Tiene servidores de aplicaciones que ejecutan el software Google Docs real. Luego tienes servidores de bases de datos que almacenan tus datos. Es probable que haya un control o un servidor administrativo que actúe como guardián y administre el tráfico y las actualizaciones.
Dado que el hardware barato se estropea, Google asume el fracaso. Constantemente. Usan redundancia. Su documento no se almacena en un solo lugar. Se copia en varios servidores de bases de datos. Si un nodo se apaga, Google Docs extrae la información de otro. Los servidores hablan con un punto de control central para mantener todo sincronizado.
La realidad física
¿Cuántas máquinas están involucradas? No sabemos el número exacto. Pero sabemos que utilizan enormes centros de datos. Un centro de datos es solo un edificio lleno de equipos informáticos. Los servidores se encuentran en estanterías metálicas llamadas racks. Una instalación grande podría albergar miles de estos servidores.
Es un rompecabezas masivo y distribuido. Google Docs no es sólo una página web. Es un ecosistema complejo construido sobre Java, JavaScript y la suposición de que todo eventualmente fallará. Y esa es la clave. El sistema está diseñado para sobrevivir a esa rotura sin que usted se dé cuenta.
Profundizaremos hacia dónde se dirige esta tecnología a continuación. Pero por ahora, sólo sepa que su documento “simple” probablemente se encuentre en docenas de servidores baratos y redundantes en algún lugar de una habitación fría y oscura.
