Porqué, para qué, cuándo y cómo migrar al Cloud computing

Tanto entre mis alumnos, como en las conversaciones con otros compañeros del sector, percibo siempre la duda de la necesidad o conveniencia de migrar al Cloud. Y, ciertamente, no es algo sencillo de explicar. 

Muchas veces se generan intensos debates sobre si es una moda, una técnica comercial de las multinacionales para “sacarnos los cuartos” o un camino irresistible al que mejor no presentar una excesiva resistencia.

Por ello, en este artículo quiero resumir los orígenes, razones, procesos y características de los diferentes senderos que deberé recorrer para desplegar mis aplicaciones y servicios en la Nube.

El Porqué de migrar a la nube

Tengo muy claro -al iniciar el camino hacia el Cloud- que el principal motor para abordar los costes y esfuerzos debe ser un modelo de negocio claro, donde la adopción de la Nube se signifique como un mecanismo para incrementar la productividad. Es decir: al Cloud se va a ganar dinero.

No es buena idea que aborde el aprovecharme de las posibilidades de una infraestructura a la que tendré acceso, si el coste por su uso no es cubierto por un incremento de beneficios o la optimización de los costes.

La pregunta no es porqué, realmente es cúando.

Debo tener en cuenta que, desplegando mis servicios en estas plataformas, me hago beneficiario de precios que solamente se pueden alcanzar en Economía a Escala. Es decir, cuando se habla de adquirir millones o centenas de millones de servidores, está claro que el precio unitario de compra, mantenimiento y operación está muy por debajo de lo que yo podría conseguir en el mercado general. Y esa contención de los costes, se revierte en precios de consumo del Cloud cada vez más bajos y competitivos.

La alta disponibilidad, la escalabilidad y la resiliencia, son otras ventajas que emergen de estas plataformas mastodónticas, en donde la disponibilidad de recursos es virtualmente infinita (el límite lo pone mi nivel adquisitivo). Cubriendo las necesidades de la práctica totalidad de los casos de uso, al disponer de la capacidad de replicar cualquier servicio, infraestructura o aplicación que quiera publicar en el Cloud, tantas veces que sea necesario para asegurar niveles de acuerdo de servicio superiores al 99,99%, en cualquier zona geográfica del mundo.

Otra característica que solamente me ofrece este tipo de plataformas es que la inversión en adquisición, puesta en marcha y crecimiento de mis servicios, es muy inferior a la que tendría que enfrentar en el caso de querer hacerlo con mi propio “hierro”. 

Aun, incluso, cuando a medio/largo plazo los costes de instalación, administración, mantenimiento y actualización tanto del software como del hardware, puedan llegar a ser similares; a corto plazo (menos de dos años), la Nube es imbatible en los costes de operación, inicio nuevos servicios, o abordar el crecimiento (ya sea imprevisto, constante, puntual, o periódico).

Tampoco son baladí las inversiones asociadas para logar un acceso mundial a mis aplicaciones; lo que implica una formidable complejidad técnica y una barrera de entrada, muchas veces insalvable, a nuevos mercados o al crecimiento empresarial. El Cloud, sin embargo, es por naturaleza de ámbito mundial. Siendo, gracias a la redundancia permanente, la plataforma perfecta para publicaciones geo replicadas con acceso vía Web.

El duopolio de facto existente (Amazon 48% - Azure 10%) produce el recelo de poner "todos los huevos en la misma cesta"

Por último, y no por ello menos importante, las plataformas de Nube liberan de la creciente necesidad de formación, experiencia y conocimiento que se requiere para administrar y evolucionar sistemas informáticos tan complejos como los actuales. Los tiempos del administrador para todo, han quedado atrás. Y el coste de sostener una creciente plantilla que debe estar en formación permanente, no siempre es viable económicamente. Por ello, el delegar estas responsabilidades al Cloud, con los diferentes niveles basados en los tres tipos principales de “sabores” (IaaS, PaaS y SaaS), y el ahorro de costes asociados en personal especializado (sea de plantillas o externo), es otra causa de plantearme la migración de los servicios.

Para qué migrar a la nube

Aunque me repita, el objetivo último de adoptar el Cloud computing es el incrementar los beneficios de la empresa a corto y medio plazo, por medio de la optimización de los costes:

