¿Cuáles pueden ser considerados verdaderos servicios de Cloud Computing?

Hoy día, en que ya empieza a existir una nutrida oferta de proveedores de servicios en la nube (Cloud Providers) con una diversidad de soluciones o servicios en este modelo nuevo que llamamos de "consumo" o comercial y que es uno de los servicios tercerizados o de outsourcing disponibles para llevar a cabo la cesión de funciones de algunas partes de la TI de las organizaciones, es conveniente despejar las diferencias en percepción con respecto a que es un servicio en la nube versus cual no lo es. 

A pesar de ser promocionadas como ofertas de nube, muchas de ellas en realidad no lo son y es importante tener una claridad al respecto y no permitir ser engañados por propuestas que en todo caso tiene que ver con servicios "hosteados" de infraestructura (hardware y/o software), pero que de ninguna manera puede ser llamados servicios de nube.

Resulta, que el NIST (Instituto Naciones de Estándares y tecnología) perteneciente al departamento de comercio de Estados Unidos, se dió a la tarea en 2011 de crear una serie de definiciones con respecto a lo que debe cumplir cada solución de servicios de TI que pretenda ser considera como una solución de nube, y con ello, eliminar duda alguna con respecto a la desinformación generada por algunos proveedores de nube que al no contar con todas las características que mencionaré más adelante, han querido "pintar" como servicios de nube, servicios que no lo son.

El NIST publicó en Septiembre de 2011 en el estándar llamado SP 800-145 titulado "The NIST definition of Cloud Computing" que puede ser consultado públicamente en el siguiente enlace:

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

en donde entre otras cosas, hace 3 grandes grupos de definiciones de las características inherentes a un servicio de nube, estos grupos tienen que ver con:

• Los posibles escenarios de implementación de un servicio de nube.
• Modelos de servicio de un servicio de nube.
• Caracterísitcas esenciales de un servicio de nube.

Veamos cada grupo y sus definiciones respectivas.

Escenarios de Implementación

Los escenarios de implementación planteados para la adopción de un servicio de nube por un cliente fueron:

• Nube Privada.- Es un escenario en el cual se lleva a cabo una construcción de uno o más servicios de nube en cumplimiento con las definiciones del NIST y en donde toda la infraestructura aprovisionada para tal servicio (por un constructor de nube o Cloud Builder), es dedicada en tu totalidad a un solo cliente. Los activos requeridos para el servicio de nube en este escenario se pueden encontrarse en los centros de datos del proveedor de nube o del cliente.
• Nube Pública.- Es un escenario en el cual a diferencia del escenario anterior, toda la infraestructura de nube es compartida por múltiples clientes que son segmentados de manera lógica regularmente, pero compartiendo los recursos de harware y software del servicio o servicios de nube contratados. Los activos requeridos para el servicio de nube en este escenario se encuentran mayormente en los centros de datos del proveedor de nube, salvo los dispositivos requeridos como parte del servicio que se requieren en instalaciones del cliente.
• Nube Comunitaria.- Es un escenario en el cual se implementa uno o varios servicios de nube para clientes con afinidad de necesidades, regularmente en un sector industrial, ejemplo, educación, financiero, manufactura, trámites gubernamentales, seguridad nacional, etc. Los activos requeridos para el servicio de nube en este escenario se pueden encontrar en los centros de datos del proveedor de nube o de la comunidad.
• Nube Híbrida.- Es un escenario en el cual pueden existir potencialmente una mezcla de los 3 escenarios anteriores en un cliente. Los activos requeridos para el servicio de nube en este escenario se encuentran en los centros de datos del proveedor de nube y del cliente.

Modelos de Servicio

Los modelos de servicio no son otra cosa que la oferta posible de productos o servicios que un proveedor de nube ofrece a sus clientes. Cualquier oferta de servicios de nube encaja invariablemente en:

• Infraestructura como servicio (IaaS).- Hardware ofrecido en modalidad de un servicio de nube y por tanto alojado en las instalaciones del proveedor de nube (en sus centros de datos o en instalaciones del cliente si se trata de un escenario de nube privada o híbrida). La unidad de medida y cobro de este tipo de servicio en la nube, es por componente de hardware, de acuerdo a sus capacidades definidas, por mes.
• Plataforma como servicio (PaaS).- Ambientes de desarrollo y el hardware necesario para su funcionamiento ofrecido en modalidad de un servicio de nube y por tanto alojado en las instalaciones del proveedor de nube (en sus centros de datos o en instalaciones del cliente si se trata de un escenario de nube privada o híbrida). La unidad de medida y cobro de este tipo de servicio en la nube, es por instancia de acuerdo a sus características definidas, por mes.
• Software como servicio (SaaS).- Software tanto para aplicaciones hacia usuarios finales como para clientes empresariales. La unidad de medida y cobro de este tipo de servicio en la nube, es por usuario, por mes (PUPM, Per User Per Month).

Cada proveedor de servicio es libre de mercadear su oferta de servicio como crea más conveniente, por lo cual podemos ver acrónimos de todo tipo tales como: XaaS (cualquier cosa como servicio), EaaS (todo como servicio), DRPaaS (soluciones de recuperación de desastres como servicio), NetaaS (networkig as a service) entre otras, sin embargo todas caen en las 3 definiciones anteriores. 

Característias Esenciales

Finalmente, y de gran relevancia, se definieron 5 características esenciales que sin ellas, no puede ser catalogado un servicio de TI tercerizado como un servicio de nube:

