Arquitecturas escalables en Google at Jompeich d’er Bisente

Un compañero de trabajo me manda tres interesantes artículos de la web High Scalability, que no conocía aún y que ya he añadido a mi lista de RSSs en Google Reader. Los artículos tratan sobre las decisiones de diseño y arquitectura de computadores/redes tomadas en YouTube, Google y GTalk, para hacer frente a la altísima cantidad de visitas y datos que deben servir por segundo, comentando también más o menos la estructura actual y la evolución de la infraestructura de cada uno de ellos:

Algunas conclusiones a extraer de éstos artículos:

No intentar arreglarlo todo con una única arquitectura o una única herramienta. Dividir el problema en subproblemas, ver en cada caso si el límite es CPU, ancho de banda, IO y optimizarlo. Especializar servidores para cada caso y coordinar el trabajo de cada parte.
Cachear contenido siempre que sea posible. Pregenerar contenido siempre que sea posible. Utilizar las directivas HTTP para el control de caché. Usar squid como proxy inverso para aliviar a los servidores de aplicaciones.
Plantearse externalizar algún servicio, el hosting de imágenes o videos que puedan suponer más ancho de banda del que actualmente tenemos. Aunque sea como solución de compromiso mientras se contrata más ancho de banda. Lo importante es ofrecer el servicio en condiciones.
Simplicidad, dentro de lo que cabe. Permitirá hacer cambios y evoluciones sin cagarla demasiado.
Clusters basados en PCs normales. Maximizan la relación potencia/precio. Tener montado un sistema de redundancia para que una caída no afecte al servicio, y un sistema de instalación sencillo para poder añadir/sustituir equipos sin calentarse mucho la cabeza. Y empezar a planificar los problemas de alimentación y aire acondicionado.
La programación hoy en día se basa en librerías y frameworks. No reinventar la rueda. Usar un framework común, propio o no, de forma que los programadores no tengan que hacer una y otra vez las mismas cosas y una actualización beneficie a todos nuestros productos de golpe.
Pensar en la arquitectura desde el principio. Estoy tristemente acostumbrado a que los desarrolladores no se preocupen de lo que hay por debajo de su código, ni si éste va a provocar problemas de red, disco, CPU, etc. Google enfoca todos los problemas desde la arquitectura necesaria para dar el servicio, y luego programa alrededor de ésa arquitectura. Es lo que diferencia a Google del resto.