Las empresas no logran compensar los costes de las interrupciones de la nube
- Software y Apps
A medida que las organizaciones amplían el número de aplicaciones en la nube se enfrentan a la posibilidad de sufrir más interrupciones por fallos en los servicios individuales. Pero las compensaciones de los proveedores solo cubren el coste por el fallo en los servicios en sí, y no por la interrupción de las aplicaciones, por lo que las empresas deben asumir un volumen creciente de gastos, un problema para el que de momento no hay una solución clara.
Los proveedores de servicios cloud proporcionan a los clientes la posibilidad de ensamblar aplicaciones aprovechando diferentes servicios, pero un fallo en uno de ellos puede interrumpir completamente la aplicación, ya sea una aplicación empresarial o destinada al cliente final. Dado que los proveedores de la nube solo garantizan la disponibilidad de los servicios individuales sus programas de compensación no cubren los costes que puede tener para el cliente la interrupción de sus aplicaciones, por lo que deben asumirlos sin más ayuda.
En un reciente artículo publicado por el Uptime Institute, el Dr. Owen Rogers, director de investigación de computación en la nube profundiza en cómo esta situación está generando cada vez más problemas y costes para las organizaciones que construyen sus aplicaciones en la nube empleando los servicios de los proveedores. Explica que los acuerdos de nivel de servicio (SLA) establecen la disponibilidad probable o garantizada de un servicio cloud específico, junto con una compensación en caso de que no se cumpla con esta disponibilidad. Además, hay un SLA específico para cada servicio en la nube.
En muchos casos, los proveedores emplean una arquitectura basada a grandes rasgos en máquinas virtuales y un balanceador de carga virtual, que distribuye el tráfico entre las máquinas virtuales. Estas se basan en un modelo de infraestructura en la nube (IaaS) según el cual el usuario es el responsable de diseñar las máquinas virtuales para que sean lo suficientemente resistentes. En cambio, el equilibrador de carga es una Plataforma como Servicio (PaaS), y es el proveedor el que garantiza que sea lo suficientemente resistente. Así, si el equilibrador de carga falla, toda la aplicación queda inutilizable y el tráfico no se puede enrutar a las máquinas virtuales, lo que hace que el equilibrador de carga sea el eslabón más débil.
En estas situaciones las máquinas virtuales son accesibles para la empresa para su mantenimiento o administración, pero no para los usuarios finales, que acceden a través de las aplicaciones. El problema está en que los proveedores no pagan ninguna compensación porque las máquinas virtuales no sean accesibles, y este recae enteramente en el cliente. Para garantizar la máxima disponibilidad de sus aplicaciones los usuarios pueden buscar servicios cloud que se hayan diseñado para tener la máxima resiliencia posible, mediante servidores redundantes o conmutación por error automática, pero en muchos casos los proveedores no proporcionan la suficiente visibilidad y control sobre cómo están construidos sus servicios.
En su artículo, Rogers explica que en el supuesto de que cada máquina virtual y equilibrador de carga tenga un coste mensual de 3 dólares al mes, un SLA típico de proveedores como Microsoft ofrecería una compensación del 10% del costo mensual del balanceador de carga si no está disponible del 99,99% al 99,9% al mes. Esto mismo podría aplicarse a las máquinas virtuales. En caso de que el balanceador de carga se interrumpa durante 43 minutos, este proveedor tendría que pagar 0,3 dólares, pero no estaría obligado a pagar por la interrupción de las máquinas virtuales.
Esto supondría que, si el costo total de la aplicación es de 30 dólares y la compensación es de 0,3 dólares, el pago compensatorio por esta interrupción sería del 1% de la tarifa mensual. Esto se encuentra muy lejos de los costes derivados de esta interrupción para el cliente, que van mucho más allá del coste de los servicios en la nube.
Para Rogers este ejemplo sirve para ilustrar dos puntos clave del modelo de aplicaciones basadas en la nube. El primero es que la responsabilidad de los proveedores termina con los SLA de los servicios individuales. Para mitigar los problemas los usuarios podrían haber diseñado una aplicación más escalable, haber reducido el costo de las máquinas virtuales al implementar el ajuste de escala automático, finalizando las máquinas virtuales en desuso. Así, el usuario el auténtico responsable de crear una aplicación lo suficientemente resiliente y escalable, mientras que el proveedor es el responsable de la calidad de su pequeña parte en este esquema.
El segundo punto clave que según Rogers deben tener en cuenta los clientes de la nube es que los SLA no son en absoluto una póliza de seguros, ya que no están diseñados para cubrir los costes de una interrupción comercial, sino solo de los servicios, algo marginal. Por ello, los clientes de la nube deberían identificar los puntos débiles en sus aplicaciones y evaluar adecuadamente el riesgo y el impacto que puede tener la interrupción de los servicios de su proveedor. Así, los clientes son los máximos responsables de que sus aplicaciones en la nube sean resilientes y garanticen los servicios a los clientes finales y a su propia organización, cuando se trata de aplicaciones para el uso interno.
