Microsoft Cloud Adoption Framework para Azure: Landing Zone y cargas de trabajo.

¡Bienvenidos de nuevo! Seguimos avanzando en nuestro análisis de los distintos framework de adopción propuestos por los proveedores Cloud y hoy continuamos con la disección de la propuesta de Azure.

En la primera parte analizamos las primeras etapas del framework: la estrategia y el plan. En esta segunda entrega profundizaremos en las etapas de Preparación (Ready) y Migración e Innovación (Adopt).

Preparación (Ready)

El objetivo de la preparación es comenzar a definir y provisionar los recursos comunes necesarios para poner en marcha nuestras cargas de trabajo en la nube. Este proceso se conoce como establecer la Landing Zone e incluye implementar aspectos como la estructura de cuentas, suscripciones, etiquetado de recursos, facturación, control de costes, modelo de identidad, modelo de red (conexiones con nuestros entornos on-premise), modelo operativo, políticas globales, mecanismos de monitorización y gestión del ciclo de vida de los servicios de Azure.

Probablemente, este sea este el momento más habitual donde las compañías buscan la ayuda de partners como Paradigma. Hayan seguido de forma consciente o no las líneas marcadas por un framework de adopción, hay un camino común que consiste en la ejecución de una prueba de concepto sobre la nube que, si resulta exitosa, se quiere llevar a un entorno productivo. Sin embargo, eso ya son palabras mayores que conllevan cubrir todos esos aspectos de industrialización que marcan la diferencia y para los que la compañía puede precisar conocimiento externo que acelere la toma de decisiones sobre la nube concreta.

Si aplicamos la metodología definida en este framework, la prueba de concepto (first mover) se ejecutaría durante la fase de estrategia. Se recomendó que se escogiera un sistema no crítico precisamente porque el modelo operativo y la landing zone aún no están establecidas y no se cumplen los requisitos de un entorno productivo. En este momento ya contamos con esa experiencia previa, hemos analizado qué cargas, soluciones o servicios queremos llevar a la nube (plan) y podemos componer la fotografía de necesidades que requiere nuestro entorno productivo en la nube.

Vamos a explicar en qué consisten los aspectos típicos que se definen en una Landing Zone y cómo este framework nos orienta en su definición.

Para comenzar se establece el modelo de cuentas, management groups y suscripciones. Las suscripciones agrupan los servicios desplegados sobre Azure y son la unidad superior de facturación. La confección de este modelo está íntimamente ligado a la estructura y matriz de responsabilidades de la compañía. Dependiendo de su tamaño puede haber una o varias suscripciones. En caso de ser varias se definirá cuál es el criterio de su creación, si habrá suscripciones por entorno (muy habitual), si hay suscripciones por proyecto concreto (debido a la entidad, importancia o gestión delegada del mismo) o si, por ejemplo, se establece una suscripción para el manejo de infraestructura de red común.

Otro aspecto cardinal que se dirime a la hora de crear la Landing Zone es el modelo de identidad y acceso. Las suscripciones de Azure están asociadas a un tenant de Azure Active Directory. Esta solución es la que centraliza todo el modelo de identidad de este proveedor Cloud y sobre la que se pueden tomar muchas decisiones. Quizá una de las más importantes que se valora en este punto es la integración con la identidad corporativa para ofrecer a nuestros usuarios la posibilidad del single sign-on y compartir las políticas on-premise. También se establecen muchas de las políticas de seguridad transversales como la obligatoriedad de la doble autenticación, limitación de conexión a determinados servicios dependiendo de nuestra ubicación, etc.

Así mismo, se abordará el modelo de facturación y control de costes. Si trabajamos este aspecto podremos afinar la atribución de costes a nuestros proyectos y definir los mecanismos de seguimiento de los mismos. Es habitual definir dashboards que nos permitan analizar los gastos ya sea en el mismo portal de Azure o llevándolos a las herramientas de reporting corporativas. Cabe mencionar que uno de los objetivos habituales que se tiene en mente a la hora de migrar a la nube es conseguir ahorro de costes frente a nuestra infraestructura on-premise. Esto no se consigue per se por el hecho de haber migrado a la nube y podemos llevarnos una sorpresa si no trabajamos de forma activa en este punto.

Al establecer la Landing Zone también se trabaja sobre muchos puntos de la gobernanza Cloud. Entre ellos las políticas de etiquetado de los recursos que se provisionan. Las etiquetas son parte fundamental para la atribución de costes que mencionamos en el punto anterior así como para la asignación de responsables y catalogación de los recursos. Etiquetas típicas que se definen son el entorno, usuario al cargo, centro de costes, unidad organizativa o proyecto. Fijaos si el etiquetado es importante que en la gran mayoría de implantaciones invitamos a crear políticas de obligatoriedad de las mismas. De esta manera, si no se etiqueta bien el recurso, ¡no se crea!

Llegamos a un punto muy importante en la definición de la Landing Zone como es el modelo y conectividad de red. Gracias a la documentación del framework podemos informarnos de topologías muy habituales que van desde sencillas implementaciones de una única red virtual hasta aproximaciones WAN o el famoso modelo Hub & Spoke. Definir el modelo de red no es sencillo pero para eso tenemos este fantástico framework y su documentación. Para orientarnos en la toma de decisiones contamos con una guía específica que puede ayudarnos mucho. Volvemos a traer a colación, como ya hemos comentado en otras ocasiones, que aunque se hablan de soluciones y servicios de Azure, podemos abstraer la información lo suficiente como para poder aplicar los conceptos a las topologías desplegadas en otras nubes o para realizar planteamientos Multi-Cloud.

