Escalado vertical de la infraestructura de Azure DevTest Labs

La orquestación de una implementación correcta de DevTest Labs a escala empresarial requiere tener en cuenta los puntos de decisión clave y planear un enfoque para la implementación rápida de Azure DevTest Labs.

En este artículo se describen los puntos de decisión clave que debe tener en cuenta al planear la implementación y se proporciona un enfoque recomendado para ello.

Puntos clave de decisión

Antes de implementar DevTest Labs a escala empresarial, hay varias decisiones clave. Reconocer estos puntos de decisión a un nivel alto ayuda a las organizaciones con las decisiones de diseño en el futuro. De todas formas, estas decisiones no deberían evitar que una organización iniciara una prueba de concepto.

Las tres áreas principales para el planeamiento del escalado vertical inicial son:

• Redes y seguridad
• Topología de la suscripción
• Roles y responsabilidades

Redes y seguridad

La seguridad y las redes son una parte fundamental en todas las organizaciones. Aunque una implementación en toda la empresa requiere un análisis más profundo, hay un número reducido de requisitos para realizar correctamente una prueba de concepto. Algunas áreas de enfoque clave incluyen:

• Suscripción de Azure: para implementar DevTest Labs, debe tener acceso a una suscripción de Azure con los derechos adecuados para crear recursos. Hay varias maneras de obtener acceso a suscripciones de Azure, como un Contrato Enterprise y una opción de Pago por uso. Para obtener más información sobre cómo obtener acceso a una suscripción de Azure, vea las licencias de Azure para la empresa.
• Acceso a recursos locales: algunas organizaciones requieren que sus recursos de DevTest Labs tengan acceso a recursos locales. Se necesita una conexión segura desde el entorno local a Azure. Es importante configurar una VPN o una conexión de Azure ExpressRoute antes de empezar. Para más información, vea Información general sobre Virtual Network.
• Otros requisitos de seguridad: otros requisitos de seguridad, como las directivas de equipo, el acceso a direcciones IP públicas y la conexión a Internet, son escenarios que se deben revisar antes de implementar una prueba de concepto.

Topología de la suscripción

La topología de la suscripción es una consideración de diseño fundamental a la hora de implementar DevTest Labs en la empresa. Pero no es necesario consolidar todas las decisiones hasta después de haber completado una prueba de concepto. Al evaluar el número de suscripciones necesarias para una implementación empresarial, hay dos extremos:

• Una suscripción para toda la organización
• Suscripción por usuario

A continuación se resaltan las ventajas de cada enfoque.

Una suscripción

A menudo, el enfoque de una suscripción no es fácil de administrar en una gran empresa. Sin embargo, la limitación del número de suscripciones proporciona las siguientes ventajas:

• Previsión de los costos de la empresa. Realizar presupuestos resulta mucho más sencillo en una sola suscripción porque todos los recursos están en un único grupo. Este enfoque permite simplificar la toma de decisiones sobre cuándo adoptar medidas de control de costos en un momento dado de un ciclo de facturación.
• La administración de máquinas virtuales, artefactos, fórmulas, configuraciones de red, permisos y directivas es más fácil, ya que todas las actualizaciones son necesarias solo en una suscripción, en lugar de tener que realizar actualizaciones en varias suscripciones.
• El esfuerzo de red es más sencillo en una suscripción única en aquellas empresas donde la conectividad local es un requisito. La conexión de redes virtuales entre suscripciones (modelo en estrella tipo hub-and-spoke), necesaria con suscripciones adicionales, requiere más configuración, administración y espacios de direcciones IP.
• La colaboración del equipo es más fácil cuando todos los usuarios trabajan en la misma suscripción. Por ejemplo, es más sencillo reasignar una máquina virtual a un compañero de trabajo o compartir recursos de equipo.

Suscripción por usuario

Una suscripción independiente por usuario proporciona igualdad de oportunidades en el espectro de alternativo. Las ventajas de tener muchas suscripciones incluyen:

