Compartir a través de

Plan para las plataformas de aplicaciones modernas

  • Artículo

La metodología del plan de Cloud Adoption Framework ayuda a crear un plan de adopción de la nube general para orientar los programas y equipos implicados en la transformación digital basada en la nube. En esta guía se proporcionan plantillas para crear el trabajo pendiente y planes para generar las aptitudes necesarias en los equipos, todo ello en función de lo que está intentando hacer en la nube.

La aplicación de la metodología del plan se centra en las cinco R de racionalización del patrimonio digital. El camino más habitual a la nube se centra en la velocidad, la eficiencia y la repetibilidad de los procesos de migración y modernización. A partir de las cinco R, el planeamiento suele priorizar las opciones de rehospedaje con compatibilidad paralela limitada para las opciones de rediseño y recompilación.

Patrimonio digital

A la hora de planear el patrimonio digital, es recomendable recopilar datos de inventario y racionalizar este patrimonio. En un plan de adopción de contenedores, es fundamental que todos los recursos (por ejemplo, VM, datos y aplicaciones) estén agrupados por la carga de trabajo que admiten. Una vez completada la racionalización básica y la agrupación, puede evaluar estas cargas de trabajo para determinar las opciones de empaquetado y rehospedaje o rediseño.

La plantilla de plan de adopción de la nube estándar tiene en cuenta los tipos de trabajo necesarios en un esfuerzo típico de adopción en la nube. Sin embargo, deberá agregar tareas al plan para empaquetar la carga de trabajo en contenedores y la orquestación del aprovisionamiento de los contenedores.

Precaución

En este artículo se da por supuesto que el lector ya está siguiendo los procedimientos recomendados descritos en la serie de artículos sobre la creación de un plan de adopción de la nube en Azure DevOps. Si está realizando un seguimiento del plan de adopción de la nube en una hoja de cálculo u otra herramienta de seguimiento de proyectos, las secciones siguientes seguirán siendo de aplicación, pero será necesario ajustar los pasos que se pueden realizar para agregar datos al plan.

Advertencia

La incorporación de una estrategia de plataforma de aplicaciones moderna en procesos de migración estándar (o una factoría de migración) requiere una implementación madura de las tareas asociadas con el diseño de arquitecturas de cargas de trabajo antes de la migración. Si se continúa con esta estrategia sin esas tareas, se retrasará el esfuerzo de migración y podrían tomarse decisiones de arquitectura deficientes para los hosts de contenedor implementados y las cargas de trabajo auxiliares.

Identificación de cargas de trabajo candidatas

En el escenario de la plataforma de aplicaciones modernas, la rentabilidad a largo plazo, que requiere una mayor inversión inicial, tiene prioridad sobre los procesos de migración más eficaces. Las inversiones a largo plazo se representan en partes específicas del plan con especial atención a la capacidad de innovar y la racionalización de las operaciones para grupos específicos de cargas de trabajo.

Para empezar a alinear la estrategia y el plan, identifique las cargas de trabajo que probablemente se verán afectadas por la incorporación de plataformas de aplicaciones modernas en la estrategia de adopción de la nube. Estas suposiciones se validarán antes de implementar cambios técnicos. Para ayudar a identificar posibles candidatas, busque los siguientes criterios dentro de la cartera de cargas de trabajo:

  • Desarrollo activo o inversiones en DevOps: un porcentaje de las cargas de trabajo de producción se encontrará en desarrollo activo. Algunas incluso se pueden administrar mediante procedimientos de DevOps continuos.
  • Portabilidad de cargas de trabajo: algunas cargas de trabajo se ven afectadas por restricciones operativas, de cumplimiento o de protección de datos, que pueden requerir portabilidad entre la nube privada, el perímetro o incluso varios proveedores de nube pública.
  • Consolidación de cargas de trabajo: muchas cargas de trabajo (especialmente las cargas de trabajo de uso reducido) pueden ser candidatas para la consolidación en hosts de contenedor, por lo que se requieren pocos servidores o máquinas virtuales y se reducen los costos operativos.
  • Cargas de trabajo heredadas: las cargas de trabajo heredadas pueden bloquear las actualizaciones de los sistemas operativos e incluso impedir la migración a la nube. Las cargas de trabajo heredadas que no son compatibles con las características de Azure podrían ser candidatas para la migración en un host de contenedor.