Cualquier servicio, sobre todo los orientados a un entorno productivo, deberá estar convenientemente monitorizado. Al establecer la Landing Zone también se definen las políticas comunes en este aspecto. Es el momento de definir qué métricas se van a recoger sobre los distintos servicios, qué alertas se establecen y si se utilizarán los servicios nativos de la plataforma (Azure Monitor) o se realizarán integraciones sobre soluciones ya existentes en la empresa que permitan un punto único de operaciones.

Al tratar de definir de forma clara cómo vamos a operar nuestros servicios en la nube, no podemos dejar de abordar la definición del modelo de operaciones sobre esta nueva plataforma Cloud. El desarrollo del manual operativo deberá estar ligado a la definición de roles y responsabilidades por lo que, en este punto, es habitual el desarrollo de matrices RACI que nos ayuden a documentar nuestras operaciones.

Definir todos los aspectos anteriores puede entrañar complejidad y nos llevará tiempo. Por ello, el framework pone a nuestra disposición multitud de ayuda en forma de guías y documentación específica para conocer modelos comunes de trabajo en la nube y que van desde modelos totalmente descentralizados hasta modelos distribuidos. También nos invita a aprovechar las posibilidades que la nube nos ofrece para iterar, pivotar y refactorizar servicios. Así, podemos abordar distintas estrategias a la hora de definir nuestra Landing Zone:

• Inicio a pequeña escala y expansión: esta opción implementa un producto mínimo viable (MVP) para iniciar una migración. A medida que progresa la migración, se seguirá un enfoque basado en la refactorización de módulos para consolidar el modelo operativo y la metodología de gobernanza.
• Inicio a escala empresarial: esta opción está indicada cuando los requisitos empresariales requieren una implementación inicial enriquecida de landing zones con una gobernanza, seguridad y operaciones totalmente integradas desde el principio.

Para acabar con la fase de preparación os comentamos los anti-patrones más habituales resaltados por el framework. Destacaremos dos de ellos. El primero es atribuir que cualquier servicio desplegado en la nube está listo para su uso en producción sin configurar nada. Ya habéis visto todo lo que hemos abordado en puntos anteriores para darle forma (¡y no hemos profundizado en la seguridad!). El segundo es pensar que también estos servicios nos ofrecen alta disponibilidad por el hecho de estar en la nube. Esto no es así, de hecho lo habitual es que las configuraciones por defecto no ofrezcan despliegues en alta disponibilidad para contener los costes. Los esquemas de alta disponibilidad y recuperación ante desastres también debemos tratarlos en la Landing Zone si desplegamos servicios críticos.

En este momento parece que ya lo tenemos todo listo para desplegar en condiciones. ¡¿Qué tal si vamos a ello?!

Migración e Innovación (Adopt)

Como os habréis fijado en el título de esta sección, hemos optado por hacer una traducción libre de la fase “Adopt”. Lo hemos hecho porque “Adoptar” puede confundirse con la acción genérica del framework y parece que podemos ir directamente a esta fase cuando en realidad es la última de las principales. El objetivo de esta etapa es el despliegue de cargas de trabajo, ya sea porque existen previamente y las movemos (migración) o creamos nuevas soluciones directamente en nuestra nueva nube (innovación).

Si hemos llegado a este punto aplicando el framework, contamos con la priorización de cargas de trabajo sobre la que trabajamos en la fase de elaboración del plan, y estamos en disposición de ir ejecutándolas en distintas iteraciones. Cuando se habla de migraciones un término común para definir esas iteraciones es el concepto de oleadas. Generalmente en una oleada se introducen servicios que, por su relación funcional o dependencias, tienen que moverse a la vez. Precisamente uno de los aspectos que el framework invita a analizar en el plan es ese análisis de dependencias y del que os hablamos explícitamente en la primera parte. Esta metodología no da puntada sin hilo.

El enfoque de la migración de cargas está muy trabajado en el framework y contamos tanto con una guía con un enfoque metodológico: assessment, deploy y release; como con ejemplos concretos para migrar cargas basadas en VMWare, Windows Server, SQL Server o Aplicaciones Java (¡y solo citamos algunos!).

En cuanto a la puesta en marcha de nuevas soluciones, el modelo operativo y toda la estructura de la Landing Zone ya nos dan los mimbres para ir provisionando los servicios necesarios y gobernarlos acorde a los requisitos productivos. Las guías que el framework pone a nuestra disposición hablan de ejemplos de casos de uso que son muy habituales y que generalmente han ido de la mano en su despliegue en la nube como son: desarrollo de productos digitales con iteraciones cortas y guiadas por el feedback de los usuarios, democratización de los datos, computación ubicua e Internet de las cosas (IoT) o aplicación de la Inteligencia Artificial.

¡Es hora de respirar un poco! En estas dos partes de la serie de posts ya hemos explicado las fases principales propuestas por el framework: estrategia, plan, preparación y migración e innovación. Os damos un merecido descanso para asentar y profundizar en los conceptos que os hemos contado y en unos días volveremos con la última entrega sobre el Microsoft Cloud Adoption Framework para Azure donde hablaremos de actividades transversales y metodologías de soporte que nos ayudarán en cualquier momento: gobierno, seguridad, administración y organización. ¡Os esperamos!