Refactorización de zonas de aterrizaje

Una zona de aterrizaje es un entorno para hospedar cargas de trabajo que se aprovisionan previamente mediante código. Dado que la infraestructura de la zona de aterrizaje se define en el código, se puede refactorizar de manera similar a cualquier otro código base. La refactorización es el proceso de modificar o reestructurar el código fuente para optimizar la salida del código sin cambiar su finalidad ni su función básica.

La metodología de preparación usa el concepto de refactorización para acelerar la migración y quitar los bloqueadores comunes. En los pasos de la introducción a la metodología de preparación se describe un proceso que comienza con una plantilla de zona de aterrizaje predefinida que se alinea mejor con su función de hospedaje. A continuación, refactorice o amplíe el código fuente para expandir la capacidad de las zonas de aterrizaje para ofrecer esa función con una seguridad, operaciones o gobernanza mejoradas. En la imagen siguiente se ilustra el concepto de refactorización.

Figura 1: Refactorización de zonas de aterrizaje.

Bloqueadores comunes

Cuando los clientes adoptan la nube, las consideraciones sobre la zona de aterrizaje son el bloqueador más común para la adopción y los resultados empresariales relacionados con la nube. Los clientes tienden a decantarse por uno de los dos bloqueadores siguientes. A menudo, los diferentes equipos se inclinan hacia uno de estos dos obstáculos, lo cual da lugar a interbloqueos que dificultan el proceso de adopción.

Los dos bloqueadores principales se basan en la creencia de que el entorno en la nube y los centros de datos existentes deben tener paridad de características en relación con las operaciones, la gobernanza y la seguridad. Este es un objetivo a largo plazo inteligente. Sin embargo, lo difícil es el delicado equilibrio entre los tiempos para lograr ese objetivo y la velocidad necesaria para proporcionar resultados empresariales.

Bloqueador: Actuar demasiado pronto

Se necesitaron años y un esfuerzo considerable para alcanzar el estado actual de seguridad, gobernanza y operaciones en el centro de datos actual. También se necesitaron observaciones, aprendizaje y personalización para ajustarse a las restricciones únicas del entorno. La replicación de los mismos procedimientos y configuraciones llevará tiempo. Alcanzar la paridad de características total también puede generar un entorno con un rendimiento deficiente en la nube. Este enfoque de paridad también conduce a un considerable gasto excesivo no planeado en el entorno en la nube. No intente aplicar los requisitos de estado actual a un entorno de estado futuro como fase de desarrollo temprana. Este enfoque no suele ser rentable.

Figura 2: Actuar demasiado pronto es un obstáculo habitual.

En la imagen anterior, el cliente tiene un objetivo de 100 cargas de trabajo en ejecución en la nube. Para ello, es probable que el cliente implemente su primera carga de trabajo y, a continuación, sus primeras diez cargas de trabajo (aproximadamente) antes de que estén listas para publicar una de ellas en producción. Finalmente, alcanzarán el objetivo del plan de adopción y contarán con una sólida cartera en la nube. Sin embargo, la x roja de la imagen muestra dónde se bloquean, normalmente, los clientes. Esperar una alineación total puede retrasar la primera carga de trabajo en semanas, meses o, incluso, años.

Bloqueador: Actuar demasiado tarde

Por otra parte, actuar demasiado tarde puede tener importantes consecuencias a largo plazo en el éxito del trabajo de adopción de la nube. Si el equipo espera a alcanzar la paridad de características hasta que se completen los esfuerzos de adopción, se encontrará con obstáculos innecesarios y se requerirán varias escalaciones para mantener los esfuerzos bien encaminados.

Figura 3: Actuar demasiado tarde es un obstáculo habitual.

Este caso es similar al anterior, en que se actuaba demasiado pronto. En esta imagen, el cliente espera demasiado tiempo para conseguir la preparación empresarial en todas las zonas de aterrizaje. Al esperar demasiado, el cliente se verá limitado por la cantidad de refactorización y expansión que puede aplicar en el entorno. Estas restricciones limitarán su capacidad de generar un éxito continuado.

