Introducción a Microsoft Cloud Adoption Framework para Azure.

Hace unos días os hablamos de los Cloud Adoption Framework (CAF), qué son y cómo pueden ayudarnos en el uso de soluciones en la nube. Si en nuestro primer post introdujimos qué es un CAF y en qué podría sernos de utilidad, en esta nueva entrada nos sumergimos de lleno en la propuesta de Microsoft para la nube Azure.

Veremos que cada proveedor posicionará su nube cuando nos hable de su modelo de CAF, pero el marco es fácilmente extrapolable a cualquier otra nube. Combinar, o al menos conocer, la propuesta de los distintos CAF enriquecerá nuestra visión para aplicar el proceso que mejor encaje a la realidad de nuestra empresa u organización.

El CAF de Microsoft es la propuesta más extensa tanto en contenido como en profundidad entre las que podemos encontrar de los grandes proveedores. Esta sea, probablemente, a la vez su mayor virtud y su mayor defecto. Comprender la propuesta nos puede llevar tiempo, relecturas, discriminar información y resultarnos algo abrumador. Sin embargo, cuando se han analizado todas las áreas de la propuesta, difícilmente encontraremos algún aspecto que se haya dejado fuera.

Además, este CAF se encuentra en mejora y ampliación constante (podemos consultar sus novedades aquí. Os recomendamos que, siempre que sea posible, accedáis a los recursos de documentación en inglés ya que suelen estar unas iteraciones por delante de su versión en español.

Ante tal cantidad de información contenida en el CAF, el objetivo de esta serie de posts es que conozcáis las principales áreas que se trabajan en el marco y tengáis el contexto suficiente como para poder decidir si encaja y es aplicable a vuestra situación particular.

El CAF de Microsoft plantea distintas etapas y una metodología de análisis e implementación para cada una de ellas con los siguientes objetivos:

• Estrategia (Strategy): definir los objetivos, justificación empresarial y los resultados esperados. Trabajar por una comunicación clara y buscar el compromiso de la organización.
• Plan: diseñar un plan de acción aplicable que nos permita conseguir los objetivos y resultados definidos en la estrategia.
• Preparación (Ready): preparar el entorno en la nube para posibilitar el despliegue de soluciones, ayudándonos a organizar los recursos, controlar costes, monitorizar servicios e introducir la seguridad necesaria.
• Migración e Innovación (Adopt): migrar, modernizar y desarrollar nuevos servicios y soluciones sobre la nube una vez desplegada la infraestructura base.
• Gobierno (Govern): implementar políticas transversales a los recursos desplegados. Poniendo el foco, entre otras, en el control de costes, compliance, delegación de operaciones o etiquetado de recursos.
• Seguridad (Secure): identificar los riesgos y mitigaciones propuestas. Elaboración de políticas de seguridad y plan de respuesta ante ataques.
• Administración (Manage): administrar y monitorizar los servicios y soluciones desplegados en la nube. Intervención y mantenimiento proactivo.
• Organización (Organize): alinear los equipos, roles y funciones acorde a las estrategias de adopción de la nube.

A continuación, vamos a explicar qué aspectos se pretende cubrir en cada una de esas etapas para entender cuál es el flujo de trabajo propuesto y qué se analiza en cada punto.

Estrategia

La estrategia debe definir qué partes de la cadena de valor de nuestro negocio serán impactadas por el proceso de adopción de la nube, cuál es la motivación del cambio o cómo podemos medir el éxito de nuestro proceso.

El CAF de Microsoft encuadra las motivaciones para iniciar un proceso de adopción de la nube en tres grandes categorías:

• Eventos empresariales críticos: finalización de soporte técnico de tecnologías críticas, necesidades de reducción de gastos o cambios requeridos por cumplimiento normativo.
• Migración: reducción de la complejidad técnica, preparación para nuevas funcionalidades o integración de una cartera de TI compleja.
• Innovación: transformación de productos o servicios, disrupción del mercado con nuevos productos o servicios o democratización y/o entornos de autoservicio.

El seguimiento de la estrategia se realiza mediante la medición de objetivos y resultados clave (OKR). Si no estás familiarizado con la metodología OKR, nuestro compañero Jesús Javier Marcos escribió un fantástico post en el que cuenta qué son.

La estrategia no tiene que circunscribirse a la empresa u organización en su conjunto, puesto que distintas unidades de negocio o iniciativas pueden presentar distintas motivaciones. Así mismo, planear una estrategia de reducción de costes no conlleva las mismas decisiones que la puesta en marcha de un producto disruptivo para el mercado. En el primer caso, quizá adoptemos una estrategia de control más centralizada; mientras que en el segundo, optemos por descentralizar la administración de la infraestructura para que el equipo de producto sea lo más ágil posible y se reduzcan sus dependencias de terceros.

El anterior es un buen ejemplo de la importancia de introducir la estrategia como parte inicial de la adopción de servicios en la nube. Si no se conoce desde el principio, decisiones sobre aspectos como el gobierno o el modelo operativo, puede que no converjan y faciliten los objetivos que se persiguen. Si no se explicitan, no se tendrán en cuenta.

En esta fase también se nos propone la elección y ejecución del primer proyecto que llevar a la nube o first mover. Con él podremos validar nuestras premisas, aproximaciones iniciales y aprendizaje sobre la nube. Los criterios para elegir este proyecto pueden ser de negocio, como dar soporte a una demanda elástica; o técnicos, escoger una aplicación que tenga pocas dependencias internas e implique mover infraestructura mínima. Se recomienda que este proyecto no sea crítico para la organización ya que en esta etapa aún estamos aprendiendo y podemos necesitar margen para pivotar algunas decisiones. Debe orientarse como un piloto o prueba de concepto y no como despliegue productivo.

Para facilitar el trabajo de definición de la estrategia, podemos acceder a una plantilla genérica donde nos proponen recoger nuestras motivaciones, resultados esperados, informar sobre el primer proyecto que se llevaría a la nube y los stakeholders principales. Es un documento sencillo pero es un buen punto de partida si no sabemos muy bien por dónde empezar a trabajar.

Un punto común en muchas de las metodologías del CAF es la sección de anti-patrones. En el caso de la estrategia identifican lo problemático de lanzarnos a la nube sin haber establecido previamente unos objetivos claros y por otro lado, no comunicar convenientemente las motivaciones del proyecto a todos los involucrados. No cuidar estos detalles nos pondría en riesgo de perder el rumbo y desalinear las distintas áreas de compañía.

Plan

El objetivo de esta etapa es definir un plan de acción a partir de los objetivos y resultados esperados definidos en la estrategia. Tenemos que orientar esfuerzos técnicos y organizativos concretos para alinearlos y dirigirlos hacia la consecución de dichos objetivos.

El CAF propone la realización de distintas actividades que se enmarcar en tres grandes áreas:

1. Inventario de las cargas de trabajo a migrar a la nube. Realizar el análisis necesario para determinar la mejor manera de transicionar a la nube y cuál es el portfolio de aplicaciones o servicios susceptibles de ello. Aquí se mencionan las conocidas como cinco “Rs” cuando se evalúa la mejor estrategia de migración (Rehost, Refactor, Rearchitect, Rebuild y Replace).
2. Adaptar los roles, habilidades y procesos existentes. Realizar un mapa de roles, habilidades y procesos que serán impactados por el cambio y cuáles serán sus contrapartes para el manejo de los servicios en la nube. Identificar lagunas de conocimiento y planificar cómo van a subsanarse.
3. Elaborar el plan aplicable. En este punto se validará que se cumplen los prerrequisitos necesarios, priorizará las cargas de trabajo a migrar a la nube, establecerá los recursos necesarios y se estimará el tiempo necesario.

Abordando estas actividades podemos correr el riesgo de perdernos y llegar a lo que se conoce como parálisis por análisis. No debemos perder el foco y olvidar que los objetivos están planteados en una etapa previa y que estas tareas deben trazar el plan para conseguirlos y movernos a la acción. Si vamos a lo concreto, el inventario de cargas de trabajo debe orientarse a precisamente aquellas que nos permitan conseguir los resultados esperados. Tampoco podemos olvidar que se pueden realizar aproximaciones iterativas e ir planeando oleadas.

En cuanto a las cinco “Rs” propuestas como estrategias de migración, podéis profundizar sobre el significado de cada una de ellas en este post de nuestro compañero Juan María Fiz. Seguramente veáis estas estrategias en multitud de documentación y presentaciones sobre migración a la nube. Puede haber cinco, seis, siete o variar sus nombres. Lo importante es entender la idea detrás de ellas para conocer qué opciones tenemos cuando analicemos nuestras aplicaciones y servicios.

En cuanto al análisis de los roles, habilidades y procesos existentes, no solo se trata de listar qué tenemos y qué vamos a necesitar. Estaremos trabajando con personas de la organización que pueden ofrecer resistencia al cambio. Por ello, además de cubrir sus posibles necesidades de conocimiento y adaptación, deberemos indagar en sus preocupaciones e introducir iniciativas para resolverlas. Una herramienta importante para alinear a todos los involucrados es volver a incidir en la comunicación de la estrategia. Informar de los objetivos y los resultados esperados es la mejor forma de trasladar la importancia del cambio y hacer partícipe a la entidad en su conjunto.

Por último, el plan recogerá todo lo necesario para orientar los esfuerzos que realizaremos en sucesivas etapas. El CAF propone explicitar los siguientes aspectos:

1. Asegurar que se cumplen todos los prerrequisitos necesarios. La revisión de prerrequisitos se realiza desde dos ángulos: estratégico y táctico. La estrategia debe haber dejado claro las motivaciones, objetivos y resultados esperados. El aspecto táctico habrá definido el inventario de cargas de trabajo, los roles y habilidades necesarias y alineado al conjunto de la organización.
2. Definir y priorizar el conjunto inicial de cargas de trabajo a llevar a la nube. Una carga de trabajo es el concepto que nos sirve para agrupar todos los recursos necesarios para proporcionar un servicio determinado: máquinas virtuales, aplicaciones, orígenes de datos, etc. En este punto, habrá que definir y priorizar un conjunto de cargas de trabajo que conformen un backlog que abordar en sucesivas iteraciones.
3. Analizar los recursos de las cargas de trabajo. Una vez tenemos priorizadas una serie de cargas de trabajo debemos profundizar en el conjunto de recursos que las componen y listar todas las máquinas, servidores, aplicaciones, orígenes de datos, servicios de terceros y las dependencias entre ellos.
4. Revisar las estrategias de migración. En el inventario de cargas se hizo la propuesta inicial de migración para cada una de las cargas de trabajo (las cinco “Rs”). Una vez hemos profundizado en el conocimiento de cada una de ellas, es necesario revisar si la estrategia escogida es la adecuada o se plantea otra opción más conveniente.
5. Establecer iteraciones y plan de entregas. Es hora de establecer un marco temporal de trabajo. Se nos recomienda establecer un horizonte de entregas iterativas de entre seis y doce meses. Para poder hacerlo deberemos realizar una estimación inicial de lo que llevará trasladar cada una de las cargas de trabajo priorizadas y los bloques que las componen. Cada una de las iteraciones estará orientada al despliegue de distintos componentes de las cargas de trabajo mientras que las entregas (releases) supondrán que todos los componentes de una carga de trabajo han sido desplegados y está lista para su uso en producción. A la hora de establecer el calendario también hay que tener en cuenta que para realizar el despliegue de cargas, previamente habremos de haber desplegado la infraestructura base (etapa de preparación).

En esta fase hay mucha información sobre la que trabajar y que debe recogerse convenientemente. El CAF nos ofrece la plantilla genérica que ya se utilizó en la fase de estrategia. Al tratarse de un documento reducido, nuestra recomendación es que se trabaje sobre las herramientas de la organización y sobre todo el plan se lleve al ecosistema de gestión de proyectos existente: JIRA, Confluence, Zoho, Google Workspace, Teams, etc.

Al igual que en la fase de estrategia, contamos con una sección de anti-patrones que en este caso nos ponen en sobre aviso de seguir tendencias genéricas, por ejemplo PaaS sobre IaaS, sin analizar qué se ajusta a nuestro contexto. Si aplicamos generalidades corremos el riesgo de introducir fricciones a la hora de alinear nuestro modelo objetivo y conseguir resultados.

Estaréis de acuerdo en que el nivel de profundidad en los apartados de este CAF es digno de mención, ¿o no? Llegados aquí, vamos a poner un punto y seguido en la explicación de la propuesta de Azure y en un próximo post seguiremos profundizando en el tema. Hay mucha información que asimilar y es un buen momento para profundizar en las referencias y coger fuerzas para la próxima entrega. ¡Os esperamos!