• Las cuotas de escalado de Azure no evitan la adopción. Por ejemplo, en el momento en que se escribe este artículo, Azure admite 200 cuentas de almacenamiento por suscripción. Existen cuotas operativas para la mayoría de los servicios de Azure (muchas se pueden personalizar, otras no). En este modelo de una suscripción por usuario, es muy poco probable que se alcancen la mayoría de las cuotas. Para obtener más información sobre las cuotas de escalado de Azure actuales, vea: Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.
• Los contracargos a grupos o desarrolladores individuales son más sencillos, lo que permite a las organizaciones tener en cuenta los costos mediante su modelo actual.
• La propiedad y los permisos de los entornos de DevTest Labs son sencillos. Se proporciona a los desarrolladores el acceso de nivel de suscripción y son responsables de todo, como configuración de redes, directivas de laboratorio y administración de máquinas virtuales.

En la empresa, puede haber suficientes restricciones en los extremos del espectro. Por tanto, puede que deba configurar suscripciones de forma que se encuentre en el medio de estos extremos. Como procedimiento recomendado, el objetivo de una organización debe ser usar el número mínimo de suscripciones posible. Tenga en cuenta las funciones obligatorias que aumentan el número total de suscripciones. Una vez más, la topología de suscripción es fundamental para una implementación empresarial de DevTest Labs, pero no debe retrasar una prueba de concepto. Hay más detalles en el artículo de gobernanza sobre cómo decidir sobre la granularidad del laboratorio y la suscripción en la organización.

Roles y responsabilidades

Una prueba de concepto de DevTest Labs tiene tres roles principales con responsabilidades definidas: propietario de la suscripción, propietario de DevTest Labs, usuario de DevTest Labs y, opcionalmente, un colaborador.

• Propietario de la suscripción: el propietario de la suscripción tiene derechos para administrar una suscripción de Azure, como asignar usuarios, administrar directivas, crear y administrar la topología de red y solicitar aumentos de cuota. Para obtener más información, consulte este artículo.
• Propietario de DevTest Labs: el propietario de DevTest Labs tiene acceso administrativo completo al laboratorio. Esta persona es responsable de agregar o quitar usuarios, administrar la configuración de costos, la configuración de laboratorio general y otras tareas basadas en máquinas virtuales o artefactos. Un propietario de laboratorio también tiene todos los derechos de un usuario de DevTest Labs.
• Usuario de DevTest Labs: el usuario de DevTest Labs puede crear y consumir las máquinas virtuales del laboratorio. Estas personas tienen algunas funcionalidades administrativas mínimas en las máquinas virtuales que crean (iniciar, detener, eliminar y configurar sus máquinas virtuales). Los usuarios no pueden administrar máquinas virtuales de otros usuarios.

Orquestación de la implementación de DevTest Labs

En este sección se proporciona un enfoque recomendado para una rápida implementación de Azure DevTest Labs. La siguiente imagen resalta el proceso general como orientación prescriptiva observando la flexibilidad para admitir diversos escenarios y requisitos del sector.

Supuestos

En este artículo se supone que tiene los siguientes elementos antes de implementar un piloto de DevTest Labs:

• Suscripción de Azure: el equipo piloto tiene acceso a la implementación de recursos en una suscripción de Azure. Si las cargas de trabajo son solo de desarrollo y pruebas, se recomienda seleccionar la oferta Enterprise DevTest para otras imágenes disponibles y tarifas más bajas en máquinas virtuales Windows.
• Acceso local: por si es necesario, el acceso local ya se ha configurado. El acceso local puede realizarse a través de una conexión VPN de sitio a sitio o mediante ExpressRoute. La conectividad mediante ExpressRoute suele puede tardar muchas semanas en establecerse; se recomienda disponer de ExpressRoute antes de iniciar el proyecto.
• Equipos piloto: se identificaron los equipos de proyectos de desarrollo inicial que usan DevTest Labs junto con actividades de desarrollo o pruebas aplicables y se establecieron requisitos y objetivos para dichos equipos.