Buscar el equilibrio

Para evitar estos bloqueadores comunes, se recomienda un enfoque iterativo basado en un plan de adopción en la nube bien estructurado que maximiza las oportunidades de aprendizaje y minimiza el tiempo necesario para conseguir éxito empresarial. La refactorización y los esfuerzos paralelos son fundamentales para este enfoque.

Advertencia

Los equipos de adopción que tengan un objetivo a medio plazo (en 24 meses) para hospedar más de 1000 recursos (aplicaciones, infraestructura o recursos de datos) en la nube tienen pocas posibilidades de tener éxito con un enfoque de refactorización. La curva de aprendizaje es demasiado alta y la escala de tiempo es demasiado ajustada para los enfoques orgánicos para adquirir aptitudes. Un punto inicial más completo que requiera menos personalización será una ruta de acceso mejor para lograr sus objetivos. Los asociados de implementación, probablemente, podrán guiarle hacia un enfoque mejor.

El resto de este artículo se centrará en algunas restricciones clave que pueden facilitar un enfoque de refactorización, a la vez que se minimiza el riesgo.

Teoría

El concepto de refactorización de una zona de aterrizaje es sencillo, pero su realización requiere de las protecciones adecuadas. El concepto anterior describe el flujo básico:

• Cuando esté listo para compilar la primera zona de aterrizaje, comience con una zona de aterrizaje inicial definida mediante una plantilla.
• Una vez implementada la zona de aterrizaje, use la guía en los artículos siguientes de la sección Enhance del índice para refactorizar y ampliar la zona de aterrizaje inicial.
• Repita el proceso de revisión y adición hasta que tenga un entorno preparado para la empresa que cumpla los requisitos mejorados de los equipos de seguridad, operaciones y gobernanza.

Enfoque de desarrollo

La ventaja de un enfoque basado en la refactorización es la capacidad de crear rutas de acceso de iteración paralelas para el desarrollo. La imagen siguiente proporciona un ejemplo de dos rutas de acceso de iteración paralelas: la adopción de la nube y la plataforma de nube. Ambas progresan a su propio ritmo, con el mínimo riesgo de convertirse en un bloqueador para los esfuerzos diarios de ningún equipo. La alineación con el plan de adopción y las protecciones de refactorización pueden conducir a acuerdos respecto a los hitos y claridad con respecto a las dependencias de estados futuros.

Figura 4: Iteración paralela de zonas de aterrizaje.

En las rutas de acceso de iteración de ejemplo anteriores, el equipo de adopción en la nube está migrando su cartera de 100 cargas de trabajo a la nube. En paralelo, el equipo de plataforma en la nube se centra en seguir el plan de adopción en la nube para asegurarse de que el entorno está preparado para esas cargas de trabajo.

En este ejemplo, las iteraciones planeadas se ejecutan de la siguiente manera:

• El equipo de la plataforma en la nube inicia sus esfuerzos de desarrollo con la implementación de una zona de aterrizaje inicial. Esa zona de aterrizaje permite al equipo de adopción en la nube implementar y comenzar a probar su primera carga de trabajo.
• Para prepararse para la próxima implementación de 10 cargas de trabajo del equipo de adopción en la nube, el equipo de la plataforma en la nube trabaja por adelantado para refactorizar y agregar un entorno conectado que trata la nube como una red perimetral.
• Antes de que el equipo de adopción pueda lanzar su primera carga de trabajo de producción, el equipo de seguridad necesita una revisión de seguridad. Mientras el equipo de adopción implementa las 10 primeras cargas de trabajo, el equipo de la plataforma avanza para definir e implementar los requisitos de seguridad.
• En el momento en que se libera la primera carga de trabajo para producción, ambos equipos deben tener suficientes conocimientos para prepararse para un modelo de servicio compartido más a largo plazo. La centralización de las arquitecturas de servicio principales le ayudará a alinear al equipo de operaciones y gobernanza. La centralización de los servicios principales le ayudará a preparar el equipo de adopción para escalar y liberar las siguientes olas de cargas de trabajo de producción.
• A medida que el equipo se aproxima a su objetivo de migrar 100 cargas de trabajo, el equipo comenzará a avanzar de forma natural hacia una estructura de equipo y modelo de colaboración de excelencia más centrado en la nube.