• Disponibilidad del servicio. La mayoría de los negocios se apoyan firmemente en servicios publicados en Internet y/o en aplicaciones/herramientas. De hecho, aún demasiado pocos son plenamente conscientes de lo dependientes que somos de las Tecnologías de la Información hasta que falla algún sistema, o deja de estar disponible. Y este es uno de los objetivos más importantes que se buscan al irse a la Nube: la importancia de tener mi “sistema informático” permanentemente disponible; lo cual gana en criticidad según el impacto que genera en el negocio cada vez que se sufre una incidencia. Llegando incluso, a significar el cierre de la empresa, si la interrupción es lo suficientemente prolongada o crítica.
• Simplificar. Todo lo relacionado con la informática va ganando complejidad según la tecnología y la propia industria va incrementado su madurez (aún es muy joven). El hardware, el software y las herramientas que se crean con ello, son cada vez más numerosas y complejas. Llegando a ser inmantenibles, insostenibles y desconocidas. El concepto de KISS, gana en importancia, y hacer más sencillo las gestiones de los recursos TI se convierte en imprescindible. Así desde el propio concepto de Infraestructura como Servicios, hasta el Software como Servicio, el Cloud ofrece una salida para mitigar la complejidad y su crecimiento.
• Seguridad. Esa es otra preocupación con la que se debe bregar desde el entorno empresarial, por las consecuencias legales y de negocio que ocasionan. Estamos inmersos en la metáfora de “El cañón contra el escudo”, en una verdadera guerra armamentística en el ciberespacio. Y dónde los conocimientos necesarios, en renovación constante y permanente sobre seguridad informática, están atesorados por un número muy limitado de profesionales. Rara es la empresa que puede tener un departamento o personal dedicado en exclusiva a proteger sus sistemas de los llamado cyber-ataques. Así, delegando en el Cloud obtendré acuerdos de seguridad del servicio, con una fracción de la inversión que implicaría subcontratar estos trabajos a empresas externas, o formar mi propio personal.
• Pago por uso. Curiosamente el mayor coste de una infraestructura sobre la que publicar mis servicios, nos es tanto la adquisición, mantenimiento y evolución de la misma, si no la amortización de todas las capacidades que no se utilizan y que deben ser adquiridas igualmente. Por ejemplo, capacidades de cálculo (procesadores y placas madre), memoria (RAM), y almacenamiento que adquiero sobre dimensionadas, para poder soportar picos de trabajo o crecimiento previsto, y que no se utilizan durante largos periodos de tiempo. En Cloud se paga por lo que se usa. Si crezco, el coste es mayor porque estoy consumiendo más recursos para generar más negocio, pero la diferencia la marca la capacidad de reducir la escala, consumiendo menos, y dejando de pagar por aquellos recursos que ya no necesito. Siendo esto una operación con un gran impacto en el ahorro de costes de operación.
• Costes laborales. La simplificación de la plataforma sobre la que funcionan las aplicaciones significa que delego en la Nube la adquisición, instalación, administración, mantenimiento y evolución del hardware y el software – dependiendo del nivel de abstracción de los servicios. Lo que significa una importante reducción de los costes laborales, al liberar ciertos perfiles profesionales de estas tareas. Por ejemplo, no necesitaría tener personal de guardia por si una fuente de alimentación falla.

Cuándo lanzarse a la nube

Podría decir que la mejor respuesta es cuanto antes, pero en realidad hay múltiples factores a tomar en cuenta para iniciar el camino hacia el Cloud.

Lo primero que debo de asegurar es que el sistema, infraestructura o aplicaciones que quiero publicar en la Nube, sea un sistema estable. Es decir, es un error pensar que un servicio que sufre errores funciona mal o de forma impredecible, va a estabilizarse por irse al Cloud. No solamente no es así, sino que los problemas se pueden hacer aún más complejos y difíciles de resolver, impactando directamente en la operatividad.

Otra cosa que debo de mitigar al máximo es la resistencia al cambio que toda organización va a presentar. Desde los profesionales que ven peligrar sus funciones, el usuario final que está acostumbrado a hacer las cosas desde dentro de su zona de confort, hasta el directivo que se resiste a que los datos salgan de debajo de su mesa. Mientras esta resistencia no deje de ser un problema bloqueante, el forzar el cambio solamente añade riesgos de fracaso.

