Cómo definir acuerdos de nivel de servicio para una nube híbrida

Nube pública, privada o híbrida: a los usuarios finales no les importa donde están alojados sus servicios de TI –a menos que un servicio se caiga o se pierdan los datos– así que la presión está en el área de TI.Conforme las organizaciones de TI adoptan las nubes híbridas, la definición de acuerdos de niveles de servicio (SLA) es cada vez más difícil. Sin embargo, no es imposible. Con un poco de previsión y comprensión, TI puede tejer un acuerdo de nivel de servicio en la nube que cumpla con los niveles de servicio, así como los requisitos reglamentarios de cumplimiento, seguridad y gobernabilidad.

"Una nube híbrida significa una combinación de servicios –algunos públicos y otros privados– y trabajan al unísono como si fueran un solo sistema", dijo Judith Hurwitz, CEO y fundador de la firma de análisis de la competencia Hurwitz & Associates. "El tema es que no se trata de sistemas estáticos. Cualquiera de los componentes podría ser el origen de los problemas. Además, su enlace más débil un día podría no ser su eslabón más débil del día siguiente. Es muy fluido", dijo Hurwitz.

Por lo tanto, es esencial que las organizaciones de TI comprendan quién es dueño de todas las partes de la pila en el nuevo entorno híbrido. "A medida que se introducen múltiples jugadores, hay que ser muy conscientes de quién tiene qué responsabilidad. Al desarrollar un SLA, usted debe tener una comprensión clara de la propiedad y el soporte en múltiples niveles de la pila", dijo Tim Burke, CEO de Quest, un proveedor de servicios gestionados con sede en Sacramento.

Por ejemplo, Burke dijo que si usted está utilizando computación y almacenamiento de Amazon Web Services, entonces es Amazon quien gestiona esas pilas y su seguridad. "Puede parecerle que eso está bastante bien definido. Usted solamente se conecta a esas cosas", dijo. Pero con la introducción de la conectividad entre la nube privada y la pública, usted también ha introducido el tema del transporte, por lo que necesita saber quién es el responsable de eso".

"El truco con cualquier proveedor de la nube es que hay un punto de demarcación donde termina la responsabilidad del proveedor de servicios y donde comienza mi responsabilidad. En un servicio en la nube, [el punto de demarcación] es una capa en la pila de aplicaciones. En función del servicio en la nube, puede ser que sea el sistema operativo, la plataforma como servicio o un contenedor. Puede ser uno de cualquier número de capas, pero siempre existe", dijo Abner Germanow, director senior de marketing de la empresa New Relic, una firma de software de análisis con sede en San Francisco.

Además de entender esta línea de demarcación, las organizaciones de TI necesitan entender los niveles de servicio que ofrece un proveedor de la nube. "[Los servicios en la nube] proporcionan una excelente plataforma sobre la base de las normas que han definido. Si funciona para ti, eso es genial. Pero no imparten en ellos otros atributos. No es justo para ellos", dijo Burke. "La mayoría de los proveedores de nube pública se centran en la escala, por lo que sentarse y pasar mucho tiempo con usted para trazar nuevos niveles de servicio se encuentra fuera de su modelo de negocio."

Hurwitz estuvo de acuerdo. "Digamos que usted es una empresa de tamaño medio y utiliza Gmail como su proveedor de correo electrónico. No puede llamar a Google y decir: 'Esto es lo que exigimos de ustedes por un nivel de servicio’. De hecho, es probable que no encuentre a nadie con quien hablar de eso de todos modos". Pero, tal vez, hay una excepción: "Si usted es una empresa multimillonaria y se has suscrito a un servicio especial, tal vez entonces tendrá influencia y harán algo especial para usted. Es todo una cuestión de la escala e importancia", dijo Hurwitz.

Sin embargo, para la gran mayoría de las empresas que no son empresas multimillonarias, Hurwitz ofreció este consejo: "Tienen que decidir cuál es su nivel de tolerancia para los imprevistos. Si los servicios fallan en cualquier forma o son muy lentos, ello tendrá un impacto en los ingresos y su capacidad para hacer negocios. Piense ‘¿Cuál es el modelo de implementación más segura y fiable que puedo usar para ese servicio?’"

Por ejemplo, si una empresa se comunica con los clientes sólo a través de correo electrónico entonces para ellos se trata de una aplicación de misión crítica. "Es posible que tenga que pagar un poco más o buscar una estrategia diferente porque saben que si ese servicio se cae durante 10 segundos, usted será dañado. No es blanco y negro. Es en gran medida un acto de equilibrio", dijo Hurwitz. La organización debe determinar qué áreas son las más críticas, incluyendo los requisitos de rendimiento y seguridad, y con qué estrategia de copia de seguridad cuentan, así como cuáles estrategias de recuperación de desastres tienen.

"Todos estos temas se convierten en cosas que usted tiene que averiguar", dijo, y luego "hay que trabajar en reunir elementos para tener el nivel de servicio que necesita".

Germanow dijo que puede haber momentos en que su acuerdo de nivel de servicio con los usuarios finales sea más estricto que el acuerdo de nivel de servicio en la nube. "Es posible que tenga una arquitectura de aplicaciones que conmuta con varios proveedores o de otra manera desencadena diferentes escenarios de disponibilidad de manera que la experiencia del cliente se mantiene sólida en su acuerdo de nivel de servicio, mientras que la línea que tiene con los diferentes proveedores de nube podría ser mucho más flexible, ya que puede fallar el relevo de proveedor de servicios a proveedor de servicios", explicó. "Entender todo es bastante crítico".