La configuración de un entorno preparado para la empresa llevará tiempo. Este enfoque no eliminará ese requisito. En su lugar, este enfoque está diseñado para quitar los bloqueadores iniciales y crear oportunidades para que los equipos de plataforma y adopción aprendan juntos.

Protección de la refactorización de las zonas de aterrizaje

Todas las plantillas de la zona de aterrizaje iniciales tienen limitaciones. Las protecciones o las directivas durante la refactorización deben reflejar esas limitaciones. Antes de comenzar un proceso de refactorización de zona de aterrizaje, es importante comprender los requisitos a largo plazo del plan de adopción en la nube y la clasificación de las cargas de trabajo candidatas, en comparación con las limitaciones de las plantillas iniciales.

Como ejemplo de establecimiento de protecciones de refactorización, comparemos el enfoque de desarrollo del ejemplo anterior y el plano técnico de la zona de aterrizaje de migración de CAF.

• En lo que se refiere a los supuestos del plano técnico de la zona de aterrizaje de migración de CAF, esta zona de aterrizaje inicial no está diseñada para cargas de trabajo críticas ni datos confidenciales. Estas características se deberán agregar mediante refactorización.
• En este ejemplo, supongamos que la cartera de 100 cargas de trabajo requerirá funcionalidades de hospedaje de datos críticos y confidenciales.

Para equilibrar estos dos requisitos competitivos, los equipos de adopción y plataforma trabajarán con las siguientes condiciones acordadas:

• El equipo de adopción en la nube priorizará las cargas de trabajo de producción que no tienen acceso a datos confidenciales y no se consideran críticas.
• Antes de la versión de producción, el equipo de seguridad y operaciones validará la alineación con la directiva anterior.
• El equipo de plataforma en la nube trabajará con los equipos de seguridad y gobernanza para implementar una línea de base de seguridad. Una vez que la seguridad apruebe la implementación, se borrará el equipo de adopción para migrar las cargas de trabajo que tengan acceso a algunos datos confidenciales.
• El equipo de plataforma en la nube trabajará con el equipo de operaciones para implementar una línea de base de administración. Una vez que el equipo de operaciones apruebe la implementación, el equipo de adopción podrá migrar las cargas de trabajo con un nivel más alto de importancia.

En este ejemplo, el conjunto anterior de condiciones acordadas permitirá que el equipo de adopción empiece a trabajar en la migración. También ayuda al equipo de plataforma a dar forma a sus interacciones con otros equipos a medida que avanzan hacia un entorno listo para la empresa más a largo plazo.

Refactorización y cumplimiento de los requisitos a largo plazo

La sección de la metodología de protección para mejorar la zona de aterrizaje le ayudará a avanzar hacia los requisitos a largo plazo. A medida que el equipo de adopción de la nube progrese en su plan de adopción, consulte Expansión de una zona de aterrizaje para obtener instrucciones que ayuden a tomar decisiones y realice la refactorización para dar respuesta a los requisitos cambiantes de los diversos equipos.

Figura 5: Metodologías más detalladas que ayudan a una iteración paralela de zonas de aterrizaje.

Cada subsección de Expansión de la zona de aterrizaje se corresponde a una de las adiciones descritas en la imagen anterior. Más allá de esas expansiones básicas, las metodologías más profundas (como las de gobernanza o administración) de este marco de trabajo le ayudarán a ir más allá de las modificaciones básicas de la zona de aterrizaje para implementar materias a largo plazo.

Pasos siguientes

Para empezar a trabajar en un proceso de refactorización, comience por usar las zonas de aterrizaje de Azure.

Zonas de aterrizaje de Azure