Los grandes centros de Cloud atráen el talento y experiencia de los mejores. Hay en marcha una nueva transformación de los puestos de trabajo

El equipo debe estar formado en los procesos de migración, o ser acompañado por consultores con experiencia real y conocimiento profundo del Cloud de destino. El tamaño y número de servicios que ofrecen las Nubes actuales está en continuo incremento, y se necesita “tenerlos por la mano” para poder tomar las decisiones arquitectónicas, de procesos y tecnología sobre las que vamos a construir nuestros servicios.

También las propias circunstancias del negocio me pueden indicar que es el momento del salto. Así podría ser indicio claro el que tenga un bloqueo en el crecimiento (principalmente a causa de los costes de inversión necesarios); o estar por debajo del nivel crítico de disponibilidad y resiliencia en los servicios, que pueda poder en riesgo la viabilidad de la empresa; o que deba abordar complejos y caros procesos de certificación de calidad, seguridad o procesos; o que por fin caiga en cuenta que el sitio más endeble e inseguro para almacenar los datos es debajo de mi mesa. 

Aunque, en mi experiencia, casi siempre el pistoletazo de salida proviene de la percepción y conocimiento, por parte del personal técnico, de las ventajas económicas y operativas de la Nube. Transmitiendo a Dirección las ventajas en la relación servicios/costes que ofrece la plataforma.

Cómo hacerlo

Una vez que tenga claro que el Cloud es mi destino, hay que empezar por lo más básico: una valoración del nivel de madurez de nuestra plataforma actualpara, en conjunto con negocio y tecnología, definir cuáles serían las aplicaciones y servicios que podríamos desplegar.

La primera clasificación, por cada una de ellas, es el esfuerzo que hay que realizar, y que se podría categorizar así:

• Migración. Muy orientada a IaaS, o máquinas virtuales, en donde despliego los servicios en un entorno tan similar al original, que no tengo que realizar casi ningún cambio. Esta es la forma más sencilla de irme al Cloud, pero también es la que más coste por servicio soporta.
• Transformación. Ya sea como Infraestructura o Plataforma, mis servicios van a requerir ser modificados en mayor o menor medida para ajustarse a las características de la Nube. Un ejemplo es tener que cambiar la forma en que trabajo con los ficheros, al adoptar una cuenta de almacenamiento de Blob en vez de una Carpeta en el Sistema de ficheros. Esto requiere transformación a nivel de código, que será más o menos costosa de acuerdo con la deuda técnica con que me encuentre.
• Reconstrucción. Hay casos en que la transformación exige tantos cambios y tan profundos que puede ser más interesante económicamente y de forma práctica el reconstruir el servicio desde cero o casi. Esto puede suceder si queremos irnos a la versión PaaS o SaaS del Cloud, o aprovecharnos de las capacidades de los servicios serveless, o implantar las arquitecturas de aplicaciones Cloud más correctas (bus de mensajes, cqrs, key Vault, etc.). 
• Por último, y no menos importante, decidir no migrar. Aquellas aplicaciones en donde el coste no compense los beneficios de la adopción del Cloud, no deben ser migradas. Como ejemplo típico, es aquella aplicación que funciona sobre Windows XP utilizando drivers hechos a medida y que reproducirlos en un entorno virtual sería difícil y costoso. O aquella aplicación realizada sobre Excel, que su reconstrucción sería inabordable.

El siguiente paso que realizar, una vez definido si el proyecto de migración tiene sentido y es el momento oportuno para abordarlo, es el realizar pilotos de migración. Esta aproximación tiene un coste muy pequeño (solo se paga por lo que se usa) y permite formarse en los conocimientos necesarios para realizar las transformaciones o reconstrucciones que van a aparecer durante la migración. Tengo que tener muy presente que me voy a enfrentar a las diferencias tanto en la Infraestructura, Sistemas, Telecomunicaciones, Desarrollo de software, Seguridad, etc., en comparación con mi plataforma actual. A lo que he de añadir que, cuanto más alto es el nivel de abstracción, más “específicos” son los cambios y de más calado.

Pero si no mido, no podré saber si la plataforma Cloud está bien configurada o mis servicios y aplicaciones funcionan correctamente. Es más, debo definir qué significa “funciona correctamente” o “mejora”, estableciendo el conjunto de métricas y KPI’s que monitorizar, y cuáles son los valores nominales en donde se deben de mantener.