Documentación de cargas de trabajo candidatas

Nota:

La siguiente lista de consideraciones solo debe documentarse para las candidatas de migración identificadas por los criterios anteriores.

Al crear un plan de adopción de la nube, cada carga de trabajo se documenta siguiendo la guía de Definición y clasificación de las cargas de trabajo. Cualquier carga de trabajo que sea candidata para el escenario de la plataforma de aplicaciones modernas requerirá información adicional para guiar la ejecución del plan. En este artículo se subraya la importancia de documentar las entradas de negocio y técnicas para definir la carga de trabajo. En el caso de las candidatas a la plataforma de aplicaciones modernas, se deben agregar los siguientes puntos de datos a la definición de la carga de trabajo.

Entradas de negocio

Los siguientes son puntos de datos relacionados con el negocio que pueden influir en la decisión de incluir una carga de trabajo en la estrategia de la plataforma de aplicaciones modernas.

  • Factores de cumplimiento: ¿Qué criterios de cumplimiento específicos respaldan las consideraciones para hospedar esta carga de trabajo en una nube privada?
  • Factores de protección de datos: ¿Qué medidas de protección de datos respaldan las consideraciones para hospedar esta carga de trabajo en una nube privada?
  • Restricciones operativas: ¿Qué restricciones operativas respaldan las consideraciones para hospedar esta carga de trabajo en una nube privada?
  • Resultados de la plataforma de aplicaciones moderna: ¿Cuál de los siguientes factores es el que respalda la evaluación de esta carga de trabajo como candidata de contenedor? DevOps, portabilidad, consolidación, heredada o varios de estos factores.
  • Modelo operativo: ¿Esta carga de trabajo se administrará centralmente (mediante TI/CCoE central), de forma descentralizada (por equipo de carga de trabajo) o con operaciones empresariales (soporte central y operaciones específicas de la carga de trabajo)?

Entradas técnicas

Los siguientes son puntos de datos de los equipos tecnológicos que pueden influir en la decisión de incluir una carga de trabajo en la estrategia de la plataforma de aplicaciones modernas.

Consideraciones de ubicación:

Consideraciones relacionadas con dónde se hospedará la carga de trabajo.

  • Requisito de hospedaje en la nube pública: ¿hay una restricción técnica específica asociada al requisito de nube pública?
  • Requisito de hospedaje en la nube privada: ¿hay una restricción técnica específica asociada al requisito de nube privada?
  • Requisito de hospedaje perimetral: ¿hay una restricción técnica específica asociada al requisito del perímetro?
  • Requisito de portabilidad: ¿hay una restricción técnica específica asociada al requisito de portabilidad de la nube?

Consideraciones sobre las operaciones:

Consideraciones relacionadas con las operaciones de la plataforma, los hosts y las cargas de trabajo.

  • Plataforma en la nube principal: las organizaciones deben definir una plataforma en la nube principal para proporcionar herramientas de administración de operaciones. Algunas organizaciones pueden tener más de una plataforma en la nube principal para administrar varios tipos de operaciones. ¿Cuál es la plataforma en la nube principal para administrar las operaciones con esta carga de trabajo?
  • Plataformas de operaciones adicionales: ¿esta carga de trabajo también se administrará mediante plataformas de operaciones adicionales?
  • Requisitos de hospedaje en la nube: ¿requiere esta carga de trabajo una estrategia de hospedaje en la nube específica? Nube pública, nube privada o portabilidad de la nube
  • Plataforma de orquestación estandarizada: si la empresa tiene una solución estándar para la orquestación de contenedores, incluya el nombre de la plataforma estandarizada para su consideración. Ejemplos: Azure Kubernetes Service (AKS), el motor de AKS o Kubernetes.
  • Consideraciones sobre la orquestación personalizada: ¿existe algún requisito para una plataforma de orquestación de contenedores no estándar? Si es así, explique ese requisito.
  • Operaciones de host estandarizadas: se presupone que las cargas de trabajo no son hostiles y pueden hospedarse en contenedores compartidos compatibles con las operaciones de host estandarizadas. ¿Esta carga de trabajo es compatible con este enfoque?
  • Consideraciones sobre las operaciones de host personalizadas: si la carga de trabajo no es compatible con las operaciones estandarizadas, ¿qué requisitos específicos se deben tener en cuenta al establecer prácticas de operaciones de host para esta carga de trabajo?

