El poema Claude 4.5, escrito por Sonnet, está bastante bien escrito en mi opinión. (El texto completo contiene 17.000 palabras; esta es la primera parte.) El Dios del Código: Biografía de Jeff Dean Jeff Dean nació en Hawái el 23 de julio de 1968. Este archipiélago del Pacífico es conocido por sus volcanes, playas y cultura diversa, pero rara vez se le considera una cuna de genios científicos. Pero la infancia de Dean estaba destinada a ser todo menos ordinaria. Su padre, Andy, era investigador de enfermedades tropicales. Su madre, Virginia Lee, era antropóloga médica y hablaba seis idiomas. Estos antecedentes familiares implicaron que su crianza incluyera migraciones globales: desde Hawái a los Centros para el Control y la Prevención de Enfermedades en Atlanta, a la Organización Mundial de la Salud en Ginebra y, finalmente, a Minnesota. A los trece años, incluso faltó a los últimos tres meses de octavo grado para ir a un campo de refugiados en el oeste de Somalia a ayudar a sus padres. Este entorno en constante cambio fomentó su temprana intuición sobre los sistemas complejos: **ya fueran los patrones de transmisión de enfermedades o, más tarde, el flujo de datos en las redes informáticas, todos seguían ciertas reglas que podían comprenderse, modelarse y optimizarse.** Por diversión, padre e hijo programaron juntos un ordenador con el paquete IMSAI 8080. Soldaron piezas de mejora a la máquina y aprendieron sobre cada uno de sus componentes. Esta experiencia de comprender las computadoras desde una perspectiva de hardware se convertirá en la piedra angular de la carrera de Dean. No solo comprende la lógica del código, sino también cómo fluye la corriente eléctrica en la oblea de silicio. En la escuela secundaria, Dean comenzó a escribir un programa de recopilación de datos llamado Epi Info para epidemiólogos. Este programa se convirtió en una herramienta estándar en el sector, llegando a distribuirse finalmente en cientos de miles de copias y admitiendo más de una docena de idiomas. Un sitio web llamado "The Story of Epi Info", mantenido por los Centros para el Control y la Prevención de Enfermedades de EE. UU., aún conserva una foto de Jeff cuando se graduó de la escuela secundaria. Pero nunca mencionó este logro por iniciativa propia. Años más tarde, su esposa Heidi comprendió la importancia del programa. "Él nunca presume de esas cosas", dijo ella. "Hay que sacárselo a la fuerza". En la Universidad de Minnesota, Dean optó por una doble titulación en Ciencias de la Computación y Economía. Esta combinación aparentemente inusual revela en realidad las dos dimensiones de su pensamiento: la búsqueda de la excelencia tecnológica al tiempo que se centra en la eficiencia de los recursos. Conoció a Heidi en la universidad. Su primera cita fue para ir a ver un partido de baloncesto femenino. Jeff iba disfrazado de mascota de ardilla y animaba. En 1990, completó su tesis de licenciatura sobre redes neuronales. Este detalle pudo haber parecido insignificante en su momento, pero mirando hacia atrás veinte años después, parece ser un presagio del destino. En aquel momento, la investigación sobre redes neuronales se encontraba en la fase final del "invierno de la IA", y la comunidad académica era en general pesimista sobre sus perspectivas. Pero el joven Dean ya estaba explorando los secretos de cómo las máquinas "aprenden" a través de los datos. Tras graduarse, Dean tomó una decisión inusual: en lugar de ir directamente a una empresa tecnológica, se fue a Ginebra a trabajar para el Programa Mundial contra el SIDA de la Organización Mundial de la Salud. Allí desarrolló software de modelado estadístico para epidemias, utilizando código para ayudar a los humanos a comprender y combatir la propagación de enfermedades mortales. Esta experiencia moldeó su comprensión inicial de la "escala", no la escala de los clústeres de servidores, sino la escala de una crisis mundial de salud pública. Cuando tu software necesita procesar datos que involucran millones de vidas, el "fallo" ya no es un término técnico abstracto, sino una verdadera tragedia humana. ## Acto uno: El nacimiento del constructor de sistemas ### Aprendizaje: La magia del compilador En 1996, Dean recibió su doctorado en Ciencias de la Computación de la Universidad de Washington. Su investigación doctoral se centró en los compiladores. Software que traduce el código escrito por humanos en instrucciones de lenguaje máquina optimizadas para que las computadoras las ejecuten. "En términos de atractivo, los compiladores son casi las cosas más aburridas." Su posterior representante, Alan Eustace, dijo. Por otro lado, te acercan "mucho a la máquina". Un compilador actúa como traductor entre programadores y máquinas, y quienes optimizan compiladores deben dominar tanto el pensamiento humano abstracto como las limitaciones físicas de los chips de silicio. Esta "capacidad bilingüe" se convertirá en una ventaja competitiva fundamental para la carrera de Dean. Cuando Sanjay describió más tarde a Jeff, hizo un círculo con el dedo índice cerca de su sien. "Mientras tú escribes código, él tiene un modelo funcionando en su mente", dijo. "¿Cuál será el rendimiento de este código?" Casi automáticamente consideró todos los casos extremos. Tras doctorarse, se unió al legendario Laboratorio de Investigación Occidental de DEC (posteriormente adquirido por Compaq). Allí trabajó con un grupo de ingenieros de primer nivel, centrándose en herramientas analíticas, arquitectura de microprocesadores y recuperación de información. Estos tres años de experiencia sentaron una base sólida para su posterior trabajo en Google: Las herramientas de análisis le enseñaron a comprender los cuellos de botella del sistema, la arquitectura de microprocesadores le proporcionó un profundo conocimiento de la esencia del hardware, y la recuperación de información es el problema central de los motores de búsqueda. Jeff distribuyó en una ocasión una lista titulada "Números de latencia que todo programador debería conocer". De hecho, esta es una lista de números que casi ningún programador conoce: **Las referencias a la caché L1 suelen tardar medio nanosegundo, mientras que la lectura secuencial de un megabyte de la memoria tarda 250 microsegundos.** Esos números están profundamente grabados en su mente. ### Sanjay: La otra mitad del cerebro En diciembre, Dean conoció a Sanjay Ghemawat. Sanjay nació en West Lafayette, Indiana, en 1966, pero creció en Kota, una ciudad industrial del norte de la India. Su padre, Mahipal, era profesor de botánica. Su madre, Shanta, cuidaba de Sanjay y de sus dos hermanos mayores. El hermano de Sanjay, Pankai, fue el profesor más joven en la historia de la Escuela de Negocios de Harvard en obtener la titularidad. (Actualmente es profesor en la Escuela de Negocios Stern de la Universidad de Nueva York). Pankai y Sanjay asistieron a la misma escuela y eran conocidos por su erudición. "Vivo un poco a la sombra de mi hermano", dijo Sanjay. Incluso en su edad adulta, conservó una gran capacidad de autohumillación. Cuando fue aceptado en la Academia Estadounidense de Artes y Ciencias en 2016, no se lo contó a sus padres; fueron sus vecinos quienes se lo dijeron. Sanjay no tuvo contacto con las computadoras hasta que cumplió diecisiete años y fue a la Universidad de Cornell. Durante su etapa como estudiante de posgrado en el MIT, su asesora fue Barbara Liskov, una influyente científica informática cuyas áreas de investigación incluían la gestión de bases de código complejas. En su opinión, el mejor código es como un buen artículo. Requiere una estructura bien pensada, donde cada palabra debe desempeñar un papel. Programar de esta manera requiere empatía con el lector. Esto también significa ver el código no solo como un medio para un fin, sino como una obra de arte en sí misma. "Creo que su mayor fortaleza es el diseño de sistemas", dijo Craig Silverstein, el primer empleado de Google. "Si uno simplemente observa un archivo de código escrito por Sanjay, su belleza es como la de una escultura bien proporcionada." En DEC, Jeff caminaba dos cuadras desde su laboratorio de investigación hasta el laboratorio de Sanjay. "Había una heladería italiana en el centro", recordó Jeff. Sanjay exclamó emocionado: "¡Así que es por culpa de esa heladería!" Comenzaron a programar juntos; en lugar de trabajar en sus propios ordenadores, compartían uno, de manera que una persona manejaba el teclado y la otra la guiaba y corregía. Este tipo de colaboración no es común en el desarrollo de software. En su libro de 2001, *Círculos de colaboración: La dinámica de las amistades y el trabajo creativo*, el sociólogo Michael P. Farrell señala que: "La mayoría de las ideas incipientes que forman la base de nuevas perspectivas no surgen cuando todo el grupo se reúne, ni cuando los miembros trabajan solos, sino cuando colaboran en parejas y responden unos a otros." Fue Monet y Renoir trabajando codo a codo en el verano de 1869 quienes desarrollaron el estilo que más tarde se convertiría en Impresionismo. Durante los seis años de colaboración que dieron origen al cubismo, Picasso y Braque a menudo firmaban solo la parte posterior del lienzo para ocultar qué pintura había sido realizada por cada uno. "No sé por qué no lo hace más gente", dijo Sanjay, refiriéndose a la programación con socios. "Necesitas encontrar a alguien cuya forma de pensar sea compatible con la tuya para hacer programación en pareja, de manera que ambos puedan complementarse", dijo Jeff. A mediados de 1999, la burbuja de las puntocom estaba cerca de su punto máximo. Jeff dejó DEC y se unió a una pequeña empresa llamada "Google". En aquel momento, Google solo tenía unas pocas docenas de empleados y sus oficinas estaban ubicadas en un edificio discreto en Mountain View, California. Diez meses después, Sanjay le siguió. Su legendaria colaboración está a punto de cambiar la historia de internet. ### Marzo de 2000: Desastre y renacimiento Un día de marzo de 2000, seis de los mejores ingenieros de Google se reunieron en una sala de guerra improvisada. La empresa se enfrenta a una emergencia sin precedentes. En octubre del año pasado, su sistema central —el sistema responsable de rastrear páginas web para crear un "índice"— dejó de funcionar. Aunque los usuarios todavía pueden introducir consultas en https://t.co/cHDYnkjtpa, obtendrán datos antiguos de hace cinco meses. Para colmo, los cofundadores de Google, Larry Page y Sergey Brin, estaban negociando un acuerdo para proporcionar soporte de motor de búsqueda a Yahoo, prometiendo ofrecer un índice diez veces mayor que el que tenía en ese momento. Si fracasan, https://t.co/cHDYnkjtpa se quedará estancado en el pasado, es probable que el acuerdo con Yahoo fracase y la empresa se enfrentará al riesgo de quedarse sin fondos y declararse en bancarrota. En una sala de conferencias cercana a las escaleras, los ingenieros colocaron los paneles de las puertas en el aserradero y configuraron sus ordenadores. Craig Silverstein, el primer empleado de Google, estaba sentado cerca de la pared del fondo. Él y un ingeniero de sistemas rumano llamado Bogdan Cocosel trabajaron durante cuatro días y cuatro noches, pero fue en vano. "Todos nuestros análisis fueron inútiles", recordó Silverstein. "Todo estaba roto y no sabíamos por qué". Silverstein apenas notó la presencia de Sanjay Gomawater a su izquierda trasera. Sanjay se había incorporado a la empresa hacía solo unos meses, procedente de DEC junto con Jeff Dean. En la sala de operaciones, Jeff deslizó su silla junto al escritorio de Sanjay, dejando un asiento vacío para sí mismo. Sanjay manejaba el teclado, mientras Jeff se inclinaba cerca de él, corrigiéndolo y guiándolo como un productor que susurra al oído de un presentador de noticias. Jeff y Sanjay comenzaron a examinar más de cerca el índice estancado. Descubrieron que faltaban algunas palabras: la búsqueda de "buzón" no arrojaba resultados, mientras que otras palabras estaban desordenadas. Durante días, habían estado buscando fallos en el código, sumergiéndose en su lógica. Tras revisar cada sección, todo parecía estar bien. No pudieron encontrar el error. En su quinto día en la sala de operaciones, Jeff y Sanjay comenzaron a sospechar que el problema que buscaban no era lógico, sino físico. Convirtieron el desordenado archivo de índice a su representación más primitiva: **código binario.** Querían ver lo que veía su máquina. En el monitor de Sanjay apareció una densa columna de 1 y 0, cada fila representando un término de índice. Sanjay señaló un número que debería haber sido 0 pero se había convertido en 1. Cuando Jeff y Sanjay juntaron todas las palabras desordenadas, vieron un patrón: cada palabra tenía los mismos pequeños fallos. Por alguna razón, el chip de memoria de su máquina estaba dañado. Sanjay miró a Jeff. Google ha experimentado un número creciente de fallos de hardware en los últimos meses. El problema es que, a medida que Google crece, su infraestructura informática también se expande. El hardware informático rara vez falla a menos que tengas demasiado, en cuyo caso fallará con frecuencia. Cables desgastados, fallo del disco duro, sobrecalentamiento de la placa base. Muchas máquinas no funcionan desde el principio; algunas se ralentizan inexplicablemente. Extraños factores ambientales también comenzaron a surtir efecto. Cuando explota una supernova, la onda expansiva produce partículas de alta energía que se dispersan en todas direcciones; los científicos creen que estas partículas dispersas, conocidas como rayos cósmicos, tienen una probabilidad muy pequeña de impactar contra chips de computadora en la Tierra y cambiar los 0 por 1. Los sistemas informáticos más robustos del mundo, como los utilizados por la NASA y las empresas financieras, utilizan hardware especial que puede tolerar cambios de bits. Pero Google, en aquel momento, todavía funcionaba como una empresa emergente, comprando ordenadores baratos que carecían de esa función. En un edificio de Santa Clara, California, Google apiló 1.500 placas base y discos duros desnudos como si fueran sándwiches en una torre de seis pies de altura. Debido a una falla de hardware, solo 1200 unidades están operativas. La empresa ha llegado a un punto de inflexión. Sus clústeres informáticos se han vuelto tan grandes que incluso las raras fallas de hardware se han vuelto inevitables. Jeff y Sanjay escribieron código juntos para compensar el mal funcionamiento de las máquinas. Poco después, se completó el nuevo índice y se disolvió la sala de operaciones. ### Reescritura de fin de semana: El nacimiento de los sistemas elásticos Esta crisis se convirtió en un punto de inflexión. Jeff y Sanjay se dieron cuenta de que, a medida que Google creciera, los fallos de hardware no serían accidentales, sino la norma. Cuando se tienen miles o decenas de miles de servidores, se producirán fallos en las máquinas, averías en los discos duros e interrupciones de la red a diario. Si el sistema no puede gestionar estos fallos, Google no podrá escalar. Necesitan construir una infraestructura completamente nueva: **un sistema capaz de mantener el orden en medio del caos.** La filosofía de diseño central detrás de la reescritura de este fin de semana es **esperar el fracaso**. En lugar de asumir que el hardware es perfecto, es mejor asumir que *fallará*. El sistema debe ser capaz de detectar automáticamente los datos corruptos, identificar las máquinas defectuosas y permitirles seguir funcionando sin interrupciones. Esta idea de "tolerancia a fallos" es de sentido común en los sistemas distribuidos hoy en día, pero era radical en el año 2000. Antes del desplome del índice en marzo, el sistema de Google se basaba en código escrito por sus fundadores cuando eran estudiantes de posgrado en la Universidad de Stanford. Page y Brin no son ingenieros de software profesionales. Son académicos que están realizando experimentos sobre tecnología de búsqueda. Cuando su rastreador web falló, no hubo ningún mensaje de diagnóstico que proporcionara información alguna, solo la frase "¡Guau, caballito!". Los primeros empleados se referían a un programa informático llamado BigFiles, escrito por Page y Brin, como BugFiles (archivos llenos de errores). Su crucial código de indexación tarda días en completarse, y si surgen problemas, tienen que empezar desde cero. En la jerga de Silicon Valley, Google carecía por aquel entonces de "escalabilidad". Wayne Rosing trabajó anteriormente en Apple en el precursor del ordenador Macintosh antes de unirse a Google en noviembre de 2000 para dirigir su equipo de 100 ingenieros. "Ellos son los líderes", dijo. Jeff y Sanjay trabajaron juntos para reconstruir la infraestructura de Google. Trabajan 90 horas semanales escribiendo código para que un fallo en un solo disco duro no provoque el colapso de todo el sistema. Añadieron puntos de control durante el proceso de rastreo para que pudiera reiniciarse a mitad de camino. Mediante el desarrollo de nuevos esquemas de codificación y compresión, lograron duplicar efectivamente la capacidad del sistema. Son optimizadores implacables. Cuando un coche gira, las ruedas exteriores deben cubrir una mayor superficie de terreno. De igual modo, el borde exterior de un disco duro giratorio se mueve más rápido que el borde interior. Google ha trasladado los datos a los que se accede con mayor frecuencia al exterior para que los bits de datos puedan fluir más rápido bajo el cabezal de lectura/escritura, pero el interior está medio vacío; Jeff y Sanjay utilizaban este espacio para almacenar datos preprocesados para consultas de búsqueda comunes. En cuatro días de 2001, demostraron que el índice de Google podía almacenarse utilizando una memoria de acceso aleatorio (RAM) rápida en lugar del disco duro, relativamente lento. Este descubrimiento transformó el modelo económico de la empresa. Page y Brin sabían que los usuarios acudirían en masa a los servicios que pudieran proporcionar respuestas instantáneas. El problema es que la velocidad requiere potencia de cálculo, y la potencia de cálculo cuesta dinero. Jeff y Sanjay resolvieron ingeniosamente el problema utilizando software. Alan Eustace se convirtió en jefe del equipo de ingeniería después de que Rossin se marchara en 2005. "Para resolver el problema de la escala, paradójicamente, hay que comprender los detalles más pequeños", dijo Eustace. Jeff y Sanjay entienden las computadoras a nivel de bits. Durante las diversas reescrituras del software central de Google que ayudaron a liderar, la capacidad del sistema se expandió exponencialmente. Mientras tanto, en el enorme centro de datos de la compañía, los técnicos ahora recorren rutas serpenteantes, siguiendo instrucciones generadas por software para reemplazar discos duros, fuentes de alimentación y módulos de memoria. Aunque sus componentes se desgasten y fallen, el sistema puede seguir funcionando con normalidad. ### MapReduce: Simplificando el caos En 2004, Dean y Gemmawater publicaron un artículo titulado "MapReduce: Procesamiento de datos simplificado en grandes clústeres". Este artículo tiene solo dos autores, pero cambiará toda la industria. La idea central de MapReduce es extremadamente simple: **abstrae la computación distribuida compleja en dos funciones: `Map` y `Reduce`.** La función `Map` procesa los datos de entrada y genera pares clave-valor intermedios. La función `Reduce` agrupa los valores con la misma clave para generar el resultado final. Los programadores solo necesitan definir estas dos funciones, y el sistema se encargará automáticamente de la paralelización, la planificación de tareas, la comunicación entre máquinas y la recuperación ante fallos. El poder de esta abstracción reside en su **simplicidad**. Antes de MapReduce, escribir programas distribuidos requería un profundo conocimiento de los sistemas: era necesario gestionar manualmente los hilos, manejar la comunicación de red y lidiar con fallos de la máquina. Estas complejidades alejan a la mayoría de los programadores. Sin embargo, MapReduce oculta estas complejidades dentro del sistema, lo que permite a los ingenieros sin experiencia en sistemas distribuidos manejar fácilmente terabytes de datos. Un ejemplo que se incluye en el artículo es el recuento de las apariciones de cada palabra en un gran número de documentos. La función `Map` lee un documento y genera pares clave-valor de `(palabra, 1)`. La función `Reduce` suma las repeticiones de las mismas palabras. El programa completo requiere tan solo unas pocas líneas de código, pero puede ejecutarse en paralelo en miles de máquinas, procesando páginas web a través de toda la Internet. Otra contribución clave de MapReduce es la **tolerancia a fallos**. El sistema supervisará continuamente la ejecución de la tarea y, si falla en una máquina, la volverá a ejecutar automáticamente en otra. Esta estrategia de "re-ejecución" funciona porque las funciones `Map` y `Reduce` están diseñadas para ser "funcionales": no modifican los datos de entrada, solo producen la salida. Esto significa que volver a ejecutar una tarea no producirá efectos secundarios y el resultado es determinista. Este diseño está directamente inspirado en las lecciones de la "crisis del 2000": el hardware puede fallar, pero el sistema debe seguir funcionando. MapReduce rápidamente ganó popularidad dentro de Google. Se utiliza para crear índices de búsqueda, procesar datos de registro, generar informes y entrenar modelos de aprendizaje automático. Para cuando se publicó el artículo en 2004, cientos de programas MapReduce ya se estaban ejecutando dentro de Google. Y lo que es más importante, las ideas detrás de MapReduce se extendieron por toda la industria. Basándose en este artículo, Yahoo desarrolló Hadoop, una implementación de código abierto de MapReduce, que se convirtió en la piedra angular de la era del big data. ### Bigtable: El arte del almacenamiento Si MapReduce resuelve el problema del cálculo a gran escala, Bigtable resuelve el problema del almacenamiento a gran escala. En 2006, Dean y Gemmawater, junto con otros ingenieros de Google, publicaron "Bigtable: Un sistema de almacenamiento distribuido para datos estructurados". Bigtable está diseñado para gestionar petabytes de datos estructurados, a la vez que admite el procesamiento por lotes de alto rendimiento y las consultas en tiempo real de baja latencia. Esto plantea un requisito aparentemente contradictorio: **el procesamiento por lotes necesita analizar grandes cantidades de datos, mientras que las consultas en tiempo real necesitan devolver rápidamente un único resultado.** Las bases de datos relacionales tradicionales no pueden cumplir ambos requisitos al mismo tiempo. La solución de Bigtable es un modelo de datos único: se trata de un "mapa ordenado multidimensional, disperso, distribuido y persistente". Cada elemento de datos está indexado por tres dimensiones: clave de fila, clave de columna y marca de tiempo. Este diseño ofrece una gran flexibilidad: - **Clave de fila**: Los datos se almacenan ordenados por clave de fila, y las claves de fila adyacentes se almacenan en la misma máquina. Esto hace que el escaneo de un rango de datos sea muy eficiente. **Familias de columnas**: Las columnas se organizan en familias, y cada familia puede tener sus propias políticas de control de acceso y compresión. Esto permite al sistema optimizar el almacenamiento según los diferentes patrones de acceso. **Marca de tiempo**: Cada elemento de datos puede tener varias versiones, diferenciadas por una marca de tiempo. El sistema puede conservar automáticamente las N versiones más recientes o la versión de los últimos T días; las versiones anteriores se eliminarán. Otra característica clave del diseño de Bigtable es que *no* es una base de datos relacional. No admite consultas SQL complejas ni transacciones entre filas. Estas limitaciones son intencionales; permiten que el sistema se escale horizontalmente a través de miles de máquinas sin verse obstaculizado por protocolos de consistencia complejos. Dentro de Google, Bigtable se utiliza para almacenar índices de páginas web, datos geográficos de Google Earth, datos de comportamiento del usuario de Google Analytics y más. Su influencia también se ha extendido a toda la industria: DynamoDB de Amazon, Cassandra de Facebook y HBase de Apache se han inspirado en Bigtable. ### Llave inglesa: La cúspide de la coherencia global MapReduce y Bigtable sentaron las bases de la infraestructura de Google, pero ambos comparten una limitación común: fueron diseñados principalmente para su uso en un único centro de datos. A medida que Google se expande globalmente, los datos deben distribuirse por todos los continentes. Mantener la coherencia de los datos a nivel mundial se ha convertido en el próximo desafío. En 2012, Dean y Gemmawater, junto con otros ingenieros, publicaron "Spanner: la base de datos distribuida globalmente de Google". Spanner es la primera base de datos distribuida globalmente del mundo que admite "transacciones distribuidas con coherencia externa". La principal innovación de Spanner es la **API TrueTime**. En los sistemas distribuidos, el tiempo es un tema complicado. Los relojes de diferentes máquinas pueden estar desincronizados, y la latencia de la red significa que no se puede estar seguro del orden real de dos eventos. La solución de Spanner consiste en aprovechar el GPS y los relojes atómicos para construir una API que pueda *exponer las incertidumbres del reloj*. TrueTime no te dirá "Son las 12:00:00 ahora", sino "Son las 12:00:00 ahora, con un margen de error de ±7 milisegundos". Al conocer con precisión esta incertidumbre, Spanner puede asignar marcas de tiempo de confirmación significativas a las transacciones globales. Si la incertidumbre es demasiado grande, el sistema esperará proactivamente a que pase la incertidumbre; esto se denomina "espera de compromiso". Esta espera normalmente solo toma unos pocos milisegundos, pero garantiza la consistencia externa de la transacción: si la transacción T1 se confirma antes que la transacción T2, entonces la marca de tiempo de T1 debe ser anterior a la marca de tiempo de T2. La creación de Spanner marcó la finalización de la "Trilogía de Sistemas" de Dean. De MapReduce (computación tolerante a fallos) a Bigtable (almacenamiento tolerante a fallos), y luego a Spanner (consistencia global). Estos tres sistemas, en conjunto, forman la ventaja tecnológica de Google. No solo respaldaron los negocios principales de Google, como las búsquedas, la publicidad y Gmail, sino que también proporcionaron la infraestructura para la posterior ola de inteligencia artificial. En 2025, Spanner recibió el premio ACM SIGMOD System Award por "reimaginar la gestión de datos relacionales para lograr la serialización con coherencia externa a escala global". Este es el último reconocimiento al trabajo que Dean y Gemmawater realizaron hace más de una década. ### Efectos de cola de la escala: La cúspide de la filosofía de sistemas En 2013, Dean y Gemmawater publicaron otro artículo influyente: "La cola a escala". Este artículo explora un problema que es frecuente en los sistemas a gran escala pero que a menudo se pasa por alto: la **latencia de cola**. En el sistema de Google, una sola solicitud de usuario puede requerir el acceso a cientos de servidores. Aunque el tiempo de respuesta promedio de cada servidor sea rápido, si tan solo el 1% de los servidores son lentos (por ejemplo, debido a la recolección de basura, la E/S de disco o la congestión de la red), se ralentizarán la mayoría de las solicitudes de los usuarios. Esto se debe a que las solicitudes de los usuarios deben esperar respuestas de *todos* los servidores, y el servidor más lento determina la latencia general. La profunda conclusión del artículo es que intentar eliminar todas las fuentes de retraso es “poco realista”. El hardware fallará, las redes se congestionarán y los sistemas operativos sufrirán problemas. En lugar de buscar la perfección, es mejor construir un sistema tolerante a fallos puntuales, un concepto que recuerda a su filosofía posterior a la crisis del 2000 de construir sistemas tolerantes a fallos. El artículo propone una serie de técnicas para abordar la latencia de cola: - **Solicitud de cobertura**: Enviar la misma solicitud a múltiples réplicas y utilizar la respuesta más rápida. - **Solicitud de enlace**: Envía una solicitud a varias réplicas, pero cancela las solicitudes a otras réplicas una vez que una réplica ha comenzado a procesarlas. - **Microparticionamiento**: Divide los datos en particiones más pequeñas, lo que permite migrar la carga de trabajo de forma más flexible entre máquinas. - **Replicación selectiva**: Cree más réplicas para los datos a los que se accede con frecuencia para distribuir la carga. La idea principal detrás de estas tecnologías es construir servicios elásticos y de alto rendimiento en hardware poco fiable y con velocidades desiguales mediante redundancia y programación inteligente. En 2025, "The Tail at Scale" recibió el premio ACM SIGOPS Hall of Fame, en reconocimiento a su "resistencia al paso del tiempo". Este artículo no solo influyó en el diseño del sistema de Google, sino que también se convirtió en un documento clásico en toda la industria. ### Dean y Gemmawater: Una colaboración legendaria Al contar la historia de Dean, es imposible no mencionar su colaboración con Sanjay Gormwalt. Son los *únicos* dos autores del artículo sobre MapReduce, los diseñadores principales de Bigtable y Spanner, y coautores de "The Tail at Scale". Comenzaron a colaborar en DEC, superaron juntos la "crisis del 2000" en Google y trabajaron juntos para construir la base tecnológica de Google durante las dos décadas siguientes. En 2012, recibieron conjuntamente el premio ACM Computing Award en reconocimiento a su "concepción, diseño e implementación de la revolucionaria infraestructura de software de Google". En 2009, ambos fueron elegidos miembros de la Academia Nacional de Ingeniería. Su colaboración ha sido descrita como "la amistad que salvó a Google e inventó el internet moderno". Pero esta colaboración también ha dado lugar a un interesante fenómeno cultural: los "Datos sobre Jeff Dean". ### "Meme de Jeff Dean": Admiración y arrepentimiento Alrededor del Día de los Inocentes de 2007, comenzó a circular internamente en Google una serie de chistes sobre Jeff Dean, imitando el "chiste de Chuck Norris". Estos chistes exageraban las habilidades técnicas de Dean, por ejemplo: —Jeff Dean escribió directamente el código binario; el código fuente era solo documentación para que otros la leyeran. —El teclado de Jeff Dean no tiene tecla Ctrl, porque él siempre tiene el control. —El compilador no le avisará a Jeff Dean. Jeff Dean le avisará al compilador. "La velocidad de la luz en el vacío solía ser muy lenta, pero Jeff Dean optimizó la física en un fin de semana." Estos memes se propagaron rápidamente dentro de Google y posteriormente permearon toda la industria tecnológica. Esto refleja la admiración de los ingenieros por Dean: no solo era un experto técnico excepcional, sino también un "dios de la programación" capaz de resolver cualquier problema. Pero estos memes también presentan un problema: dan la impresión de que "Jeff es mejor que Sanjay". De hecho, las contribuciones de Dean y Gemmawater fueron iguales, y su colaboración, complementaria. Según se informa, el creador del meme expresó posteriormente su arrepentimiento, creyendo que "la única razón era que el nombre 'Jeff' parecía 'más interesante'". Este detalle revela la brecha entre la percepción pública y la historia verdadera. La leyenda de Dean no es un logro individual, sino una colaboración que ha perdurado por más de 20 años.
Cargando el detalle del hilo
Obteniendo los tweets originales de X para ofrecer una lectura limpia.
Esto suele tardar solo unos segundos.