La paciencia es un requisito imprescindible para llevar a buen puerto un complejo proyecto de migración.

Qué pruebas funcionales, de carga, experiencia de usuario o rendimiento se deben realizar; cuales serán automáticas; cómo se van a reportar; y en que prioridad ejecutar las acciones correctivas. Y cuáles son los valores esperados y aceptables.

Por supuesto hay que definir un marco financiero que limite el gasto a valores sostenibles. Pero evitando caer en la falacia de obtener un presupuesto basado en una estimación de las horas y costes previstos; porque en este tipo de migraciones los riesgos, mutabilidad y volatibilidad de las operaciones fuerzan un rango de incertidumbre demasiado amplío para ser útil.

Por ello, es crítico saber el volumen de inversión que estoy dispuesto a asumir; cuales son los puntos de fallo, retorno y no retorno; y las acciones de refinanciación o mitigación de los costes extraordinarios, si los hubiera. Es decir, realizar una gestión de riesgos económicos.

Por último, hay que tener paciencia. Son operaciones técnicas con ramificaciones e implicaciones en todo el negocio. Por lo cual el dicho de “las prisas nunca son buenas consejeras” hay que aplicarlo a rajatabla, e ir cubriendo todos los pasos de forma confiable para llevar a buen término el piloto (primero), y luego las migraciones a producción.

Desventajas

Sin duda no existe ninguna tecnología que no tenga desventajas; y la Nube no iba a ser diferente.

Una de las mayores resistencias aparece cuando nos damos cuenta de que nos convertimos en un cliente cautivo, en donde tenemos una dependencia bastante alta con el proveedor. Es decir, si nos decidimos por los servicios de Amazon, no es transparente ni sencillo el irnos el día de mañana a Azure, o volverlos a traer a nuestra infraestructura privada.

Han cambiado las reglas del juego. Ahora, cualquier pequeña empresa puede posicionar sus servicios en Cloud con una inversión inicial mínima

Al revés, cuanto más abstracta es nuestra plataforma (PaaS o SaaS) más encadenados estamos al proveedor y a su tecnología. Llevándolo a su límite en servicios como Lambdas o Serveless, o las plataformas de publicación de arquitecturas de microservicios. Añadiendo que el límite de nuestros servicios lo impondrá el límite de lo que puede hacerse con el Cloud elegido.

Y aquí tenemos otra desventaja: de facto en la actualidad vivimos un duopolio com Amazon AWS y Microsoft Azure. Es cierto que existen Google y otras Cloud, pero realmente la voz cantante la lleva AWS con casi el 48% del mercado, seguido por Azure con poco más del 10%, y Google con apenas un 3%.

También, como transmito durante todo el artículo, hay que asumir importantes costes monetarios, pero también en horas/hombre, en esfuerzo, en formación y en transformación de la propia empresa. No es el proceso más crítico y complejo al que se enfrentan las empresas, pero no es un proceso sencillo, transparente y barato.

Aquí habría que incluir el impacto en la paz laboral de la empresa. Cloud genera recelos y rechazo en los perfiles técnicos orientados a la administración de sistemas; siendo la decisión de migrar al Cloud causas de conflictos, resistencias al cambio, o transformaciones en la fuerza laboral.

Conclusión

No hay otro camino, ya sea de forma privada, híbrida o en Cloud pública, las ventajas de adoptar la Nube como plataforma sobre la que construir servicios son irrefutables. Y soy de la opinión de que no tiene vuelta atrás.

Creamos en ello o no, vivimos en un mundo hiperconectado, global y público. En dónde el concepto de ventaja competitiva hace emerger grandes corporaciones y destruye a otras, en ciclos tan cortos que ningún economista hubiera creído posible hace unas pocas décadas.

Y donde la Nube es casi una obligación a causa del cambio en profundidad las reglas del juego que significa el dar acceso universal a servicios del mayor nivel y calidad, anteriormente reservados a las empresas con abultados presupuestos económicos.

Hoy en día, basado en Cloud, montar una Startup o un negocio clásico con unos costes mínimos de TI ya no es una entelequia, es una realidad que se observa en el día a día.

Lo cual me lleva a la conclusión de que la pregunta realmente a contestar es: ¿Cuándo?