Llegamos a ustedes gracias a:



Columnas de opinión

El caso contra el Cloud Computing: Tercera parte

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

[03/04/2009] En las partes 1 y 2 de esta serie, abordé dos de las objeciones más comunes respecto al computing: la dificultad de migrar aplicaciones y los elevados riesgos. Ahora, quiero abordar otra objeción que se suele formular a la computación en la nube: aquella que se refiere a los acuerdos de nivel de servicio, SLA por sus siglas en inglés (Services-level agreements).

Una de las inquietudes más comunes en torno a la computación en la nube es el lapso potencial de tiempo muerto del sistema. Este aspecto es determinante para las aplicaciones en la línea de negocios, pues cada minuto de apagado es un minuto en que alguna función importante del negocio no se ejecuta.
Entre las principales aplicaciones de negocios tenemos las que toman órdenes, interactúan con los clientes, supervisan procesos de trabajo, etc. Ciertamente, los sistemas ERP pertenecerían a esta categoría, así como también las aplicaciones verticales para diversas industrias, como por ejemplo el software de mecanización para una empresa de manufactura, o el software de monitoreo de sensores en las industrias de gas e hidrocarburos, centrales eléctricas y otros.
Frente a la importancia que tiene la disponibilidad de las aplicaciones, muchos reaccionarían con precaución -o incluso rechazo- ante el eventual uso de aplicaciones basadas en la nube. Esta actitud se ve reforzada por el hecho de que algunos proveedores de la nube no ofrecen SLA, mientras que otros proponen SLA inadecuados (en términos de garantizar el tiempo operativo).
Detrás de estas inquietudes podemos detectar la sospecha de que en realidad uno no puede confiar en los proveedores de la nube; es como una aprehensión en cadena que se extiende a toda la organización para preservar la continuidad del negocio. Y, en honor a la verdad, los proveedores de la nube han sufrido caídas aparatosas. Salesforce tuvo que soportar varias en los últimos años y, hace no mucho, Amazon también experimentó una o dos. 
Bajo esta óptica, es comprensible que, para las organizaciones, sus recelos referentes a esta importante conjunción de sistemas críticos de negocios con el proveedor en la nube se traduzcan en un asunto de SLA. 
Pero ¿Es esa la mejor manera de enfocar el tema?
Si analizamos el uso de SLA en otros contextos, veremos que a veces son parte de compromisos al interior de las compañías, como cuando, por ejemplo, el departamento de márketing solicita que el de TI implemente un nuevo sistema, y la gente de TI les garantiza un cierto nivel de disponibilidad. Por lo general, sin embargo, los SLA son elementos de acuerdos de outsource, donde la empresa escoge un proveedor externo, como EDS, para sus sistemas de TI.
Sin duda, en un contexto de ese tipo, los SLA requieren una atención especial. Si googleamos "outsource SLA" obtendremos páginas de "best practices" (mejores prácticas), institutos abocados a brindar asesoría para la elaboración de contratos que contienen SLA, artículos de consejería sobre los principios básicos de la creación de SLA, etc. Lamentablemente, si googleamos "casos de éxito de outsource SLA," apenas si encontraremos algún link. De ahí podríamos deducir que un SLA no necesariamente asegura la calidad del tiempo operativo, aunque, ciertamente, sienta las bases para negociar conflictos en caso de que las cosas no salgan bien, al estilo de un contrato prenupcial.
Entonces, si el objetivo de un SLA es dar más pautas para resolver conflictos luego de que se presente un problema específico, debemos asumir que muchas de las situaciones cubiertas por los SLA no están funcionando adecuadamente. En otras palabras, después de todos los seminarios de mejores prácticas, las negociaciones (a propósito, ¿no les parece increíblemente absurdo que estos asuntos se negocien por separado para cada contrato?), todos los electrones que se han sacrificado en artículos sobre los SLA, resulta que en el fondo no cumplen gran cosa de lo que debería ser su tarea fundamental: disponibilidad del sistema. ¿Por qué, entonces, sería distinto en la nube? 
En primer lugar, el problema que acabo de mencionar: la presencia de un SLA no necesariamente cambia la forma en que ya se realizan las operaciones; simplemente provee una herramienta de argumentación. El punto es la operatividad del sistema, no si el contrato tiene una cláusula para que los abogados puedan respirar aliviados.
En segundo lugar, en el fondo, los SLA per se no protegen las organizaciones de aquello que, teóricamente, están diseñadas para proteger: insuficiente disponibilidad del sistema. Por lo general, los SLA están restringidos al costo del servicio de hosting en sí mismo, no al costo de una ocasional caída de sistema (por ejemplo: la cantidad de dinero que el usuario de la compañía ha perdido o dejado de producir). Así que además de ser ineficientes, los SLA realmente no son de ninguna ayuda si se trata de fijar sanciones económicas para el proveedor. Es cierto que para los SLA internos, la penalidad podría equivaler al despido del administrador central, lo cual tiene un significado emocional nada desdeñable, pero definitivamente no sirve de mucho para proteger a la parte afectada. Después de todo, hacer que el departamento de TI pague una especie de multa a favor del departamento de márketing, equivale simplemente a pasar plata de un bolsillo al otro. 
Para terminar, la presencia de un SLA incentiva al proveedor a cumplir cabalmente los términos del acuerdo, aunque ello no necesariamente implique satisfacer las necesidades del usuario; peor aún, mientras más intensas sean las negociaciones, mayores son las probabilidades de que el proveedor adopte la ley del menor esfuerzo que, en este caso, equivale a ceñirse estrictamente a lo especificado por contrato, en lugar de resolver el problema de la manera que haga falta. No hay nada más irritante que acudir a un proveedor de servicio externo con una necesidad concreta y enterarse de que ese asunto escapa a la cobertura del acuerdo. Grrrr!
Considerando estos, no diremos inconvenientes sino desafíos, ¿podemos afirmar que la ausencia de SLA o su cuestionable calidad para los proveedores de cloud computing no significan nada?
No.
De todas maneras, con o sin SLA en el horizonte, es necesario tener en cuenta los niveles de servicio de la computación en la nube.
No olvidemos que el objetivo es la disponibilidad del servicio, no un compromiso contractual precariamente ligado a dicho objetivo. Así que estos son mis consejos:
Uno, pida un SLA pero recuerde que se trata solo de un objetivo a tener en cuenta, no de un ultimátum que hace que todo funcione bien como por arte de magia. Y tenga presente que los proveedores en la nube, al igual que los proveedores de outsourcing, escriben sus SLA para minimizar su riesgos financieros limitando los pagos al costo de la pérdida del servicio, no al efecto financiero de la pérdida de servicio.
Dos, utilice un criterio apropiado de comparación. El tema no es lo que los proveedores pongan en el papel, sino lo que realmente puede ofrecer un proveedor en la nube comparado a las otras alternativas disponibles. Si nuestro actual proveedor de outsourcing es incapaz de cumplir sus compromisos de tiempo operativo, definitivamente lo más aconsejable es buscar otra posibilidad. Si trasladamos la comparación al proveedor externo en la nube versus nuestro grupo interno de TI, cabe aplicar el mismo razonamiento.
Tres, recuerde que la calidad del tiempo operativo interno está directamente relacionada a la sofisticación de la organización de TI. Si bien las grandes organizaciones pueden permitirse el lujo de contar con un amplio staff de TI y sofisticados datacenters, el resto tiene que lidiar con presupuestos muy limitados para sus datacenters, procesos de automatización básicos y falta de personal. Por eso no es raro que sufran una emergencia tras otra, y que la operatividad sea casi un asunto del azar. Para este tipo de organizaciones, un proveedor en la nube puede representar una significativa mejora en la calidad del servicio.
Cuarto, aunque se sienta satisfecho con la calidad de su tiempo operativo actual, es recomendable que examine cuánto le cuesta obtener ese estándar. Si para hacerlo tiene que acudir reiteradamente a la intervención manual con refuerzos de personal a cada momento, quizá ese tiempo operativo le está resultando demasiado caro. Una comparación de tiempo operativo y costos entre la nube y los esfuerzos internos (o los servicios de outsourcing) puede resultar ilustrativa. Al respecto, conversé con un colega de operaciones Google quien me hizo notar que, a la escala en que ellos trabajan, la administración manual era simplemente impensable: nada pasa a la etapa de producción sino ha sido completamente automatizado. Entonces, si resulta que para obtener un buen nivel de tiempo operativo usted tiene que remangarse la camisa y recurrir a métodos antiguos, es muy probable que, económicamente hablando, le resulte más conveniente entrar en la nube.
Cinco, como corolario del último punto, incluso si hubiera algunas aplicaciones que, debido a sus rígidos requerimientos de tiempo operativo, se deben administrar -sí o sí- localmente, eso no tiene porque traducirse en todo un portafolio de aplicaciones. Muchas aplicaciones no imponen requerimientos tan estrictos de tiempo operativo; de manera que sería financieramente irresponsable pretender gestionarlas en el mismo framework de administración y con los mismos costos operativos que las aplicaciones de misión crítica. Revise su portafolio de aplicaciones, tanto el actual como el futuro, y ordénelas de acuerdo a sus requerimientos de tiempo operativo. Evalúe si algunas pueden migrar a un entorno de menor costo cuya capacidad de tiempo operativo resulte aceptable, y utilice esta experiencia como un adelanto de lo que implicaría el tiempo operativo en un entorno en la nube. De esta manera tendrá la información necesaria para determinar si es posible o no que otras aplicaciones importantes también pasen a la nube.
En cierto sentido, la última recomendación es similar a otra que hago en la entrega referida a riesgos de este mismo dossier: en el citado artículo, sugiero, entre otras cosas, evaluar el portafolio de aplicaciones de acuerdo a su perfil de riesgo, con el objetivo de identificar cuáles pueden migrar con toda seguridad a una infraestructura de nube. El cálculo de tiempo operativo es otro criterio de evaluación a aplicarse en un marco general de evaluación.
Entonces, el SLA de nube no es una contradicción ni mucho menos una razón válida para negarle al cloud computing la oportunidad de ayudarnos a ejecutar las operaciones de TI de manera más eficiente.
Bernard Golden es CEO de la firma de consultoría HyperStratus, que se especializa en virtualización, cloud computing and temas afines. También es autor del libro Virtualization for Dummies, un best seller en este tema.
CIO.com