Por qué AWS no integra sus servicios - La filosofía de diseño de Two-Pizza Team y la separación de servicios
Explicamos por qué AWS continúa ofreciendo más de 200 servicios individualmente, desde las perspectivas del API Mandate de Bezos, el principio organizacional de Two-Pizza Team y la Ley de Conway, y analizamos las ventajas y costos de la separación de servicios.
La pregunta de por qué hay tantos servicios similares
Hay una pregunta que todos los que empiezan a usar AWS inevitablemente se hacen. ¿Por qué existen tanto SQS como Kinesis si ambos manejan mensajes? ¿Por qué no se integran ECS y EKS si ambos ejecutan contenedores? ¿Por qué no se combinan CodeCommit, CodeBuild, CodeDeploy y CodePipeline en una sola herramienta? AWS, que comenzó en 2006 con solo S3 y EC2, ahora ofrece más de 200 servicios. Esta proliferación no es accidental ni resultado de una falta de planificación, sino una consecuencia inevitable de los principios organizacionales de Amazon.
El API Mandate de Bezos - Todo comenzó aquí
En 2002, la base de código de Amazon había crecido hasta convertirse en un monolito gigante, y las dependencias entre equipos se habían convertido en un cuello de botella para el escalado. Bezos emitió una directiva clara a todos los equipos: (1) Todos los equipos deben exponer sus datos y funcionalidades a través de interfaces de servicio. (2) Toda comunicación entre equipos debe pasar por estas interfaces. (3) No se permite el acceso directo a los almacenes de datos de otros equipos. (4) La tecnología específica no importa. (5) Todas las interfaces de servicio deben diseñarse desde el principio para ser externalizables. (6) Quien no cumpla será despedido. Este mandato transformó fundamentalmente la arquitectura de Amazon de un monolito a microservicios.
Two-Pizza Team y la Ley de Conway
Otro principio organizacional que Bezos introdujo fue el Two-Pizza Team. La regla es que un equipo debe ser lo suficientemente pequeño como para que todos puedan comer con 2 pizzas, es decir, entre 6 y 10 personas. Este pequeño equipo es responsable de todo el diseño, desarrollo y operación de un servicio. Aquí actúa la Ley de Conway. Esta ley, propuesta por Melvin Conway en 1967, establece que las organizaciones diseñan sistemas que reflejan su propia estructura de comunicación. Cuando un equipo pequeño e independiente posee un servicio, ese servicio se convierte en un módulo cohesivo con interfaces claras hacia el exterior.
Tres ventajas que aporta la separación de servicios
Primero, la independencia en la velocidad de lanzamiento. Como cada equipo puede desplegar su servicio de forma independiente, no depende del calendario de lanzamiento de otros equipos. La razón por la que AWS puede lanzar miles de mejoras funcionales al año es esta independencia. Segundo, la localización del radio de explosión de fallos. Cuando ocurre un fallo en un servicio, el impacto en otros servicios se minimiza. En la interrupción de S3 de 2017, muchos servicios se vieron afectados, pero esto demostró inversamente cuánto depende la industria de S3. Tercero, la granularidad de las opciones del cliente. Los clientes pueden seleccionar y combinar solo los servicios que necesitan.
El costo de la separación - Costo de aprendizaje y complejidad de integración
La separación de servicios también tiene costos claros. El más notable es el aumento del costo de aprendizaje. Al comenzar un nuevo proyecto, se requiere un tiempo considerable solo para entender las diferencias entre servicios similares y seleccionar el apropiado. Los modelos de precios también difieren por servicio, complicando las estimaciones de costos. También surge fricción en la integración entre servicios. Arquitecturas donde Lambda llama a DynamoDB, envía resultados a SQS y otro Lambda los procesa requieren configuración de permisos IAM, manejo de errores y diseño de reintentos en cada punto de conexión.
Implicaciones para el diseño de sus propios sistemas
La filosofía de separación de servicios de AWS también ofrece implicaciones para el diseño de sistemas propios. Al decidir la granularidad de los microservicios, el criterio debería ser "¿puede un equipo independiente ser responsable?" en lugar de "¿se puede dividir técnicamente?". Al alinear los límites del equipo con los límites del servicio, se puede aprovechar la Ley de Conway. Por otro lado, que una organización pequeña divida servicios con la misma granularidad que AWS es excesivo. Un equipo de 3 personas gestionando 20 microservicios es una receta para el fracaso operativo.
Resumen
La razón por la que AWS continúa ofreciendo más de 200 servicios individualmente sin integrarlos se arraiga en el API Mandate de Bezos de 2002 y el principio organizacional de Two-Pizza Team. Como muestra la Ley de Conway, la estructura organizacional define la arquitectura, y el sistema donde pequeños equipos independientes poseen sus respectivos servicios genera las ventajas de independencia en la velocidad de lanzamiento, localización de fallos y granularidad de opciones para el cliente. El costo de aprendizaje y la complejidad de integración son el precio a pagar, pero AWS considera que las ventajas de la separación superan estos costos.