Llegamos a ustedes gracias a:



Columnas de opinión

Los SLA de la nube: Otro punto de vista

Por: Bernard Golden, CEO de la firma de consultoría HyperStratus

[01/12/2009] Probablemente ha visto cientos, o incluso miles, de artículos criticando los Acuerdos de Nivel de Servicio (SLA, por sus siglas en inglés) de cloud computing. Un ejemplo común en esos artículos es el supuestamente laxo SLA de Amazon Web Services. Generalmente, los autores de esta clase de artículos citan las recientes caídas que han sufrido los proveedores de la nube, dando a entender (o directamente afirmando) que la cloud computing queda muy corta con respecto a los verdaderos requerimientos de los SLA de las empresas, generalmente descritos como los cinco nueves, por ejemplo, 99.999% de disponibilidad.

Lo que no se menciona en estos artículos es que se está presuponiendo que los data centers corporativos operan a tasas de disponibilidad mucho más altas que los proveedores de la nube. Francamente, estoy poco convencido de esto. Y esto lo digo porque me parece que casi todas las veces que contacto con el área de soporte de una gran empresa, el muy amable representante del call center se disculpa por las demoras causadas debido a que la computadora está corriendo lenta esta mañana. Además, mucha gente con la que converso me señala sus molestias porque su correo electrónico se cayó, etc. Así que menospreciar a los proveedores de la nube al compararlos con los de los data centers internos podría no ser exacto; sin embargo, podría darse el caso que la propia exactitud no sea algo que se pueda probar, ya que muchas empresas no miden el rendimiento de los SLA en el mundo real.
Algo más que debería señalarse es la inexistencia de los cinco nueves en el mundo real. Si uno observa la definición del Uptime Institute de los varios niveles de robustez del data center, la escala va desde el Nivel 1, con una única ruta de componentes y puntos únicos de falla, hasta el Nivel 4, con múltiples equipos de enfriamiento y rutas de energía, junto con componentes redundantes. Sin embargo, incluso el Nivel 4, consigue solo un 99.995% de disponibilidad, una cifra por debajo del estándar de los cinco nueves.
Más aún, aquí también se está comparando manzanas con naranjas. Los proveedores de la nube no solo entregan infraestructura (el dominio de las definiciones del Uptime Institute), sino que entregan también capacidad de software. En el caso de Amazon, la capacidad de software consiste en hipervisores, administración del almacenamiento y software de administración de la nube. Google y Microsoft ponen una capa adicional con la funcionalidad de plataforma sobre lo que provee Amazon.
Si uno fuera a comparar SLA de data centers internos que incorporen la capa de software y la infraestructura, uno podría arriesgarse a suponer que los proveedores de la nube empezarían a verse mucho mejor.
Sin embargo, este modo de evaluación se encuentra cada vez más obsoleto, ya que se encuentra basado en un mundo en el que pequeñas cantidades de costoso hardware corren software diseñado para servidores de recursos limitados. Ese enfoque del diseño de sistemas ya no es de vanguardia. ¿Por qué?
En Transaction Processing (Procesamiento de transacciones), libro escrito por Jim Gray y Andreas Reuter, los autores postulan que el hardware es mucho más confiable que el software; consecuentemente, la obra no le dedica espacio a las estrategias de hardware para incrementar el uptime. En lugar de eso, el libro discute cómo diseñar software para que sea seguro para las transacciones (dato: utilice una base de datos relacional que tenga registro de las transacciones). Gray y Reuter asumen un mundo de pequeñas cantidades de hardware con aplicaciones que ocupan una o algunas máquinas -pero ese enfoque está siendo dejado atrás en el mundo de hoy de grandes datos y aplicaciones masivas.
Las aplicaciones de hoy abarcan docenas, cientos o incluso a miles de máquinas. El tamaño de los data centers es asombroso. El nuevo data center de Microsoft en Chicago contiene más de 400 mil máquinas. Si usted lee los artículos y los estudios que están siendo publicados, Google y Microsoft ya no pueden confiar más en asumir la robustez del hardware. A estas escalas, la falla del hardware es una constante. En lugar de tratar al hardware como un recurso limitado que debe conservarse -incrementando su confiabilidad mediante la adquisición de costosos sistemas-, estos proveedores aceptan las fallas, adquieren hardware de nivel de usuario, e incrementan la robustez mediante una redundancia significativa -usualmente con conjuntos triples de equipos.
Así que es un hecho que en los sistemas actuales que ya no es defendible suponer la robustez del hardware. Esto significa que los diseñadores de sistemas deben incorporar las fallas de los componentes individuales del hardware en el diseño de las aplicaciones. El que el hardware ya no sea considerado un factor en la confiabilidad del sistema que Gray y Reuter sostuvieron, debe ser reevaluado a la luz de los tamaños de la industria.
La necesidad de una redundancia masiva de hardware también genera la necesidad de un enfoque distinto en el diseño de las aplicaciones. Las aplicaciones de la nube están diseñadas para desplegarse a lo largo de grandes cantidades de máquinas, y para estar listas para incorporar múltiples copias del código y de los datos de la aplicación. El enfoque de consistencia defendido por Gray y Reuter es inadecuado para este tipo de diseño de aplicaciones. Con tantas máquinas y tantas copias de los datos, colocar una base de datos transaccional en el centro del sistema crea un cuello de botella y reduce el desempeño de la aplicación -sin mencionar la pérdida de uptime de la aplicación y la caída de la sobrecargada base de datos debido a la carga de trabajo.
Todos los fundamentos de los actuales sistemas de evaluación del uptime deben ser repensados. No es adecuado el énfasis que se hace en el incremento de la robustez de las aplicaciones mediante la eliminación del punto único de falla a través de una redundancia en par de recursos costosos -sin mencionar que es económicamente inviable en un mundo de súper tamaños. De hecho, en un documento sobre el tema, los diseñadores del data center de Microsoft defienden la eliminación de cualquier redundancia en par de los recursos críticos del data center; en lugar de ello, el documento defiende la redundancia a nivel del data center, con data centers de nivel de consumidor que cambian de uno a otro en caso de que falle la disponibilidad de los recursos.
En resumen, no estoy convencido de la critica que señala que la cloud computing está brindando SLA inadecuados. Si uno observa las aplicaciones de arquitectura tradicional, no queda claro qué disponibilidad proporcionan en realidad los data centers internos, y criticar a los proveedores de nube por SLA laxos no toma en cuenta el hecho de que ellos sí se responsabilizan por las capas de software tan igual como por las de hardware, mientras que las medidas comunes para los data centers internos únicamente se enfocan en la disponibilidad de la infraestructura.
No obstante, cuando uno observa la siguiente generación de aplicaciones, queda realmente claro cuán inapropiadas son las medidas tradicionales de disponibilidad. En un mundo de grandes datos y aplicaciones dispersas en cientos o miles de máquinas (o, ciertamente, dispersas en múltiples data centers), no tiene sentido tratar de aplicar medidas diseñadas para un mundo de pequeñas aplicaciones corriendo sobre hardware costoso. Tal vez es tiempo de repensar el concepto de los SLA.
Como pensamiento final, al parecer una nueva generación de aplicaciones de negocios estándar se encuentra en el horizonte -piense en la arquitectura de Google para los ERP. En lugar de crear islas de inmensos centros de costos (software enormemente costoso puesto sobre costosos grupos de hardware), las compañías utilizarán proveedores externos que escriban aplicaciones para utilizar la enorme y económica redundancia de hardware con una arquitectura de software diseñada para grandes pools de recursos de hardware -todos pagados con una tarifa mensual por usuario. Y no se engañen a sí mismos pensando en que las compañías no utilizarán este tipo de ofertas, si se ofrecen a un 20% del costo que se cobra por la versión instalada en la compañía.
Recientemente escuché un podcast realmente interesante sobre Workday, un nuevo proveedor de SaaS de Recursos Humanos. De acuerdo con el locutor, ellos han captado varios clientes que no deseaban los costos de pagar las actualizaciones del software instalado en la empresa. Es asombroso cuán dispuesta está la gente a tomar algunos riesgos adicionales para ahorrar mucho dinero. El futuro va a ser interesante.
CIO.com
Bernard Golden es CEO de la firma de consultoría HyperStratus, que se especializa en virtualización, cloud computing y temas relacionados. También es el autor de Virtualización para Dummies, el libro más vendido sobre virtualización a la fecha.