Hito 1: Establecer el diseño y la topología de red inicial

Lo primero a lo que hay que prestar atención al implementar una solución de Azure DevTest Labs es establecer la conectividad planeada para las máquinas virtuales. En los siguientes pasos se describen los procedimientos necesarios:

1. Defina los intervalos de direcciones IP iniciales que se asignan a la suscripción de DevTest Labs en Azure. Este paso requiere prever el uso esperado del número de máquinas virtuales, para poder proporcionar un gran bloque que sea suficiente para una futura expansión.
2. Identifique los métodos de acceso deseado en DevTest Labs (por ejemplo, acceso interno o externo). Un punto clave en este paso es determinar si las máquinas virtuales tienen direcciones IP públicas (es decir, si se puede acceder a ellas directamente desde Internet).
3. Identifique y establezca métodos de conectividad con el resto del entorno local y en la nube de Azure. Si el enrutamiento forzado con ExpressRoute está habilitado, es probable que las máquinas virtuales necesiten configuraciones de proxy adecuadas para atravesar el firewall corporativo.
4. Si las máquinas virtuales se van a unir a un dominio, determine si se deben unir a un dominio basado en la nube (por ejemplo, Microsoft Entra Directory Services) o a un dominio local. Si se trata de un dominio local, determine a qué unidad organizativa del directorio activo al que se van a unir las máquinas virtuales. Además, confirme que los usuarios tengan acceso para unirse, o bien establezca una cuenta de servicio que pueda crear registros de máquina en el dominio.

Hito 2: Implementar el laboratorio piloto

Cuando ya exista la topología de red, se puede crear el primer laboratorio o un laboratorio piloto mediante los siguientes pasos:

1. Cree un entorno inicial de DevTest Labs.
2. Determine los tamaños y las imágenes de máquina virtual permitidos para su uso con el laboratorio. Decida si se pueden cargar imágenes personalizadas en Azure para su uso con DevTest Labs.
3. Proteja el acceso al laboratorio mediante la creación de controles de acceso basados en roles (Azure RBAC) iniciales para el laboratorio (propietarios del laboratorio y usuarios del laboratorio). Se recomienda utilizar cuentas de Active Directory sincronizadas con Microsoft Entra ID para la identidad con DevTest Labs.
4. Configure DevTest Labs para usar directivas, como programaciones, administración de costos, máquinas virtuales reclamables, imágenes personalizadas o fórmulas.
5. Establezca un repositorio en línea como Azure Repos/Git.
6. Decida sobre el uso de repositorios públicos o privados o una combinación de ambos. Organice las plantillas JSON para las implementaciones y un sostenimiento a largo plazo.
7. Si es necesario, cree artefactos personalizados. Este paso es opcional.

Hito 3: Documentación, asistencia, aprendizaje y mejoras

Los equipos pilotos iniciales pueden requerir asistencia exhaustiva para empezar. Use sus experiencias para asegurarse de que cuenta con la documentación y la asistencia apropiadas para la implementación continua de Azure DevTest Labs.

1. Presente a los equipos pilotos sus nuevos recursos de DevTest Labs (demostraciones y documentación).
2. Según las experiencias de los equipos pilotos, planee y proporcione documentación según sea necesario.
3. Formalice el proceso de incorporación de equipos nuevos (creación y configuración de laboratorios, proporcionar acceso, etc).
4. Según la aceptación inicial, verifique si la previsión original de espacio de direcciones IP todavía es razonable y precisa.
5. Asegúrese de que se han llevado a cabo las revisiones de cumplimiento y seguridad apropiadas.

Pasos siguientes

Lea el siguiente artículo de esta serie: Gobernanza de la infraestructura de Azure DevTest Labs