Topologías de equipos de DevOps

La distribución de roles, responsabilidades y confianza entre los equipos de TI y los equipos de aplicaciones es fundamental para la transformación operativa implicada en la adopción de la nube a escala.

Los equipos de TI se esfuerzan por mantener el control. Los propietarios de aplicaciones buscan maximizar la agilidad. El equilibrio que establece en última instancia entre estos dos objetivos influye considerablemente en el éxito del modelo operativo en la nube.

Según la ley de Conway, los equipos generan arquitecturas en función de su estructura de comunicación. Comprender este principio es fundamental a medida que trabaja para lograr el equilibrio necesario entre la autonomía y el control. Cualquier organización que diseñe un sistema (definido ampliamente) generará una estructura de diseño que sea una copia de la estructura de comunicación de esa organización.

Desde una perspectiva de DevOps, las organizaciones deben optimizar para responder rápidamente a las necesidades de los clientes. Los equipos que poseen, diseñan e implementan sus aplicaciones y sistemas encuentran su mayor nivel de autonomía en arquitecturas con las siguientes características:

• Arquitectura evolucionista que admite cambios constantes
• Capacidad de implementación
• Capacidad de prueba

La solución de Conway es eludir estratégicamente la Ley de Conway. Si su organización sigue una estructura determinada para producir servicios y productos y está buscando optimizar, debe replantearse la estructura organizativa. Evolucione el equipo y la estructura organizativa para lograr la arquitectura deseada.

Este principio conduce a topologías de equipo diseñadas intencionadamente en las que los equipos son responsables del extremo a extremo de las aplicaciones, sistemas o plataformas que poseen para lograr la disciplina completa de DevOps.

En la tabla siguiente se proporciona una categorización simplificada de estos equipos.

Consideraciones de diseño

• Establezca un equipo de plataformas multiplataforma para diseñar, compilar, aprovisionar, administrar y mantener el ciclo de vida de la zona de aterrizaje de Azure. Este equipo puede incluir miembros del equipo de TI central, la seguridad, el cumplimiento y las unidades de negocio para asegurarse de que se representa un amplio espectro de su empresa. Asegúrese de evitar antipatrones.

• Considere la posibilidad de establecer un equipo de habilitación que pueda proporcionar funciones de DevOps para admitir aplicaciones y plataformas que no tengan funcionalidades de DevOps existentes o un caso empresarial para establecer una (por ejemplo, aplicaciones heredadas con funcionalidades de desarrollo mínimas).

• No restrinja a los equipos de trabajo de aplicaciones a recursos centrales, lo que podría dificultar su capacidad de respuesta ágil. Puede usar la gobernanza controlada por directivas y el control de acceso basado en roles de Azure (RBAC de Azure) para aplicar configuraciones de línea base coherentes y asegurarse de que los equipos de aplicaciones (unidad de negocio) sean lo suficientemente flexibles como para innovar, pero aún así capaces de dibujar a partir de un conjunto predefinido de plantillas.

• No obligue a los equipos de aplicación a usar un proceso central ni una canalización de aprovisionamiento para la creación de instancias o la administración de recursos de la aplicación. Los equipos existentes que ya dependen de una canalización de DevOps para la entrega de aplicaciones pueden seguir usando sus herramientas actuales. Recuerde que puede usar Azure Policy ayuda a aplicar los estándares de la organización y a evaluar el cumplimiento a escala y abordar las consideraciones de seguridad de los procesos de DevOps.

• La aplicación general de un modelo de DevOps no establece al instante equipos de DevOps compatibles.

• La inversión en capacidades y recursos de ingeniería es fundamental.

• Es posible que los equipos de aplicaciones para algunas aplicaciones heredadas no tengan los recursos de ingeniería necesarios para alinearse con una estrategia de DevOps.

Recomendaciones de diseño

Las secciones siguientes contienen recomendaciones de diseño para guiarle a medida que diseña las topologías de equipo.

Alineación de topologías de equipo con el modelo operativo en la nube

Asegúrese de alinear las topologías de equipo con el modelo operativo en la nube deseado.

Establezca un proceso básico para las revisiones de adecuación operativa para comprender completamente los problemas que pueden resultar de las estructuras del equipo.

Definición de funciones para el equipo de plataforma

En la lista siguiente se proporciona un conjunto recomendado de funciones para el equipo de plataforma responsable de las zonas de aterrizaje de Azure:

• Gobernanza de la arquitectura
• Aprovisionamiento de suscripciones y delegación de las políticas necesarias de administración de red, identidades y acceso
• Administración y supervisión de plataformas (holística)
• Administración de costos (holística)
• Plataforma como código (administración de plantillas, scripts y otros recursos)
• Operaciones generales en Microsoft Azure dentro de su entorno de Microsoft Entra (administración de principales de servicio, registro en la API de Microsoft Graph y definiciones de roles)
• RBAC de Azure (integral)
• Administración de claves para servicios centrales (protocolo simple de transferencia de correo y controladores de dominio)
• Administración y aplicación de directivas (holística)
• Supervisión y auditorías de seguridad (holística)
• Administración de redes (holística)

Definición de funciones para los equipos de carga de trabajo de aplicaciones

En la lista siguiente se proporciona un conjunto recomendado de funciones para los equipos de aplicaciones responsables de las cargas de trabajo de aplicaciones:

• Creación y administración de recursos de aplicación mediante un modelo de DevOps
• Administración de bases de datos
• Migración o transformación de aplicaciones
• Administración y supervisión de aplicaciones (recursos de aplicación)
• Control de Acceso Basado en Roles (RBAC) de Azure (recursos de aplicación)
• Supervisión y auditorías de seguridad (recursos de aplicación)
• Administración de secretos y claves (claves de aplicación)
• Administración de costos (recursos de aplicación)
• Administración de redes (recursos de aplicación)

Definición de funciones para habilitar equipos

En la lista siguiente se proporciona un conjunto recomendado de funciones para un equipo de habilitación responsable de ayudar a otros equipos:

• Definición de instrucciones y funcionalidades horizontales (entre funciones) para ayudar a adquirir la experiencia adecuada en toda la organización, lo que garantiza la alineación con el modelo operativo en la nube de destino general (como DevOps).
• Apoyo, capacitación y entrenamiento para otros equipos para alcanzar el nivel de experiencia necesario
• Establecimiento de un conjunto común de plantillas y bibliotecas reutilizables para los equipos de aplicaciones o plataformas, y fomentar innerSourcing, como módulos comprobados de Azure.

Definir modos de interacción entre equipos

Los objetivos de las interacciones entre los equipos son:

• Lograr autonomía
• Desbloquear dependencias
• Minimizar el tiempo de pérdida
• Evitar cuellos de botella

Las topologías de equipo describen tres modos de interacción del equipo: