Retos y dificultades en el viaje a la nube

¿Dónde están cometiendo las empresas los principales errores a la hora de establecer una estrategia cloud?

Bajo mi punto de vista, y habiendo sido tanto cliente como consultor, precisamente la falta de una estrategia cloud es lo que más lastra a las empresas en una adopción eficaz y eficiente. Muchas veces se ve la adopción cloud como una palanca de costes, pensando que el modelo de pago por uso va a suponer una reducción por sí mismo porque no hay que provisionar con antelación. Esto, que es cierto pero incompleto, es lo mismo que pasó en los inicios de la virtualización, ya no era necesario un servidor físico para cada carga y aislamiento, pero eso no dio lugar a una reducción del hardware, sino a una exponencialización de los desarrollos y servicios. Por otra parte, los modelos económicos de las empresas no siempre soportan de buen agrado el pasar los modelos de inversión acotados presupuestariamente a modelos de gasto más impredecibles. 

Pensar que la adopción cloud es meramente un aspecto tecnológico es posiblemente el mayor error. La adopción cloud debe ser un modelo de cultura de la empresa, al igual que la cultura DevOps o cualquier otro cambio estructural. Es cierto que, de forma oportunista, algunas decisiones tecnológicas puedan derivar en un modelo cloud parcial, pero sin el resto de la organización soportando el cambio será posiblemente un modelo problemático cuando no fallido:

• RRHH: Es necesario entender que los perfiles cloud no son los mismos que existían y que la reconversión de perfiles no es sencilla. Un técnico de sistemas especializado en almacenamiento, directorio activo, o un operador de consola que han trabajado siempre con entornos gráficos o en Shell no son reconvertibles a programadores de sistemas para tener infraestructura como código de una forma fácil. Tampoco un desarrollador de C, Cobol, o de java tiene mucho interés en aprender de cómputo, almacenamiento, redes, etc., al igual que un arquitecto de software no es reconvertible muchas veces en un arquitecto de sistemas. Los perfiles cloud actualmente son escasos y muy demandados, con lo que si no hay unas condiciones de trabajo que personalmente les satisfagan, durarán menos de un año en cuanto dispongan de ciertos skills. Los planes de formación, el ambiente de trabajo, el liderazgo que hay que desarrollar evolucionando desde formas tradicionales de gestión deben ser acordes o tendremos una rotación muy alta debido al poco atractivo.

• Financiera/negocio: Como se ha indicado antes, este también es uno de los errores o dificultades. Si la dirección financiera no cambia la mentalidad, la adopción cloud será fallida. Un modelo de pago por uso y predictibilidad de gastos son incompatibles, hay que manejar la incertidumbre con un modelo FinOps adecuado, donde las decisiones de ahorro se establecen centralizadamente (por ejemplo con los planes de ahorro de instancias reservadas) y el traslado de las decisiones tecnológicas a los ingenieros con retos de visibilidad de los gastos e incentivos orientados a la optimización de los mismos, mediante cierta gamificación de costes y showback/chargeback de costes a las unidades de negocio demandantes. Normalmente es complicado hacer visibles los costes de las soluciones desarrolladas a las unidades de negocio, hay muchos servicios compartidos y suele ser difícil hacer una categorización exhaustiva o exclusiva de los mismos, suele recurrirse a un reparto ponderado en función de determinados parámetros como ingresos, costes o personal de esa unidad de negocio. Una correcta adopción FinOps implica que cada decisión de despliegue cloud debe responder a cómo se va a incrementar el negocio debido a ese coste, y los propios hyperscalers permiten, mediante el etiquetado de cada recurso, extraer los costes asociados casi de forma inmediata, no sólo mediante las calculadoras previas al despliegue como mediante el seguimiento prácticamente online del consumo.

• Sistemas: Otro de los errores suele ser pensar que llevar a cloud es la solución a los problemas de obsolescencia, incapacidad de escalado o eliminar trabas burocráticas con la dirección financiera para la compra de equipos. Sin embargo, al igual que no se recicla la basura cambiando el color del cubo, sino que exige un tratamiento previo y entendimiento del reciclaje en todos los miembros de la familia, no se resuelven los problemas de sistemas cambiando el datacenter on-prem a un datacenter ajeno (aunque lo llamemos nube). En muchas ocasiones nos encontramos que la migración de cargas a la nube cambian de un modelo on-prem a un modelo de “housing” de máquinas virtuales. Por otra parte, los “cantos de sirena” asociados a los descuentos aplicados para la migración de cargas tienen una duración limitada, normalmente de 3 años máximo y sólo para nuevas cargas. Pensar que “ya reduciremos costes de aquí a 3 años porque vamos a optimizar” sin un plan realista de transformación y optimización de las aplicaciones para ejecutarse en cloud, llevará a un desencanto y paralización de los proyectos de migración, si son puro Lift&Shift o un replatform menor. Adicionalmente, la migración a cloud, cuya principal ventaja es olvidarse de la infraestructura física, obliga a adaptar nuevos modelos de seguridad, actualización y evolución muy superiores a los tradicionales. No te puedes permitir disponer de un sistema no crítico en Red Hat 5 o Windows 2003 porque dejará de funcionar en un plazo muy corto. Decisiones en las que antes no se ponía ningún foco se convierten ahora en un imperativo. O si tengo un servicio como un balanceador de carga determinado que evoluciona a otro servicio, me veré obligado a modificar mis sistemas irremediablemente. 

• Desarrollo: Aquí entramos en otro de los grandes dilemas si no hay una clara apuesta y cambio cultural. Los equipos de desarrollo normalmente están expuestos a presiones de las unidades de negocio por las fechas de puesta en producción de las nuevas funcionalidades. Transformar las aplicaciones existentes en cloud nativo, para ofrecer exactamente la misma funcionalidad que anteriormente, suele ser poco inspirador. Hay que dedicar muchas horas de rediseño, rearquitecturización y pruebas para empezar a sacar partido al cloud. Muchas empresas empiezan los nuevos desarrollos en cloud, lo cual es una gran opción, porque se genera tracción, pero experimenta el bloqueo de interoperar con los sistemas legacy. Una correcta adopción cloud debe considerarse como un cambio estratégico a nivel de la organización y no un mero cambio tecnológico, por ello, debe ir acompañado de una correcta implantación de un CCoE (Cloud Center of Excelence) que permita de una forma gradual y sostenida evolucionar el modelo de gobierno de TI, considerando todas sus velocidades y potencialidades. Igualmente, es preciso contar con un squad de innovación cloud, o experiential architecture que pueda ir valorando y considerando las modificaciones arquitecturales necesarias para nuevos servicios y aplicaciones.

En la siguiente entrega veremos qué retos serán los principales a la hora de afrontar de forma seria un modelo cloud.