A medida que los grandes sistemas de TI escalan sus sistemas a niveles nunca antes vistos de complejidad, entran en juego nuevas leyes de administración efectiva

Los gigantes de Internet como Google y Amazon ejecutan operaciones de TI muchísimo más grandes de lo que la mayoría de empresas sueñan con realizar, y las lecciones que aprenden de la gestión o administración de esos enormes sistemas pueden beneficiar a otros en la industria.

En algunas conferencias realizadas en las últimas semanas, ingenieros de Google y Amazon revelaron algunos de los secretos que usan para modificar la escala de sus sistemas, pero con el nivel más bajo posible de complicaciones.

En la conferencia de Usenix LISA (Large Installation Systems Administration) en Washington, el ingeniero de confiabilidad de sitios de Google, Todd Underwood, destacó uno de los imperativos de la compañía que puede ser sorprendente: la frugalidad.

“Mucho de lo que Google hace tiene que ver con ser súper barato”, señaló ante una audiencia de administradores de sistemas.

Google se ve obligado a controlar de forma maniática los costos porque ha aprendido que “todo lo que escala con la demanda se convierte en un desastre si no es barato”.

Cada vez que un servicio se hace más popular, los costos deben crecer de una manera “sublineal”, añadió.

“Si agregas un millón de usuarios, tienes que agregar menos de mil ‘cantidades’ de cualquier gasto en el que se esté incurriendo”, anotó Underwood. Una ‘cantidad’ de gasto puede ser el tiempo de las personas o los recursos informáticos.

Esa lógica es la que se encuentra detrás de los esfuerzos de Google para no comprar equipos de enrutamiento de compañías como Cisco o Juniper. Google necesitará tantos puertos que es mejor, en términos de dinero, que ellos los construyan, añadió Underwood.

El ejecutivo refutó la idea de que los retos que Google enfrenta son únicos para una empresa de su tamaño. Por ejemplo, la compañía está compuesta por servicios mucho más pequeños como Gmail y Google+.

“La escala de todo Google no es el tema con el que la mayoría de desarrolladores de aplicaciones dentro de Google se enfrentan. Ellos ejecutan cosas que son comprensibles para todos y cada uno de ustedes”, señaló a la audiencia.

Otra técnica que Google usa es automatizar todo lo posible. “Estamos haciendo mucho del trabajo que deberían hacer las máquinas”, anotó.

Lo ideal sería que una organización se deshaga por completo de su administración del sistema, y solo construya e innove sobre los servicios ofrecidos por otros, añadió Underwood, aunque admitió que eso aún no es factible.

Underwood, quien tiene un gusto por lo dramático, declaró: “Creo que la administración de los sistemas ha llegado a su fin, y creo que deberíamos dejar de hacerlo. Fue una mala idea que fue necesaria por mucho tiempo, pero creo que se ha convertido en una muleta”.

El competidor más fuerte de Google no es ni Bing ni Apple ni Facebook. Es Google mismo, indicó Underwood. Los ingenieros de la compañía apuntan a que sus productos sean lo más confiables posible, pero esa no es su única tarea. Si un producto es muy confiable -es decir, más allá de los cinco nueves de confiabilidad (99,999%)- entonces ese servicio está perdiendo dinero ante los ojos de la compañía.

 “El punto no es alcanzar el 100% de disponibilidad. El punto es alcanzar la disponibilidad de tu target -99,999%- mientras se mueve tan rápido como pueda. Si cruzas masivamente ese umbral estás perdiendo dinero”, agregó Underwood.

“El costo de oportunidad es nuestro más grande competidor”, indicó.

Los trucos de Amazon

A la semana siguiente en la conferencia re:Invent de Amazon Web Services (AWS) en Las Vegas, se dio una exposición a cargo de James Hamilton, vicepresidente e ingeniero distinguido de AWS. Entonces, se discutió sobre los trucos que usa Amazon para escalar sus sistemas.

Aunque Amazon es selectiva con los números que comparte, se puede decir que AWS está creciendo a un ritmo prodigioso. Todos los días agrega una cantidad de recursos informáticos (servidores, routers y dispositivos para centros de datos) que es equivalente a lo que tenía en total en el año 2000, señaló Hamilton. “Éste es un tipo de escala diferente”, agregó.

