Mudanza a la cloud o como no morir en el intento

Desde mi perspectiva de observador del mercado cloud, me apasiona comprobar como los clientes cada día más van comprando las ventajas de los servicios cloud y sobre todo, ver cómo van atreviéndose a dar ese salto a la contratación de estos servicios.

Uno de los puntos que más incertidumbre genera a la hora de abordar nuevos proyecto en servicios clouds en casi todas las compañías, es el llamado Go to cloud, o traducido al “román paladino” como muevo mis máquinas desde mi cloud privada a servicio de cloud pública.

A partir de ese momento cruzamos la frontera que nos adentra en el mundo de las clouds híbridas. Normalmente frente a esta primera experiencia la pregunta que todo el mundo se hace es, ¿cómo voy a realizar esa mudanza de mi infraestructura? Pero a casi todos se nos olvida reflexionar sobre sí me constará lo mismo volver en caso de que mi proveedor no satisfaga todas mis necesidades pasado un tiempo.

La realidad actual es que la mayoría de las compañías que están consumiendo servicios de cloud pública, han nacido alrededor de necesidades puntuales, vinculados a nuevos proyectos y que se han configurado desde cero en estos servicios públicos, normalmente sobre plantillas que el propio proveedor proporcionó a estas compañías. Hasta ahí nada nuevo en el horizonte de un proyecto de TI nuevo en cualquier compañía, además asumiendo que por detrás de estos servicios residen plataformas de virtualización (con estándares de mercados muy asentados como OVF) y que el mercado de virtualización es un mercado maduro, a priori nadie debería preocuparse de como en un momento determinado podrá apagar esa máquina, copiarla y arrancar en un nuevo entorno privado o de otro proveedor.

Cómo es lógico estos proveedores nunca se preocuparon de como evolucionar sus servicios a esta integración de servicios de cloud híbrida, y como es lógico la intención del prestador de servicio era no dar facilidades a su cliente para que a la primera de cambio internalice esta operación o se fuese con el primero que pasase por delante con una opción muchos más atractiva desde el punto de vista económico.

Hasta aquí nada nuevo en el horizonte desde la visión del proveedor de servicio, retener y limitar al máximo la salida de mis clientes, incomprendidos o insatisfechos. Pero un día todo cambio, y el cliente empezó a protestar y sus protestas surgieron efecto cuando los proveedores de servicios se dieron cuenta de que esa puerta giratoria de la cloud híbrida se debía abrir, ya que sólo de nuevos proyectos la cloud no tenía suficiente para seguir creciendo, era necesario que el cliente final diese el paso y moviese sus entornos de producción a los servicios cloud.

A día de hoy podemos encontrar diferentes opciones de integración, en función de la criticidad de mis servicios y la posibilidad de que estos estén disponibles desde una versión unificada a nivel de gestión.

1. Para aquellos servicios menos críticos y que permiten realizar una parada planificada, así como asumir la ventana necesaria para cargar la plantilla. La mayoría de servicios cloud implementados con el vCloud Suite y especialmente con vCloud Director, nos permite definir un catálogo privada de nuestra cloud y mediante un browser cargar la plantilla OVF de las máquinas a migrar.
2. Siguiendo en esta línea y entendiendo que la mayoría de la clouds privadas del mercado están implementadas con vSphere, la siguiente opción es utilizar vCloud Conector. Un conector que se instala en la cloud pública y en nuestra cloud privada, las principales ventajas que nos aporta el conector es la integración de catálogos, movimiento de cargas, vista unificada del entorno, extensión de redes y conexión con múltiples servicios cloud (incluido vCloud Hybrid Services, ¿será casualidad?).
3. Otros proveedores como Amazon Web Services se apoya en su API del servicio para permitir esta importación, descargando el conector y mediante línea de comando realizar estas acciones, y exportación de máquinas virtuales, además ha desarrollado un conector específico para la planta instalada de vmware y para ello está disponible en su web para descarga. Sin embargo para la descarga de las imágenes es necesario exportar estás máquinas a Amazon S3 y luego descargarlo a la cloud privada.
4. La última opción siempre puede ser utilizar software de terceros que nos permite clonar en tiempo real nuestra máquina virtual contra infraestructuras de terceros, ya sea en nuestra cloud o en una cloud pública.

Visto lo visto, los proveedores de servicio no nos ponen escusas, ahora la pregunta es clara, ¿y tú estás dispuesto a llevar tus cargas de trabajo a la cloud?

Gracias por leer nuestro blog, participar y compartir.