/* PERSONALIZACION DE LUIS

5/8/06

Google por dentro

Google es una compañía que me tiene fascinado hace tiempo (1, 2, 3 y 4) .

Ya no es sólo su modelo (?) de negocio (sorprende que pueda ser rentable, ¿no?) sino también, y sobre todo, por su capacidad increible de crear nuevos productos y lanzarlos exitosamente.

Detrás de esa maquinaria parece ser que hay una tecnología, dicen que prodigiosa, soportada por una infraestructura colosal pero de la que Google ha revelado muy poco.

He leído un documento firmado por David F. Carr (a este Carr no lo conocía antes) donde, basándose en fuentes diversas (algunas de Google pero no todas), ha recopilado una serie de datos sobre esta misteriosa infraestructura que me parecen muy interesantes, no sólo desde el punto de vista técnico sino también porque se vislumbran los atípicos criterios que dirigen su estrategia.

El documento se puede encontrar aquí y recomiendo su lectura, aunque para los que no tengan el ánimo suficiente he preparado un picoteo de los puntos más interesantes.

Como ideas para recordar me quedaría con:

  • Google tiene una capacidad de proceso sin parangón conseguida mediante un enfoque diferencial de como deben ser sus procesos y sistemas de información.
  • La infraestructura de IT se considera un componente estratégico de la compañía.
  • Todo en esta vida es imperfecto. Es mejor gestionar la imperfección que pretender que todo sea perfecto.

Algunos ejemplos para ilustar estas ideas:

  • Google, según ciertas estimaciones, corre sobre 450.000 (!) "servidores" agrupados en miles de clusters en docenas de centros distribuidos en Dublín, Virginia y California. Recientemente ha adquirido un nuevo centro en Atlanta y está construyendo uno nuevo en Dallas del tamaño de dos campos de futbol (americano supongo). Esta inmensa granja de servidores está formada por elementos de bajo coste (PCs de gama baja) corriendo en un linux tuneado, con lo que disponen de escalabilidad ilimitada y lineal. El concepto de grid computing llevado al extremo.
  • Este hecho se menciona como un elemento crucial en el despegue de la compañía ya que le permitió crecer con poca inversión en infraestructura (otras puntocom empezaron con costosísimos servidores a prueba de fallos, algunas no llegaron ni a amortizar el primer año). Alguien ha llegado a decir que Google tiene una ventaja competitiva en costes de 1 a 3 con su competencia (a mí me parece exagerado este ratio).
  • Como anécdota, se menciona que el principal problema que tienen es poder refrigerar esa inmensa fuente de calor (se dice que han optado por procesadores AMD en lugar de Intel por eso).
  • Google compra, no alquila, hardware. El CFO dice que "creemos que tenemos una ventaja competitiva por construir y poseer nuestra propia infraestructura"

  • Google ha desarrollado la capacidad de desplegar rápidamente centros de datos "empaquetados" en armarios (racks) estándares de 20 o 30 pies, es decir tienen una movilidad muy valiosa tácticamente, que les permite poner un centro de datos, donde haya acceso a fibra, de un día para otro.

  • Todo el diseño de la infraestructura está regido por el principio de que cualquier componente fallará en algún momento. Si a este hecho se añade el que todo el hardware es de gama baja, se necesita que el sistema deba ser tolerante a fallos continuos, lo que consiguen a base de redundancia y sistemas de corrección automática de errores (que han sido desarrollados por Google y constituyen uno de sus secretos tecnológicos mejor guardados)
  • Si hace falta se reinventa la rueda, o mejor dicho, se inventan un tipo de ruedas que no tiene nadie. A quien se le ocurre en estos tiempos construir de cero un sistema de gestión de ficheros (el Google File System), un sistema de gestión de base de datos (Google Big Table), un sistema de gestión de trabajos en batch (global work queue), para correr procesos distribuidos en paralelo (Map/Reduce Framework) ... ¡pues a Google!
  • No me extenderé aquí pero los detalles técnicos, para los que nos gustan ese tipo de detalles, son impresionantes - es como replantearse todos los fundamentos de diseño de software. Cuando alguien lanza una búsqueda en Google desencadena una serie de acciones en su sistema que impresiona. Tampoco voy a entrar en detalles aquí, pero cuando lo lees acabas creyendo oir el silbido de los chorros de bits circulando a toda pastilla.


Pero no todo es tan estupendo:


  • Hay dudas sobre el coste de mantenimiento de todo esta parafernalia de cientos de miles de PCs funcionando de forma distribuida por el planeta
  • Yahoo y Microsoft , más o menos usando los mismos argumentos, dicen que ese modelo sólo es aplicable a un negocio de operaciones muy uniformes y repetitivas. Ellos tienen más variedad y por tanto ese modelo es parcialmente válido - sólo en sus lineas equivalentes (buscadores). Me sale la duda ahora de si para el resto de servicios que ofrece Google (blogspot, gmail, calendar, etc.) también usan ese modelo de infraestructura.
  • El modelo no es adecuado a sistemas de negocio que no admiten errores, de hecho su ERP es Oracle Financials. En el resultado de una búsqueda no pasa nada (ni siquiera lo notas) si el resultado que debía salir en 5º lugar en realidad debería salir el 8º. Si introduces un asiento contable no hay margen para un error de ese calibre.

Para los que quieran más, hay otro artículo que describe también las interioridades de la tecnología de Google. Se puede encontrar aquí.

Para los que se han aburrido y no se quieren ir con mal sabor de boca, visiten el hermano especular de Google: elgooG


2 comentarios:

Anónimo dijo...

Impresionante post. Me encanta lo del diseño basado en que "todo fallará en algún momento", pero todo es para leerlo despacio y aprender. Lo que en las escuelas de negocio llaman "alinear IT con la estrategia del negocio".

El viernes nuestro director financiero afirmaba la imposibilidad de que Google fuera un negocio rentable. Mañana le envío el link.

Anónimo dijo...

Siempre que se habla del caso Google me planteo si debe ser un caso único. Sería rentable Google si fuera el buscador número 2? Difícilmente...

Por otro lado, de momento sólo se está aprovechando una de las ventajas más básicas de Grid Computing, como es la potencia de cálculo. En un futuro veremos grandes cosas al respecto no tanto de esta tecnología, sino del jugo que se le podrá sacar.