Cómo evaluar la migración a la nube de apps heredadas de misión crítica

El entusiasmo por la nube sigue en aumento, y supera preocupaciones históricas como la seguridad. Pero lo que también está claro en los resultados de este año es que la adopción de la nube es cada vez más rápida, y que las compañías tratarán de que sus proveedores les ofrezcan infraestructuras always-on que soporten sus aplicaciones más críticas en este nuevo entorno.

Las compañías necesitan estudiar detenidamente qué aplicaciones deben pasar a la nube, y tener en cuenta qué implicaciones tiene en la gestión desde un punto de vista de recursos, conocimientos, costes y complejidad. Sabemos de primera mano que estas consideraciones no tienen una respuesta única para cualquier tipo de situación, y que reescribir las aplicaciones para la nube en muchos casos no será una solución válida.

La disponibilidad, un problema para las apps de misión crítica en la nube

La propuesta de valor de mover aplicaciones a la nube parece clara: puede mejorar de forma importante la agilidad y escalabilidad de las aplicaciones. En muchos casos las aplicaciones de misión crítica se beneficiarán al máximo de la infraestructura de nube, pero la disponibilidad sigue siendo una pesadilla.

Las nubes están diseñadas pensando en su tamaño y elasticidad. Es posible que haya componentes individuales en la nube que fallen y no se remplacen. A menos que su aplicación esté diseñada para evitar este tipo de fallos en la arquitectura de cargas de trabajo, podría encontrarse con un problema serio.

Nosotros vemos moverse una gran cantidad de aplicaciones básicas. Y vemos nuevas aplicaciones construidas en un entorno de nube. Pero no vemos moverse muchas aplicaciones de primer nivel.

El alto precio del tiempo fuera de servicio de las apps de misión crítica

El tiempo fuera de servicio de una aplicación de misión crítica puede paralizar una empresa. Por ejemplo, el año pasado justo antes de Acción de Gracias, United Airlines sufrió un problema técnico a escala nacional en el software que controla sus operaciones en tierra, lo que causó un corte de dos horas. Y esto, a su vez, originó retrasos a los pasajeros de United y vuelos perdidos en todo el país. Y en Nochebuena, un problema en la infraestructura de nube AWS de Amazon impidió que Netflix pudiese transmitir contenido a millones de clientes justo cuando acababan de sentarse para ver sus programas y películas favoritas.

Según las investigaciones de Aberdeen Group, el coste medio estimado del tiempo fuera de servicio es ahora de 138.888 dólares por hora.

Más del 50% de los responsables de TI quieren tener menos de 30 minutos de tiempo fuera de servicio al año, aunque de momento la nube no les proporciona cifras ni siquiera parecidas a esas. Ahora mismo tienen una disponibilidad del 99 por ciento, cuando lo que necesitan es 99,99 por ciento o, incluso, 99,999 por ciento.

En último extremo, determinadas aplicaciones podrían no migrarse nunca a la nube porque no lo justifica el gasto ni el riesgo. Permanecerán en entornos individuales alejados de la nube o incluso virtualizados. Estas aplicaciones pueden necesitar hardware dedicado por razones de rendimiento o funcionalidad. O quizá, las exigencias normativas exijan entornos seguros y cerrados.

Las empresas tendrán que evaluar cada aplicación caso a caso para determinar si se adapta mejor a un entorno físico, virtualizado, de nube privada, de nube pública o de nube híbrida. Cada caso tendrá sus ventajas y sus inconvenientes.

Tres consideraciones importantes sobre la disponibilidad

El primer paso que hay que dar al considerar la implementación de cualquier aplicación, es evaluar el coste de los tiempos fuera de servicio.

Tanto si busca una oportunidad basada en la nube o basada en premisas, es muy recomendable que conozca el coste de los tiempos fuera de servicio de sus aplicaciones. Este coste puede medirse el dinero, en daño a la reputación, incluso puede medirse en pérdida de vidas en el caso de aplicaciones para el sector de sanidad. Así podrá comprender el nivel de disponibilidad que necesita implementar para estas aplicaciones, y cuál es la mejor manera de conseguirlo.

Si decide seguir el camino del proveedor de servicios, es vital que examine detenidamente los acuerdos de nivel de servicio (SLA) para determinar lo que ocurrirá realmente si no consigue la disponibilidad prometida.

Algunos SLA pueden decir cosas como, “garantizamos un 100% de uptime”, pero mire los detalles del contrato actual, podría encontrar cosas como “si no somos capaces de alcanzar ese nivel, ofreceremos un descuento del 20% en la factura del próximo mes”. Una aplicación típica de primer nivel podría costarle 150.000 dólares por cada hora fuera de servicio, por lo que evidentemente esa solución no le resuelve nada. Necesita soluciones que le ofrezcan niveles de garantía mucho mayores.

Por ejemplo, Stratus ofrece una garantía de 50.000 dólares si sus clientes sufren cualquier tipo de tiempo fuera de servicio.

También es esencial tener en cuenta la protección de los datos. Una cosa es proteger los datos en la capa de transacciones, pero también es necesario considerar otros tipos de tiempos fuera de servicio que puedan ocurrir. ¿Qué ocurriría si un tsunami derriba todo mi edificio? ¿Hasta qué punto necesito hacer copias de seguridad de mis datos?