La filosofía Two-Pizza Team y la separación de servicios - Por qué AWS mantiene la calidad en más de 200 servicios
Examinamos cómo el Two-Pizza Team, fundamento del diseño organizacional de AWS, contribuye a la independencia y calidad de los servicios, comparándolo con el enfoque de integración de Azure y la estructura organizacional de GCP.
La estructura organizacional determina la estructura del software
La ley de Conway establece que las organizaciones diseñan sistemas que reflejan su estructura de comunicación. Esta ley se aplica claramente al diseño de servicios de los proveedores cloud. Que AWS tenga más de 200 servicios, cada uno con API independientes y ciclos de lanzamiento independientes, se debe a que la estructura organizacional de AWS está diseñada de esa manera. AWS se organiza en unidades básicas llamadas Two-Pizza Teams, equipos de pequeña escala. Cada equipo tiene responsabilidad completa sobre un servicio o componente principal de un servicio, realizando de forma autónoma el diseño, desarrollo, pruebas, despliegue y operación. Este diseño organizacional es la base estructural que sustenta la independencia y calidad de los servicios de AWS.
Principios de diseño del Two-Pizza Team
El nombre Two-Pizza Team proviene de un equipo lo suficientemente pequeño como para alimentarse con dos pizzas, normalmente entre 6 y 10 personas. Este tamaño tiene una intención de diseño clara. Primero, la minimización del costo de comunicación. A medida que aumenta el número de miembros, las rutas de comunicación crecen exponencialmente y la velocidad de toma de decisiones disminuye. En equipos pequeños, todos comparten el mismo contexto y pueden tomar decisiones rápidamente. Segundo, la clarificación de la propiedad. Al tener cada equipo responsabilidad completa sobre un servicio, se elimina la situación de no saber de quién es la responsabilidad. La calidad, disponibilidad y rendimiento del servicio son responsabilidad del equipo, y la respuesta ante problemas es rápida. Tercero, el fomento de la innovación. Los equipos pequeños no están atados a procesos de aprobación de grandes organizaciones y pueden experimentar y mejorar rápidamente. El ciclo desde la idea hasta la implementación y despliegue es corto, permitiendo reflejar rápidamente el feedback de los clientes.
Ventajas técnicas de la separación de servicios
El diseño organizacional del Two-Pizza Team se refleja directamente en la arquitectura de los servicios. Cada servicio tiene su propio código base, pipeline de despliegue y almacén de datos independientes. La comunicación entre servicios se realiza a través de APIs claramente definidas, ocultando los detalles de implementación interna. Esta separación minimiza el riesgo de que cambios en un servicio afecten inesperadamente a otros. Si el equipo de S3 modifica la implementación interna de S3, no afecta a EC2 ni a Lambda. Como cada servicio puede escalar y recuperarse de fallos de forma independiente, la tolerancia a fallos del sistema completo mejora. La independencia de lanzamientos también es importante. Cada equipo puede desplegar nuevas funcionalidades y correcciones de errores a su propio ritmo sin depender del calendario de lanzamiento de otros equipos. Que AWS pueda realizar miles de despliegues al año se debe a estos ciclos de lanzamiento independientes.
Contraste con el enfoque de integración de Azure
El diseño de servicios de Azure tiende a ser más orientado a la integración, en contraste con AWS. Azure Portal proporciona una experiencia integrada para operar todos los servicios desde una única interfaz de gestión, con servicios diseñados con una estrecha interconexión. Esta integración ofrece la ventaja de una experiencia de operación consistente para los usuarios, pero como contrapartida, conlleva el desafío de que las dependencias entre servicios se vuelven fácilmente complejas. En casos de fallos de Azure, se han reportado situaciones donde un problema en un servicio se propaga en cascada a otros. En la gran interrupción de Azure de 2023, un problema en la infraestructura de autenticación afectó ampliamente a Azure Portal, Azure DevOps, Microsoft 365 y otros servicios. Este es un riesgo estructural donde el radio de explosión de los fallos se amplía debido a la estrecha integración entre servicios. La estructura organizacional de Microsoft también influye en el diseño de Azure. Azure es una división de Microsoft y se requiere coordinación con otras unidades de negocio como Office, Windows y Dynamics. Esta demanda de integración organizacional refuerza la orientación integradora del diseño de servicios.
Estructura organizacional y diseño de servicios de GCP
GCP opera como la división cloud de Google y está fuertemente influenciado por la cultura técnica de Google. Google tiene un historial de operación de sistemas distribuidos a gran escala internamente, y los servicios de GCP nacen de la externalización de esa tecnología. Que GCP tenga menos servicios que AWS o Azure se debe a que Google adopta un enfoque de pocos pero excelentes. En lugar de ofrecer muchos servicios especializados, la estrategia es ofrecer pocos servicios de alta versatilidad y elevar la calidad de cada uno. BigQuery, GKE y Spanner son ejemplos exitosos de esta estrategia. Sin embargo, este enfoque tiene el desafío de que es difícil responder a requisitos de nicho de los clientes. Mientras AWS ofrece más de 15 servicios de bases de datos por caso de uso, GCP intenta cubrir con un número relativamente pequeño como Cloud SQL, Cloud Spanner, Bigtable y Firestore. Cuando no existe un servicio optimizado para un caso de uso específico, los clientes deben conformarse con un servicio genérico o optimizar por su cuenta.
La cultura You Build It, You Run It
Un aspecto importante del Two-Pizza Team es el principio You Build It, You Run It (quien lo construye, lo opera). En AWS, el equipo que desarrolla un servicio también es responsable de su operación. A diferencia de la estructura organizacional tradicional donde los equipos de desarrollo y operación están separados, los propios desarrolladores realizan guardias y responden a incidentes. Los efectos de este principio son tres. Primero, la mejora de la calidad operativa. Si los desarrolladores saben que pueden ser despertados a medianoche, escriben código más robusto y configuran monitoreo y alertas más completos. Segundo, el acortamiento del ciclo de feedback. Los problemas descubiertos durante la operación pueden ser corregidos directamente por los desarrolladores, reduciendo el tiempo desde el reporte hasta la corrección. Tercero, la mejora de la calidad del diseño. Los desarrolladores que conocen las dificultades de la operación diseñan pensando en la operabilidad desde el principio. La salida de logs, recopilación de métricas y facilidad de cambio de configuración se diseñan naturalmente considerando la operabilidad. Azure y GCP también promueven la cultura DevOps, pero no tienen el principio de que los desarrolladores operan institucionalizado a nivel de estructura organizacional como AWS. Para aprender sobre diseño de equipos y teoría organizacional, los libros relacionados (Amazon) también pueden ser útiles.
Resumen
El Two-Pizza Team de AWS institucionaliza a nivel de estructura organizacional el desarrollo y operación autónomos de servicios por equipos pequeños. Este diseño logra una estructura donde más de 200 servicios mantienen cada uno su propia calidad y ritmo de evolución independientes, y el alcance del impacto de los fallos se limita. El enfoque de integración de Azure proporciona una experiencia de operación consistente pero conlleva el riesgo de cascada de fallos. El enfoque de pocos pero excelentes de GCP eleva la calidad de cada servicio individual pero no alcanza a AWS en capacidad de respuesta a requisitos de nicho. Al evaluar la calidad y evolución a largo plazo de una plataforma cloud, comprender la filosofía de diseño organizacional subyacente es tan importante como la comparación de funcionalidades.