Hace poco circuló en LinkedIn un video que generó mucha discusión en la comunidad de ingeniería: un senior engineer que trabajó casi 8 años en Atlassian documentó en detalle la arquitectura de plataforma que construyó antes de ser despedido en una de las rondas masivas de layoffs del sector tech.
No es un artículo de resentimiento. Es uno de los mejores casos de estudio reales de arquitectura de plataforma a escala enterprise que se han publicado recientemente con nombres de tecnologías reales, decisiones de diseño documentadas, y las lecciones que raramente aparecen en los papers académicos o los blogs de marketing de las big tech.
Video original en inglés: I was laid off by Atlassian — YouTube
El problema que había que resolver
Atlassian tenía cientos de equipos de desarrollo. Cada vez que un equipo necesitaba exponer un servicio al mundo exterior, tenía que abrir un ticket con el equipo de infraestructura para que alguien configurara manualmente un load balancer enterprise. Un load balancer con licencia costosa, difícil de escalar y que creaba un cuello de botella operativo: el equipo de infra era el único que podía tocarlo.
El objetivo del proyecto: self-service infrastructure. Los desarrolladores deberían poder provisionar su propio load balancing sin depender de un equipo centralizado para cada request, de la misma manera en que los cloud providers permiten crear un load balancer desde su consola en minutos.
La solución: reemplazar los load balancers enterprise con un sistema open-source basado en Envoy Proxy, con una plataforma de autoservicio construida encima.
La arquitectura de la plataforma: 4 capas
El sistema final tiene una elegancia arquitectónica que vale la pena entender en detalle.
Capa 1: Service Broker API (FastAPI)
El punto de entrada del sistema. Los desarrolladores llaman a esta API para solicitar el provisionamiento de un load balancer. El diseño sigue el patrón Open Service Broker (OSB) el mismo estándar que usan plataformas como Cloud Foundry y Kubernetes para servicios gestionados.
Una decisión clave aquí: el broker no hace trabajo pesado en el request síncrono. Recibe la solicitud, la valida, y la encola inmediatamente. El request responde al cliente en milisegundos. Todo el trabajo real ocurre de forma asíncrona.
La implementación evolucionó en el tiempo: comenzó con una librería Python sobre OpenAPI, luego migró a Flask, y finalmente a FastAPI la arquitectura asíncrona de FastAPI es ideal para este patrón de trabajo que depende de colas y polling.
Capa 2: Worker asíncrono (SQS + DynamoDB)
El broker encola las tareas de provisionamiento en Amazon SQS. Un worker consume esas tareas y ejecuta los pasos necesarios:
- Crear registros DNS en Route 53
- Crear o actualizar distribuciones CloudFront
- Llamar a otras APIs de AWS según el tipo de recurso
El estado de cada tarea se escribe en DynamoDB. El cliente puede hacer polling al broker para saber si el provisionamiento terminó "ready/finished" o "error". Este patrón de async provisioning con polling es el mismo que usan Terraform, Pulumi y los cloud providers nativos para operaciones de larga duración.
Capa 3: Control Plane de Envoy (open-sourced como "Sovereign")
Esta es la pieza más técnicamente interesante del sistema. Envoy Proxy puede recibir configuración dinámica en runtime no necesita reiniciarse para aplicar cambios. Pero para eso necesita un control plane: un servidor que lea el estado actual del sistema y lo traduzca a configuración de Envoy en tiempo real.
El equipo construyó este control plane en FastAPI y lo open-sourceó como Sovereign. Su funcionamiento:
- Lee templates que mapean a constructs de Envoy: clusters, routes, listeners, virtual hosts
- Lee contexto dinámico desde DynamoDB y S3 los resultados del worker de provisionamiento
- Renderiza configuración Envoy válida cada vez que el contexto cambia
- Envoy Proxy aplica la nueva configuración sin interrumpir el tráfico existente
El resultado: cuando un desarrollador pide un nuevo load balancer, el flujo completo es: Broker API > SQS > Worker > DynamoDB > Control Plane detecta cambio > Envoy reconfigura sin downtime.
Capa 4: Fleet de proxies Envoy (2,000 instancias en 13 regiones)
La infraestructura de proxies es masiva: aproximadamente 2,000 instancias Envoy corriendo en 13 regiones globales. Cada instancia es una EC2 construida a partir de una AMI personalizada que incluye Envoy preinstalado, configurado y endurecido.
El pipeline de creación de AMIs usa HashiCorp Packer + SaltStack:
- Packer lanza una EC2 temporal
- SaltStack aplica la configuración: instala Envoy, configura el sistema operativo, agentes de logging y observabilidad
- Se hardenizan parámetros de red
- Packer toma un snapshot y produce la AMI final
La infraestructura se gestiona con AWS CloudFormation: Auto Scaling Groups, Network Load Balancers (L4), VPC, security groups, IAM roles, certificados ACM y registros Route 53. Todo como código, todo reproducible.
La decisión estratégica: mover lógica hacia el edge
Una vez que la plataforma estuvo funcionando y Jira, Confluence, Bitbucket, Status Page y otros productos de Atlassian migraron detrás de la infraestructura centralizada, el equipo tomó una decisión que cambió fundamentalmente la arquitectura del tráfico.
El patrón tradicional: cada servicio backend implementa su propia lógica de auth, rate limiting, logging, manejo de DDoS. Miles de servicios, cada uno duplicando las mismas preocupaciones transversales.
El patrón adoptado: mover esa lógica al proxy Envoy en el edge. El flujo es Cliente → Proxy (edge) → Servicio backend. Todo lo que puede manejarse antes de llegar al backend, se maneja en el proxy:
- Protección DDoS: implementada vía CloudFront antes de que el tráfico llegue a Envoy
- Access logs: configurados via Envoy HTTP Connection Manager con templates dinámicos
- Autenticación: un sidecar en Rust escrito por el propio speaker, que corre junto al proxy y recibe configuración dinámica
- Autorización y rate limiting: sidecars adicionales contribuidos por otros equipos
El resultado: los servicios backend son más simples porque no tienen que reimplementar estas preocupaciones, y el equipo de plataforma puede agregar nuevas capacidades al edge una sola vez para que todos los productos se beneficien automáticamente.
Las lecciones no técnicas que el speaker enfatiza
El video dedica tiempo considerable a lecciones que raramente aparecen en los architecture talks técnicos y que en la experiencia de Ab4cus son igual de críticas que las decisiones de stack.
Documentación y onboarding como parte del sistema
El speaker es enfático: un sistema exitoso en producción requiere que los ingenieros on-call sepan qué hacer cuando algo falla. Eso no ocurre mágicamente requiere documentación activa, runbooks, y entrenamiento. Un sistema sin documentación no está terminado, está en deuda.
Planificación del mantenimiento antes del lanzamiento
Los riesgos operativos que el speaker identificó antes de lanzar el sistema al tráfico real de Atlassian:
- ¿Qué pasa si DynamoDB no está disponible?
- ¿Qué pasa si una cola SQS falla?
- ¿Qué pasa si el control plane genera una configuración Envoy válida sintácticamente pero que rompe el tráfico semánticamente?
Tener respuestas a esas preguntas antes de que ocurran en producción es la diferencia entre un incidente de 30 minutos y uno de 6 horas.
La deuda técnica crece con la rotación de personas
Un patrón que el speaker observó: la complejidad del código aumenta a medida que las personas que lo construyeron se van. El code churn concentrado en ciertas partes del sistema es una señal de que algo se está volviendo difícil de cambiar. El speaker menciona que los LLMs podrían ayudar a "desenredar" código acoplado en el futuro — pero sin sobrevender la idea.
Por qué esta arquitectura es relevante para LATAM
Los problemas que resolvió este equipo en Atlassian son exactamente los que enfrentan las plataformas fintech y bancarias en crecimiento en América Latina:
Self-service de infraestructura: cuando el equipo de plataforma es el cuello de botella para que los equipos de producto salgan a producción, el modelo centralizado manual no escala. El patrón Service Broker + async provisioning es el camino correcto y es el mismo patrón que usan Kubernetes operators y los cloud providers nativos.
Centralizar lógica transversal en el edge: auth, rate limiting, logging y protección DDoS implementados una vez en el proxy es infinitamente mejor que implementarlos en cada microservicio. En el stack de Ab4cus, Cloudflare Workers hace exactamente ese rol el edge como primera línea de lógica transversal.
Configuración dinámica sin downtime: un sistema que puede reconfigurarse sin reiniciarse es fundamental para plataformas con SLAs de alta disponibilidad. Envoy con xDS API y el patrón de control plane que describe el speaker es la implementación de referencia para este problema.
Si tu plataforma está creciendo y empiezas a ver estos síntomas equipos esperando tickets de infra, lógica duplicada en múltiples servicios, deploys que requieren downtime esta arquitectura tiene las respuestas.
🔥 Evaluar la arquitectura de tu plataforma con Ab4cus
También te puede interesar:
0 Comentarios