• Amplio acceso al servicio.- Lo que significa ya que el servicio es accesado mediante Internet como medio, poder hacer uso de este desde cualquier lugar con esta conexión, en cualquier dispositivo (PC/laptop, smartphone y tablet).
• Auto-aprovisionamiento en demanda.- Lo que significa que en cualquier momento, el cliente o usuario del servicio de nube, puede solicitar mediante una interfaz Web, una ampliación de los servicios de nube contratados y aprovisionarse en consecuencia, inmediatamente.
• Rápida elásticidad.- Lo que es lo mismo que poder crecer, sin limitaciones de capacidades y todos los aspectos asociados en un situación normal cuando se trata de infraestructura interna tradicional de TI, cumpliendo lo necesario para lograr el auto-aprovisionamiento en demanda.
• Medición del consumo del servicio en todo momento.- Al contar con las características anteriores, es necesario sino indispensable, poder contar con una interfaz que nos permita medir en forma sencilla y eficiente los servicios de nube contratados, su vigencia (de existir), las capacidades y facilidades contratadas y la asignación de estos servicios a usuarios.
• Recursos compartidos.- Finalmente, recordemos que de acuerdo al escenario de implementación, los recursos de hardware y software necesarios para un servicio de nube, serán compartidos en algún momento del tiempo con diversos clientes, ya sea al finalizar un contrato de nube privada o al compartirse en el día a día en una nube pública o comunitaria.

Existe una característica que muchos clientes o los propios constructores de nube evaluan al momento de construir o contratar un servicio de nube, tal es el caso que el servicio de nube sea "multi-cliente" o multi-tenant. Es último en primera instancia no es una característica definida como esencial por el NIST y segundo, es una promesa que de acuerdo a la solución de TI ofrecida en la nube, es posible que por el momento sea solo una promesa de largo plazo. Por ello, esta caracteristica apegados a lo definido por el NIST, no debiera ser motivo para tachar de incumplimiento a un servicio como servicio de nube.

Un resumen gráfico de las definiciones anteriores, puede ser visualizado a continuación.

Características adicionales que deben ser consideradas:

• El cobro del servicio de nube debe ser mensual.
• Debe existir la opción de contratación a partir de 1 mes.
• No deben existir cargos de penalización por "bajarse de la nube" (periodos forzosos), salvo los casos en que como parte del servicio de nube, se realice una inversión para colocar componentes (hardware, software y licencias) en las distintas localidades del cliente y en donde se requiere llevar a cabo un periodo mínimo de preciación de estos activos.
• Debe haber una clara definición de los periodos de actualización del servicio (tanto en componentes de hardware y versiones de aplicaciones).
• Deben ser claros los niveles de servicio (SLA, Service Level Agreements) esperados por el servicio o servicios de nube contratados.
• Debe evaluarse y tenerse muy claros los contratos asociados cuando se trata de una oferta de nube que nos ofrece reutilizar nuestra infraestructura actual ya que regularmente son modalidades que conllevan una sesión de la propiedad al proveedor de servicios de nube de todo lo acordado en la propuesta de reutilización de activos (hardware, software y licencias hasta entonces propiedad del cliente).

Ya conociendo ustedes como potenciales clientes de un servicio de nube, las definiciones y características que se han mencionado, ¿qué aspectos de evaluación esenciales debemos "correr" al momento de evaluar y seleccionar a un proveedor de nube?, les sugiero que ese "checklist" contemple al menos lo siguiente:

• Solicitar una prueba de concepto inmediata del servicio ofrecido desde cualquier lugar y dispositivo, con ello, identificaremos si realmente el proveedor cuenta con el servicio de nube operando y listo para "subir" servicios a la nube. De no llevarse a cabo en horas o unos cuantos días, es claro que dicho proveedor no cuenta con tal oferta.
• Probar la interfaz de auto-aprovisionamiento de nuevos servicios que estará en manos del cliente, con la finalidad de revisar la facilidad de uso y el aprovisionamiento automático de más servicios en el momento que se requieran. Si el proveedor cuenta con un proceso manual de aprovisionamiento, es claro que no cumple con este requerimiento.
• Las fechas de entrega del servicio, una vez que se firma el acuerdo comercial debe ser de minutos u horas idealmente, salvo los servicios que requieren de dispositivos en las instalaciones del cliente en donde estamos sujetos a los tiempos de importación, logística e implementación de estos.
• Solicitar una demostración de la medición del servicio para comprobar la granulidad de los cargos (idealmente, deben ser cobros por usuario por mes (PUPM) o por instancia por mes).
• La perioricidad de las actualizaciones a nuevas versiones y la transparencia hacia el servicio en estos procesos de migración debe ser inmediata, después de liberarse una nueva versión por el proveedor de nube y/o los fabricantes de dicha infraestructura de nube.
• Revisar la vigencia mínima del contrato de servicios de nube (idealmente, deberia ser tan granular como para partir de un mes sin penalizaciones por salirse o "bajarse" de la nube).

Los aspectos anteriores, sugiero que sean puestos en un semáforo con 3 niveles de cumplimiento (verde, amarillo y rojo) para poder conocer de un rápido vistazo el cumplimiento de un servicio de TI como servicio de nube. Como saben, existe un largo camino al presentarse cada tendencia tecnológica para que las promesas de esta sean una realidad por la oferta de soluciones en el mercado.

Les recomiendo ampliamente revisar el siguiente libro para aquellos pioneros y expertos que les gusta tener el mayor detalle posible del tema:

• Cloud computing bible (el título en español, "¿Qué es la nube?"), Barrie Sosinsky.