Un aspecto clave para AWS, empresa que fue lanzada en el 2006, fue contar con un buen diseño arquitectónico. Hamilton admitió que Amazon tuvo suerte al tener la arquitectura correcta desde el inicio.

“Cuando uno tiene un crecimiento rápido, aprende sobre arquitectura. Si hay errores arquitectónicos o errores en la aplicación, y los clientes deciden utilizarlos en gran medida, habrá muchas caídas y muchos problemas”, señaló Hamilton.

El costo de desplegar un servicio en AWS se reduce a la creación y a la implementación de la infraestructura, explicó Hamilton. Para la mayoría de organizaciones, la infraestructura de TI es un gasto, no el núcleo de su negocio. Pero en AWS, los ingenieros se enfocan únicamente en reducir los costos de la infraestructura.

Como Google, Amazon a menudo construye su propio equipo, como los servidores. Esto no es algo práctico para las empresas, reconoció, pero funciona para una operación tan grande como la de AWS.

“Si tienes decenas de miles de servidores haciendo exactamente lo mismo, sería un robo a los clientes no optimizar el hardware”, señaló Hamilton. También anotó que los servidores que se venden a través del canal de hardware regular de TI, a menudo cuestan alrededor de 30% más que comprar los componentes individualmente a los fabricantes.

Esto no solo permite que AWS reduzca costos para los consumidores, sino también permite que la compañía hable directamente con los fabricantes de los componentes sobre las mejoras que beneficiarían a AWS.

“Tiene sentido, económicamente hablando, operar de esta forma, y también tiene sentido desde la perspectiva de la innovación”, agregó Hamilton.

Problemas de escalabilidad

Además de la computación en la nube, otra área de TI que se ocupa de la escalabilidad es la de supercomputación, donde una sola maquina puede tener miles de nodos, cada uno con docenas de procesadores. El último día de la conferencia sobre supercomputadoras SC13, un panel de operadores y proveedores se reunieron para discutir los problemas de la escalabilidad.

William Kramer, que supervisa la máquina Blue Waters del National Center of Supercomputing Applications de la Universidad de Illinois en Urbana, Champaign, señaló que la supercomputación está experimentando un fuerte crecimiento, lo cual impulsa la necesidad de nuevas herramientas de programación de la carga de trabajo para asegurar que las organizaciones obtengan los máximos beneficios de su inversión.

“Lo que ahora está en un chip -una simple pieza de silicio- tiene el tamaño de los sistemas que estábamos tratando de programar hace 15 años”, comentó Kramer. “Hemos asumido que el sistema operativo o que el programador se encargará de toda la programación que hemos estado haciendo”.

Las viejas métricas de rendimiento de la supercomputación parecen estar deshaciéndose. Este año, Jack Dongarra, uno de los creadores del benchmark Linpack que se utiliza para comparar computadoras que están en la lista SC500, pidió indicadores o métricas adicionales para poder medir mejor la eficacia de una supercomputadora.

Sin embargo, juzgar la verdadera eficiencia de un sistema puede ser un poco engañoso.

“Uno quiere medir la cantidad de trabajo que pasa por el sistema durante un periodo de tiempo”, y no solo realizar la simple medición de cuanto está siendo utilizado cada nodo, añadió Kramer.

El ejecutivo señaló que una organización puede medir la utilización de un sistema midiendo el porcentaje de tiempo que utiliza cada nodo. Pero este enfoque puede ser engañoso ya que una carga de trabajo puede ser ralentizada para incrementar la tasa de utilización, pero eso da como resultado que menos trabajo pase a través del sistema general.

John Hengeveld, director de marketing de HPC de Intel, recomendó a la comunidad de la supercomputación que observen lo que hacen los fabricantes de motores jet.

 “En Rolls Royce, ya no se compra un motor jet, se compran horas de propulsión en el aire. Ellos se aseguran de que uno tenga ese número de horas de propulsión por la cantidad de dinero que paga. Tal vez esa sea la forma en la que deberíamos estar haciendo las cosas ahora”, indicó Hengeveld. “No deberíamos estar comprando chips, deberíamos comprar resultados”.

-Joab Jackson, IDG News Service