Los equipos de aseguramiento de la calidad (QA) que gestionan productos complejos enfrentan un reto constante: la generación continua de fallos durante las pruebas. Cada error debe ser documentado en un ticket con pasos reproducibles, capturas de pantalla, tasas de reprocesos y etiquetas para descartar regresiones. Esta tarea manual consume entre 10 y 15 minutos por fallo; considerando más de 30 fallos semanales por equipo, significa dedicar un día entero de ingeniería exclusivamente a documentación que debería automatizarse.
Para resolver este problema, se creó un sistema innovador no basado en un panel de control ni en un bot de notificaciones, sino en un agente autónomo. Este agente observa los resultados de las pruebas, toma decisiones sobre si un error es nuevo, duplicado o una regresión, y luego ejecuta acciones sin intervención humana. Se encarga de registrar fallos estructurados, adjuntar capturas, calcular tasas de reprocesos, detectar regresiones entre builds y notificar a los responsables adecuados, dejando al equipo la única tarea de marcar un error como FALLIDO y continuar con su trabajo.
Este sistema se implementó inicialmente en AWS Lambda, demostrando ser eficaz para un solo equipo. Sin embargo, al plantear la expansión hacia 10, 50 o incluso 100 equipos, surgió la necesidad de replantear la arquitectura. No por limitaciones técnicas de Lambda, sino porque las características y demandas de la carga de trabajo cambiaban radicalmente, haciendo necesaria una solución más adecuada. 
Arquitectura inicial y razones del éxito
La solución original consistía en una regla de EventBridge que activaba una función Lambda cada 15 minutos. Esta función consultaba la API de gestión de pruebas, procesaba los fallos mediante un motor de decisiones (comparación con registros almacenados en DynamoDB para deduplicación y detección de regresiones) y creaba los tickets de fallo en JIRA. Todo esto generaba un coste mensual inferior a cinco dólares.
Lambda fue la opción ideal por tres razones clave:
- Sin carga operativa: no se requieren gestionar servidores, configuraciones de escalado ni actualizaciones; se despliega y se olvida.
- Costes ajustados al uso: un equipo generaba alrededor de 200 invocaciones mensuales, representando un gasto prácticamente nulo según la tarifa de Lambda.
- Rápida iteración: el motor de decisiones se modificó más de 20 veces en el primer mes, y el modelo de despliegue de Lambda permitió incorporar cambios en segundos.
En pocas semanas, el sistema superó el nivel de consistencia y completitud en la generación de tickets que había logrado el equipo manualmente. Las regresiones se detectaban en minutos en lugar de días y las interrupciones en QA desaparecieron, ya que cualquier usuario podía consultar el estado del sistema a través de Slack, ahorrando entre 8 y 10 horas semanales.
El reto de la expansión y la elección arquitectónica
Otras áreas mostraron interés en adoptar este agente, pero escalarlo no era simplemente replicarlo para cada equipo. Al aumentar el número de equipos, las características de la carga de trabajo evolucionaron:
- De eventos efímeros a contexto de larga duración: Mientras la consulta para un equipo tarda segundos, analizar patrones comunes entre múltiples equipos requiere procesar cientos de resultados simultáneamente, demandando procesamiento persistente y estado compartido.
- De invocaciones aisladas a competencia por recursos compartidos: Sesenta funciones Lambda activándose al mismo tiempo generan cuellos de botella en las APIs externas, requiriendo gestión centralizada de la tasa de peticiones y conexiones persistentes.
- De un único equipo a multiusuario con aislamiento riguroso: Cada equipo precisa recursos garantizados, límites de red y credenciales propias, aumentando la complejidad de aislamiento.
Aunque recientes mejoras en Lambda (Managed Instances, Durable Functions y Tenant Isolation) abordan aspectos individuales, la combinación de todos estos requisitos sugiere que una arquitectura basada en contenedores, con operaciones similares a serverless, es la solución más natural. Es aquí donde entra en juego EKS Auto Mode, la oferta de Kubernetes gestionado sin necesidad de administrar nodos.
Marco de decisión para elegir entre Lambda y EKS
El nuevo enfoque define un conjunto de características que ayudan a elegir la infraestructura adecuada según el tipo de carga:
| Característica | Lambda (y extensiones) | EKS Auto Mode |
|---|---|---|
| Eventos cortos y disparados | Ideal | Complicado |
| Baja complejidad, un solo usuario | Ideal | Excesivo |
| Multiusuario con necesidades de aislamiento | Posible (Tenant Isolation) | Inherente (namespaces, RBAC, políticas de red) |
| Procesos duraderos con estado persistente | Posible (Durable Functions) | Inherente (pods, conexiones persistentes) |
| Análisis cruzado de usuarios que requiere memoria compartida | Complejo (orquestación a medida) | Natural (espacio de servicios compartidos) |
| Inferencia GPU para picos | Posible (GPU en Lambda si disponible) | Inherente (NodePools GPU, escalado a cero) |
| Limitación centralizada y agrupación de conexiones | Implementación personalizada (SQS y Step Functions) | Servicio de plataforma compartido |
El factor decisivo ha sido la necesidad simultánea de todas las capacidades del lado derecho, que se combinan mejor en un entorno nativo de contenedores.
El valor añadido a gran escala: inteligencia entre equipos
Más allá de automatizar tareas individuales para cada equipo, la verdadera ventaja al escalar es detectar patrones comunes entre múltiples equipos, algo imposible desde una visión aislada:
- Varias áreas reportan fallos similares en la misma versión de firmware: indica una regresión sistemática, no fallos individuales.
- Errores coinciden con despliegues de servicios independientes: apunta a un problema en la infraestructura.
- Firmas de error idénticas en conjuntos de pruebas distintos: falla en dependencias compartidas.
Este análisis exige un motor con estado persistente capaz de manejar el contexto agregado de todas las unidades, algo óptimo en un servicio compartido dentro de un espacio de nombres de la plataforma.
Clasificación de errores mediante aprendizaje automático
Con miles de errores registrados, los patrones pueden clasificarse automáticamente:
- Asignación automática de errores al responsable adecuado basándose en la firma del fallo.
- Predicción de gravedad según el tipo de fallo (caída, degradación, error estético).
- Sugerencias de errores relacionados para investigar más a fondo.
- Detección temprana de tasas anómalas de error antes de alcanzar un escenario crítico.
La carga por inferencia es intermitente, requiriendo GPU solo en picos; un grupo especializado de nodos GPU que escala a cero cuando está inactivo mantiene los costes ajustados. Además, la clasificación y la creación de tickets se integran en un mismo flujo.
Base de conocimiento consultable vía Slack
El agente se convierte en una capa de inteligencia accesible para toda la organización. A través de Slack, cualquiera puede consultar:
- La tasa de fallos en navegación esta semana en todos los equipos.
- Regresiones detectadas en una build específica.
- Equipos con mayor número de errores críticos activos.
Estas consultas requieren agregación de datos entre equipos, cálculos de tendencias y comprensión del lenguaje natural, todo posible gracias a un estado persistente y bien indexado acumulado en el tiempo.
Ventajas de EKS Auto Mode para esta arquitectura
Lanzado en re:Invent 2024, EKS Auto Mode ofrece Kubernetes completo sin la necesidad de gestionar nodos, aportando para esta plataforma multiusuario:
- Nodos que aparecen bajo demanda cuando los pods lo requieren y se eliminan automáticamente cuando no se necesitan, evitando la gestión directa de instancias EC2.
- Seguridad reforzada con nodos que ejecutan AMIs inmutables Bottlerocket, con rotación automática y sin acceso SSH, asegurando una administración sencilla con mínimo impacto.
- Escalado reactivo que acomoda las cargas durante periodos de inactividad, consolidando tareas y optimizando costes.
- Integración sencilla de cargas de trabajo GPU a través de NodePools específicos que escalan según demanda.
Arquitectura multiusuario escalable
El sistema se dividiría en tres capas principales:
- Servicios compartidos de plataforma: limitadores de tasa centralizados, gestores de conexión persistentes, y recogida de métricas con Prometheus para toda la plataforma.
- Espacios de nombres por cliente: cada equipo dispone de un entorno aislado con pods para gestión de fallos, informes y bots en Slack. Se aplican cuotas de recursos y políticas de red para asegurar la separación y seguridad.
- Espacio compartido de inferencia ML: pods habilitados para GPU que ejecutan modelos de clasificación accesibles por todos los equipos y que escalan a cero cuando no están en uso.
El código del agente mantiene la lógica central de decisión (observar, deduplicar, decidir, actuar), adaptado a un modelo de ejecución permanente con conexiones persistentes y manejo ordenado del ciclo de vida, en contraste con el modelo efímero de Lambda.
Uso combinado del ecosistema AWS
La clave no es migrar totalmente de Lambda a EKS, sino emplear cada tecnología donde aporta más valor:
- Lambda se mantiene para validar nuevas incorporaciones y gestionar automatización individual con coste casi nulo y alta rapidez de despliegue.
- Lambda con Durable Functions soporta workflows más largos y complejos sin salir del modelo serverless.
- EKS Auto Mode cubre las necesidades de infraestructura persistente, multiusuario con aislamiento, análisis cruzados y cargas GPU.
- DynamoDB almacena el estado distribuido y datos históricos.
- EventBridge orquesta eventos entre funciones Lambda y pods de Kubernetes sin distinguir la fuente.
Cuando el equipo amplía el alcance de sus análisis o requiere workflows más complejos, Durable Functions es la transición natural. Para capacidades adicionales como estado compartido o uso de GPU, se evalúa el paso a Auto Mode.
Conclusiones clave y matemáticas de coste
- Empezar con serverless permite probar el patrón sin costes ni operatividad.
- Diseñar la función Lambda para que sea fácilmente portable a contenedores pensando en el motor de decisiones como núcleo desacoplado.
- La transición depende de las características del trabajo, no del número de equipos.
- El aislamiento multiusuario se gestiona tanto en Lambda como en Kubernetes, eligiendo según otras necesidades.
- EKS Auto Mode elimina el coste operativo previo asociado al uso de Kubernetes.
El coste para un equipo usando Lambda es de 3 a 5 dólares mensuales con un ahorro en horas hombre de 8 a 10 semanas. Para 50 equipos en EKS Auto Mode, el gasto estimado es de 200 a 250 dólares mensuales, manteniendo la misma economía por equipo y sumando aislamiento por namespaces, conexiones persistentes, GPU y gobernanza integrada.
Mirando hacia el futuro
El patrón agente autónomo – observar, decidir y actuar – es independiente de la infraestructura subyacente. Sin embargo, la verdadera revolución llegará cuando los agentes comiencen a coordinarse entre sí. Por ejemplo, un agente que detecta un patrón de fallo podrá ceder contexto a otro que localice la causa raíz, trace dependencias y proponga soluciones antes incluso de que un humano revise el error. Esta delegación entre agentes sin intervención humana abre una nueva frontera en automatización avanzada.
Además, los agentes aprenderán a mejorar sus propios modelos a partir de la historia de errores y correcciones que la organización produce, ajustando su precisión sin necesidad de reprogramación constante. Esta evolución continuará ampliando las capacidades más allá de la simple automatización que inició como un proyecto de fin de semana para eliminar la carga manual en QA.
En definitiva, el diseño y elección de infraestructura deben adaptarse a las necesidades cambiantes. Serverless valida y permite comenzar rápido, mientras que contenedores con gestión avanzada como EKS Auto Mode permiten escalar con robustez y características avanzadas que garantizan un futuro de agentes autónomos coordinados y potentes.
