Topologías de equipos de DevOps

La distribución de roles, responsabilidades y confianza entre los equipos de TI central y los equipos de las aplicaciones es primordial para la transformación operativa involucrada al adoptar la nube a gran 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 en gran medida en el éxito del modelo operativo en la nube.

Según la ley de Conway, los equipos generan arquitecturas basadas en su estructura de comunicación. Comprender este principio es fundamental a medida que trabaja para lograr el equilibrio necesario entre autonomía y control. Ley de Conway: cualquier organización que diseña un sistema (definido ampliamente) genera un diseño cuya estructura es una copia de la estructura de comunicación de la organización.

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

• Arquitectura evolucionista que admite cambios constantes
• Implementabilidad
• Capacidad de prueba

La solución de Conway es burlar la ley de Conway. Si su organización sigue una estructura determinada para producir servicios y productos y está buscando optimizar, debe replantear 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.

Tipo de equipo	Definición
Equipos de carga de trabajo de aplicaciones	Estos equipos crean aplicaciones que impulsan los resultados empresariales directos para un segmento del dominio empresarial. En el contexto de las zonas de aterrizaje de Azure, estos equipos son responsables del ciclo de vida completo de las cargas de trabajo de la aplicación.
Equipos de plataforma	Estos equipos crean plataformas internas atractivas para acelerar la entrega y reducir la carga cognitiva de los equipos de carga de trabajo de aplicaciones. En el contexto de las zonas de aterrizaje de Azure, estos equipos son responsables del ciclo de vida completo de la zona de aterrizaje de Azure.
Habilitación de equipos	Estos equipos ayudan a superar las brechas de aptitudes al ayudar a otros equipos con funcionalidades especializadas, como DevOps.

Consideraciones de diseño

• Establezca un equipo de plataforma multiplataforma para diseñar, compilar, aprovisionar, administrar y mantener el ciclo de vida de la zona de aterrizaje de Azure. En este equipo se deben incluir miembros del equipo de TI central, seguridad, cumplimiento y unidades de negocio para asegurarse de que esté representado un amplio espectro de la empresa. Asegúrese de evitar los antipatrones.

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

• No restrinja los equipos de carga de trabajo de la aplicación a artefactos centrales, ya que puede dificultar su agilidad. Puede usar la gobernanza controlada por directivas y el control de acceso basado en rol de Azure (RBAC de Azure) para aplicar configuraciones de línea base coherentes y asegurarse de que los equipos de aplicación (unidad de negocio) sean lo suficientemente flexibles como para innovar, pero aún así capaces de extraer de un conjunto predefinido de plantillas.

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

• La aplicación global de un modelo de DevOps no establece de forma instantánea equipos con capacidad de DevOps.

• Invertir en capacidades y recursos de ingeniería es fundamental.

• Los equipos de aplicación de algunas aplicaciones heredadas pueden no tener 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
• El aprovisionamiento y la delegación de suscripciones de la red necesaria, la administración de identidades y acceso, las directivas
• Administración y supervisión de la plataforma (holística)
• Cost Management (holístico)
• Plataforma como código (administración de plantillas, scripts y otros recursos)
• Operaciones generales en Microsoft Azure dentro del inquilino de Microsoft Entra (administración de entidades de servicio, registro de Microsoft Graph API y definiciones de roles)
• RBAC de Azure (holístico)
• 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 red (holística)

Definición de funciones para los equipos de carga de trabajo de la aplicación

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

• Creación y administración de recursos de aplicación a través de un modelo de DevOps
• Administración de bases de datos
• Migración o transformación de la aplicación
• Administración y supervisión de la aplicación (recursos de la aplicación)
• RBAC de Azure (recursos de la aplicación)
• Supervisión y auditorías de seguridad (recursos de la aplicación)
• Administración de secretos y claves (claves de aplicación)
• Administración de costos (recursos de la aplicación)
• Administración de redes (recursos de la 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 los demás 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, formación y entrenamiento para que otros equipos alcancen el nivel necesario de experiencia
• Establecimiento de un conjunto común de plantillas y bibliotecas reutilizables para los equipos de aplicaciones o plataformas, y promoción de innerSourcing, como los módulos verificados de Azure.

Definición de 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 de equipo:

Modo de interacción	Descripción
Colaboración	Los equipos trabajan estrechamente juntos.
X como servicio	Los equipos consumen o proporcionan algo a otros equipos con una colaboración mínima, similar a las interacciones del proveedor de terceros.
Facilitación	Otro equipo ayuda o recibe la ayuda de otro equipo para eliminar los impedimentos.