Consideraciones sobre la aplicación:

Consideraciones específicas acerca de cómo se ha desarrollado la aplicación y cómo se desarrollará en el futuro.

  • Entorno de ejecución de plataforma como servicio (PaaS): los proveedores de nube pública generan entornos de ejecución de aplicaciones coherentes, a menudo denominados ofertas de plataforma como servicio (PaaS). En Azure, Azure App Service proporciona los entornos de ejecución de PaaS. ¿Podría esta aplicación operar en un entorno de ejecución de PaaS? ¿Qué entorno de ejecución es más compatible?
  • Entorno de ejecución estandarizado: si la aplicación no es compatible con un entorno de ejecución de PaaS, ¿existe un entorno de ejecución estandarizado proporcionado por la organización? ¿En qué entorno de ejecución se compilará esta carga de trabajo?
  • Consideraciones sobre el entorno de ejecución personalizado: ¿qué consideraciones específicas requerirían un entorno de ejecución personalizado para esta carga de trabajo?
  • Restricciones del entorno de ejecución: ¿impone el entorno de ejecución elegido alguna restricción a la aplicación?
  • Dependencias de la aplicación: ¿depende esta carga de trabajo de sistemas existentes que residen en una ubicación específica (por ejemplo, pública o privada)? Un ejemplo sería un sistema ERP, como SAP en ejecución en una solución específica.
  • Gravedad de los datos: ¿depende esta carga de trabajo de un origen de datos que reside en una ubicación específica (por ejemplo, pública o privada)? Un ejemplo podría ser una dependencia de los datos de SAP u otros orígenes de datos centralizados.
  • Consideraciones sobre listas aprobadas: ¿se han aprobado las consideraciones sobre las operaciones personalizadas para su uso dentro de la plataforma en la nube? ¿Qué servicios aprobados deben incluirse en la implementación?

Consideraciones sobre los contenedores iniciales

Empaquetar las cargas de trabajo en contenedores es el primer trabajo que se debe programar y en el que se debe trabajar. El segundo es planear el hospedaje de esos contenedores.

Soluciones de PaaS para orquestación, operaciones y entornos de ejecución estandarizados

Algunas cargas de trabajo están muy autocontenidas y no tienen por qué beneficiarse de los controles avanzados y los requisitos de infraestructura de una gran plataforma como Kubernetes. El hecho de que la carga de trabajo esté en contenedores no significa que se deba implementar en Kubernetes. Azure proporciona una variedad de soluciones para ejecutar cargas de trabajo dentro de su cartera que no requieren el nivel de administración e infraestructura que requiere AKS. Cada una de las siguientes soluciones sigue este enfoque a la planeación:

Considere la posibilidad de usar una solución más ligera para los contenedores con cargas de trabajo cuya complejidad no está previsto que aumente y que se alinee con los fines y los límites de estas soluciones.

Orquestación estandarizada con operaciones y entornos de ejecución personalizados en la nube pública

Para las cargas de trabajo que no se pueden ejecutar en una plataforma de PaaS totalmente administrada y que dependen de controles de nivel de infraestructura, el deseo de usar características de implementación avanzadas, como las ofrecidas por los orquestadores de contenedores, o la previsión de aumentar la complejidad modular, conducen a Azure Kubernetes Service (AKS). AKS es una solución para el hospedaje de contenedores, pero también proporciona muchas opciones de arquitectura, SRE, seguridad, implementación, supervisión e infraestructura.

El conjunto de características de la plataforma incluye el requisito de conocer la plataforma tanto en el nivel de operador de clúster como en el de carga de trabajo. Factorice la educación de los equipos de operaciones, de arquitectura y de ingeniería de cargas de trabajo en escalas de tiempo de migración. Además, dado que AKS es una plataforma, asegúrese de que los equipos de cargas de trabajo entienden la separación de responsabilidades dentro de esta plataforma en relación con su disposición de hospedaje actual. Puede que sea similar de alguna forma, pero es probable que sea nueva en otros aspectos.

Orquestación, operaciones y entornos de ejecución personalizados en la nube pública

En el caso de cargas de trabajo muy especializadas o requisitos específicos de la organización, Azure ofrece otras dos plataformas principales en el espacio de orquestación de contenedores.

  • Red Hat OpenShift en Azure
  • Azure Service Fabric

Si hay alguna razón para explorar alternativas, asegúrese de dedicar el tiempo necesario a comprender las ventajas e inconvenientes de todas las opciones de la plataforma. La solución predeterminada de Azure es AKS y en esta documentación se asume que AKS es la tecnología elegida.

Estandarización de operaciones entre plataformas en la nube

A menudo, los clientes implementarán diferentes orquestadores de contenedores en entornos de nube privada, perimetrales y de nube pública. Para estandarizar las operaciones entre esas distintas plataformas en la nube, los clientes pueden incorporar un enfoque de operaciones unificado mediante la ampliación de sus herramientas de operaciones en la nube a varias plataformas en la nube.

En Azure, las organizaciones pueden estandarizar las operaciones entre varios orquestadores mediante la incorporación de hosts de contenedor dispares en Azure Arc para Kubernetes. Esta herramienta garantiza una supervisión, operaciones y gobernanza coherentes en cada host de contenedor.

Entornos de ejecución de aplicaciones en entornos perimetrales y de nube privada

Si las cargas de trabajo deben ejecutarse en un entorno perimetral o de nube privada, pero la carga de trabajo es más compatible con un entorno de ejecución de PaaS, existen algunas herramientas que pueden permitir a los desarrolladores compilar sobre entornos de ejecución de PaaS coherentes mediante Azure App Service:

  • Azure Stack HCI: permite hospedar Azure App Service de forma nativa en Azure Stack, administrado por el operador de Azure Stack.
  • Azure Stack HCI para AKS: permite hospedar entornos de ejecución personalizados que se ejecutan en AKS dentro de Azure Stack, administrados por operadores de Azure Stack y AKS para permitir la portabilidad a otras soluciones de Kubernetes.
  • Azure App Service en Kubernetes con Azure Arc: permite que cualquier host de Kubernetes proporcione servicios de aplicación en Azure. Todos los hosts se convierten en una pequeña instancia de Azure App Service. Puesto que cada host también se incorpora a Azure Arc, esos hosts también se pueden administrar mediante operaciones de host coherentes basadas en la nube.

Plan de preparación de la plataforma de aplicaciones moderna

Además del plan de aptitudes para la adopción de la nube, es posible que los equipos de adopción de la nube necesiten desarrollar aptitudes relacionadas con los contenedores y Kubernetes antes de ejecutar el plan:

Asegúrese de asignar el tiempo necesario para que los equipos de carga de trabajo documenten y simulen los planes de migración. Es posible que la aplicación o el sistema externo existente (tanto las dependencias como los sistemas que dependen de esta carga de trabajo) deban modificarse con mayor flexibilidad para admitir el esfuerzo de migración. Esto se aplica tanto a los entornos de preproducción como a los de producción.

Paso siguiente: revise el entorno o la zona de aterrizaje de Azure.

La siguiente lista de artículos le proporcionará orientación para puntos específicos del proceso de adopción en la nube que le ayudarán a completarlo correctamente.