Las dos lecciones anteriores han puesto la infraestructura de MercadoFresco bajo control: plantillas declarativas, constructos reutilizables, pruebas y un pipeline que despliega la infraestructura y se actualiza a sí mismo. Es el resultado de ocho módulos de trabajo. Y ahora toca hacerse una pregunta incómoda: ¿hacía falta todo esto?

Existe una alternativa que nadie del equipo evaluó en su momento, porque en el módulo 1 nadie sabía que existía. Elastic Beanstalk despliega una aplicación entregándole un fichero comprimido y una cadena con la versión del lenguaje; a cambio, aprovisiona y mantiene EC2, autoescalado, balanceador, grupos de seguridad y métricas. Esta lección explica qué hace exactamente, qué controla y qué no, y termina con la decisión honesta para MercadoFresco —que no es la que uno esperaría después de dos lecciones de infraestructura como código—.

Aviso de coste. Beanstalk es gratuito: pagas exactamente los recursos que crea. Un entorno de pruebas de un solo t3.small con balanceador cuesta unos 0,04 USD/hora, es decir, alrededor de 1 USD al día; si además es un entorno de servidor web con ALB, el balanceador solo ya son unos 0,025 USD/hora más el tráfico. El apartado de limpieza termina el entorno con un comando. Datos ficticios.

1. Qué es una plataforma como servicio
2. Qué crea Beanstalk por debajo
3. Conceptos: aplicación, versión, entorno y plataforma
4. Entornos de servidor web y entornos de trabajador
5. Plataformas admitidas y despliegue de la tienda paso a paso
6. Personalización con .ebextensions y .platform
7. Políticas de despliegue, configuraciones guardadas e IaC
8. Escalado, estado mejorado y panel de salud
9. Beanstalk con una base de datos
10. La decisión honesta para MercadoFresco
11. Comparativa con CDK, Fargate, App Runner y Amplify
12. La ruta de salida
13. Coste y limpieza
14. Errores comunes y consejos
15. Ejercicios
16. Conclusión

Una plataforma como servicio (PaaS) es un modelo en el que el proveedor gestiona todo lo que hay por debajo de tu código: el sistema operativo, el tiempo de ejecución del lenguaje, el servidor de aplicaciones, el balanceo, el escalado y la monitorización básica. Tú entregas el código y unas pocas decisiones de configuración.

Beanstalk se sitúa en un punto concreto de esa escala: más control que Lambda, mucho menos trabajo que EC2. Y, a diferencia de una PaaS cerrada, no te oculta la infraestructura: los recursos que crea son EC2, ASG, ALB y grupos de seguridad normales, visibles en la consola y accesibles por la CLI. Puedes entrar por SSH a las instancias, mirar los registros y modificar el ASG. Esa transparencia es su mayor virtud, y también el origen de sus problemas cuando alguien toca a mano lo que Beanstalk cree gobernar.

Cuando creas un entorno, Beanstalk genera una plantilla de CloudFormation y despliega una pila. Lo has estado usando sin saberlo desde 09-01: si listas las pilas de una cuenta con Beanstalk, verás una llamada awseb-e-abc123xyz-stack.

Esto tiene tres consecuencias que conviene tener claras desde el principio:

• No es magia, es CloudFormation. Los mismos estados, los mismos tiempos y los mismos límites de 09-01. Un despliegue que se queda a medias deja la pila en UPDATE_ROLLBACK_COMPLETE.
• La pila es de Beanstalk, no tuya. Modificarla directamente rompe el modelo: Beanstalk la sobrescribirá en la siguiente operación. Todo cambio se hace a través de las opciones de configuración de Beanstalk.
• En cada instancia hay un agente. Es quien recibe la orden de desplegar, descarga la versión desde S3, ejecuta los ganchos y reporta el estado. Cuando algo falla de forma rara, sus registros en /var/log/eb-engine.log son el primer sitio donde mirar.

Beanstalk tiene cinco conceptos y la confusión entre los tres primeros es la causa del 80 % de los errores iniciales.

La relación es de uno a muchos en cada nivel: una aplicación tiene N versiones y M entornos, y cada entorno tiene desplegada una versión concreta. Eso encaja perfectamente con la disciplina de 08-05: se construye el artefacto una vez y ese mismo objeto se promociona por los entornos. En Beanstalk se traduce en eb deploy --version v1.6.0 sobre cada entorno, sin reconstruir nada.

Las actualizaciones de plataforma merecen atención porque son el trabajo que Beanstalk no elimina, solo reduce. Cada rama de plataforma tiene versiones (Python 3.12 running on 64bit Amazon Linux 2023/4.2.1) y AWS publica una nueva cada pocas semanas con parches de seguridad. Hay dos formas de aplicarlas:

Las actualizaciones de plataforma gestionadas son una de las razones de peso para elegir Beanstalk: aplican los parches del sistema operativo en una ventana definida, con despliegue inmutable y reversión automática si falla. Es exactamente el trabajo que en el módulo 2 obligaba a reconstruir la AMI a mano.

Beanstalk tiene dos tipos de entorno, y el segundo encaja de forma casi literal con la arquitectura de MercadoFresco.

Un entorno de servidor web (web server) recibe tráfico HTTP a través de un ALB y tiene un nombre DNS público del tipo mercadofresco-tienda-produccion.eu-west-1.elasticbeanstalk.com.

Un entorno de trabajador (worker) no tiene balanceador ni tráfico entrante. En su lugar, Beanstalk crea una cola de SQS y despliega en cada instancia un demonio, sqsd, que lee mensajes de la cola y los entrega a tu aplicación como peticiones HTTP POST a localhost en una ruta configurable.

El detalle importante es cómo se traduce el resultado: si tu código responde 200, sqsd borra el mensaje de la cola; si responde un error o agota el tiempo, el mensaje vuelve a la cola y, tras MaxRetries intentos, va a la cola de mensajes fallidos. Es exactamente el patrón de 07-01 y 07-05 —visibilidad, reintentos y DLQ— pero con el bucle de consumo escrito por AWS.

Eso tiene una ventaja y una trampa. La ventaja: tu código de trabajador se convierte en un manejador HTTP normal, sin biblioteca de SQS, sin receive_message, sin gestión de la visibilidad. La trampa: la idempotencia sigue siendo responsabilidad tuya, porque un mensaje puede entregarse más de una vez exactamente igual que en 07-05. La tabla mercadofresco-idempotencia sigue haciendo falta.

Beanstalk permite además usar una cola existente en lugar de crear una: en las opciones del entorno, aws:elasticbeanstalk:sqsd/WorkerQueueURL apunta a cola-mercadofresco-pedidos. Con eso, el asg-mercadofresco-trabajadores del módulo 7 podría sustituirse por un entorno de trabajador sin tocar ni la cola ni el productor. Es el caso de uso donde Beanstalk sigue siendo competitivo hoy en MercadoFresco.

Un apunte útil: sqsd admite también tareas periódicas mediante un fichero cron.yaml en el paquete, con lo que sustituye a una regla programada de EventBridge para trabajos recurrentes sencillos.

Las dos últimas filas merecen una aclaración: Beanstalk puede desplegar contenedores, tanto una imagen suelta como varias con ECS por debajo. Es una vía perfectamente válida, pero si la arquitectura va a ser de contenedores, lo razonable es usar ECS o Fargate directamente —módulo 10— en lugar de una capa que los envuelve. La tienda de MercadoFresco es Python, así que encaja en la primera fila.

El requisito de la plataforma Python es sencillo: un objeto WSGI llamado application en application.py, o la ruta indicada en la configuración, y un requirements.txt.

Ese único comando eb create tarda entre cinco y siete minutos y crea el ALB, el grupo de destino, el ASG, la plantilla de lanzamiento, dos grupos de seguridad, el perfil de instancia de IAM, dos alarmas de CloudWatch y el grupo de registros. Es el contenido de aplicacion-mercadofresco.yaml de 09-01, sin escribir una línea. Esa frase es todo el argumento a favor de Beanstalk.

El ciclo de trabajo diario es igual de corto:

Dos advertencias sobre eb deploy que provocan sorpresas el primer día. La primera: empaqueta el contenido del directorio, no del último commit —salvo que uses eb deploy --staged o configures artefactos—, así que un fichero sin guardar o un .env local puede acabar desplegado. La segunda, consecuencia de la anterior: eb deploy es exactamente el «desplegar desde el portátil» que el módulo 8 eliminó. En un proyecto serio, eb deploy lo ejecuta el pipeline, no una persona.

Beanstalk es opinado, pero no cerrado. Hay dos mecanismos de personalización y sirven para cosas distintas.

.ebextensions/*.config son ficheros YAML dentro del paquete que configuran el entorno y los recursos: opciones de Beanstalk, paquetes del sistema, ficheros, comandos y recursos de CloudFormation adicionales.

.platform/ es el mecanismo moderno, disponible en las plataformas basadas en Amazon Linux 2 y posteriores, y sustituye a buena parte de lo anterior con ficheros normales en lugar de YAML:

Las opciones se organizan en espacios de nombres, y conocer los principales ahorra mucho tiempo de búsqueda en la documentación:

Un ejemplo que reúne varios y que es, en la práctica, la configuración mínima seria para un entorno de producción de MercadoFresco:

Fíjate en PreferredStartTime: la ventana de actualización de plataforma es una decisión de negocio, igual que la ventana de despliegue de 08-05. Un martes de madrugada es aceptable; un viernes por la tarde, con cinco veces más pedidos en juego, no.

Los límites de este modelo son reales y conviene conocerlos antes de casarse con Beanstalk. leader_only solo se aplica en despliegues, no cuando el ASG lanza una instancia nueva, así que una migración en container_commands no se ejecuta al escalar —lo cual está bien— pero tampoco puedes confiar en él para inicializaciones. Los ganchos se ejecutan en cada instancia, así que todo lo que hagan debe ser idempotente y rápido: un gancho lento multiplica el tiempo de despliegue por el número de instancias. Y hay cosas que sencillamente no se pueden cambiar: la estructura de la pila, el modelo de un proceso por instancia o el hecho de que el entorno sea la unidad de todo.

Aquí es donde Beanstalk se puede comparar de tú a tú con CodeDeploy (08-03), y la comparación es instructiva.

Dos notas sobre las dos últimas, que son las únicas aceptables en producción:

Inmutable es el equivalente más cercano al blue/green de 08-03 dentro de un mismo entorno: instancias nuevas desde cero, sin residuos de configuración, y si las comprobaciones de estado fallan se destruyen las nuevas y no ha pasado nada. Su ventaja sobre la renovación es que detecta problemas que solo aparecen en una instancia recién arrancada —una dependencia que ya no se descarga, un permiso que faltaba— que en un despliegue por renovación quedan enmascarados.

Blue/green por intercambio de CNAME es el modelo de 08-03 llevado al extremo: se crea un entorno completo con la versión nueva, se prueba con su propia URL y después eb swap intercambia los CNAME de los dos entornos. Es la única opción que permite revertir en segundos, porque el entorno azul sigue vivo.

Y aquí llega la comparación honesta con 08-03, que tiene dos partes.

Lo que Beanstalk hace igual de bien: las políticas cubren el espectro completo de compromisos entre velocidad, coste y riesgo, y la inmutable ofrece garantías reales sin configurar nada.

Lo que no hace: no hay canario —no se puede enviar el 10 % del tráfico a la versión nueva y observar—, no hay reversión automática basada en métricas de negocio, no hay ganchos de ciclo de vida equivalentes a BeforeAllowTraffic con una Lambda de validación, y el intercambio de CNAME depende del TTL del DNS: los clientes con la entrada cacheada siguen yendo al entorno viejo durante minutos. La puerta de calidad de 08-04, con sus quince minutos de métricas y su reversión en noventa segundos, no tiene equivalente aquí. Esa diferencia es la que hace que una tienda con 900 pedidos/hora los viernes no pueda conformarse con Beanstalk.

El problema que abrió este módulo —que preproducción no es igual que producción— también tiene respuesta dentro de Beanstalk, aunque más limitada que la de 09-02. Una configuración guardada es una foto de todas las opciones de un entorno, almacenada en S3 y aplicable a otro:

El fichero resultante es legible y comparable con diff, que es justo lo que hacía falta:

La diferencia con el config/entornos.ts de 09-02 es de grado: aquí la configuración se guarda, se versiona y se compara, pero no se genera desde una sola fuente, así que nada impide que alguien cambie una opción en un entorno y no en el otro. Es una foto, no un contrato.

Beanstalk y la infraestructura como código no son excluyentes: hay tipos de recurso nativos, de modo que un entorno puede vivir dentro del modelo unificado de 09-01 y 09-02.

Esto resuelve parcialmente la objeción de «la configuración vive en el repositorio de la aplicación»: las opciones estructurales pasan a la plantilla o al CDK, y .ebextensions se reserva para lo que acompaña al código. Es la forma correcta de usar Beanstalk en un equipo que ya practica infraestructura como código, y conviene conocerla antes de descartarlo por ese motivo.

El escalado es el del módulo 2, porque es un ASG: se configuran mínimo, máximo y un disparador basado en una métrica.

La pieza propia de Beanstalk que sí aporta valor real es el estado mejorado (enhanced health reporting). Un agente en cada instancia combina métricas del sistema, del servidor web y del balanceador y produce un estado por instancia y un estado global del entorno, con causas concretas.

eb health --refresh muestra ese panel en el terminal con las causas —«el proceso de la aplicación no responde en el puerto 8080»—, que es bastante más útil que un gráfico de CPU. El estado mejorado publica además métricas propias en CloudWatch (ApplicationRequests5xx, ApplicationLatencyP99, InstancesSevere), sobre las que se pueden montar las alarmas de 05-01 y conectarlas a alertas-mercadofresco.

Una advertencia que cuesta disgustos: el estado mejorado no viene activado en todos los caminos de creación, y sin él Beanstalk se limita a la comprobación básica del ALB. Actívalo siempre; es gratis salvo por las métricas de CloudWatch.

Beanstalk permite crear una instancia de RDS dentro del entorno, y es la trampa más conocida del servicio.

Si lo haces, la base de datos pasa a formar parte de la pila del entorno. Eso significa que eb terminate la borra, que una recreación del entorno la recrea vacía, y que la base de datos hereda el ciclo de vida de la aplicación, que es justo lo contrario de lo que debe ocurrir: la aplicación cambia cuatro veces por semana y los datos deben sobrevivir a todo. Es el mismo principio de partición por ciclo de vida de 09-01, y aquí se viola de forma flagrante.

Es cómodo para una demo o para un entorno de desarrollo que se destruye cada noche. Para cualquier otra cosa, la base de datos vive fuera y el entorno se conecta a ella:

La contraseña no va en una variable de entorno: va en Secrets Manager (04-03) y la aplicación la resuelve al arrancar con el rol de instancia, exactamente igual que en el módulo 4. Y la conectividad se resuelve con grupos de seguridad como en 03-02: el SG que Beanstalk crea para las instancias se autoriza como origen en sg-mercadofresco-basedatos.

Si ya cometiste el error y tienes la base de datos dentro, la salida existe pero es incómoda: instantánea, restauración fuera del entorno, cambio de la variable de conexión, verificación y despliegue. Con una ventana de mantenimiento, porque el endpoint cambia.

Aquí está el corazón de la lección, y la respuesta tiene dos partes que parecen contradictorias.

Beanstalk habría sido una decisión excelente en el módulo 2. En aquel momento, MercadoFresco tenía un monolito Python en un servidor, un equipo de tres personas sin experiencia en AWS y cuatro problemas urgentes. Beanstalk habría resuelto dos de ellos —las caídas de los viernes, con autoescalado y balanceador; y buena parte del riesgo de despliegue, con la política inmutable— en una tarde en lugar de en tres módulos. El coste habría sido idéntico, porque Beanstalk no cobra nada, y el equipo habría ganado meses.

Y hoy ya no encaja. No porque Beanstalk sea peor de lo que era, sino porque la arquitectura ha cambiado por debajo:

La tienda web es hoy una pieza de una arquitectura de veinte, y Beanstalk está diseñado para ser la arquitectura. Meter la tienda en un entorno de Beanstalk dejaría el 80 % del sistema fuera, gestionado con CDK, y crearía dos modelos de infraestructura conviviendo: la peor de las dos opciones.

El criterio general, que sirve más allá de este caso:

Y hay un caso concreto donde sí sigue teniendo sentido para MercadoFresco hoy: los trabajadores. Un entorno de trabajador apuntando a cola-mercadofresco-pedidos eliminaría el código de consumo, la gestión de visibilidad y el escalado del asg-mercadofresco-trabajadores, a cambio de aceptar un segundo modelo para una pieza acotada. Marta lo deja anotado como opción a evaluar, no como decisión tomada.

App Runner es, en cierto modo, «el Beanstalk de los contenedores»: le das una imagen o un repositorio y él se encarga de todo, incluido el escalado a partir de cero peticiones. Es más simple que Beanstalk y también más limitado: control de red reducido y menos opciones de despliegue.

Amplify resuelve un problema distinto —aplicaciones web frontales con hospedaje, CI/CD y backend gestionado—, y para MercadoFresco sería relevante si el catálogo se sirviera como aplicación de una sola página, no como sustituto de la tienda.

Fargate es la comparación importante, y se desarrolla en 10-02. La diferencia esencial con Beanstalk es qué desaparece: Beanstalk gestiona las instancias por ti, pero siguen existiendo, hay que parchearlas y tardan dos minutos en arrancar; Fargate elimina las instancias, y la unidad pasa a ser el contenedor. Es exactamente el problema con el que se cierra este módulo.

Un temor razonable antes de adoptar cualquier PaaS es quedarse encerrado. Con Beanstalk el encierro es moderado, y conviene saber por qué antes de decidir.

Lo que no es específico de Beanstalk: tu código, que es una aplicación WSGI normal; los recursos que crea, que son EC2, ASG y ALB estándar; y la base de datos, si la pusiste fuera. Lo que sí lo es: los ficheros .ebextensions, el demonio sqsd de los trabajadores, las variables de entorno definidas en el entorno y los ganchos de .platform.

La ruta de salida, en cinco pasos y sin corte de servicio:

1. Sacar el estado. Si la base de datos estaba dentro, se saca primero. Nada más se mueve hasta que esto esté hecho.
2. Traducir la configuración. Cada option_setting tiene su equivalente en CDK o CloudFormation, y cada gancho, su lugar en el AppSpec de CodeDeploy o en los datos de usuario de la plantilla de lanzamiento.
3. Levantar la infraestructura nueva en paralelo, con su propio ALB y su propio grupo de destino, sin tráfico.
4. Mover el tráfico gradualmente con Route 53 (03-05), con enrutamiento ponderado: 10 %, 50 %, 100 %, observando las métricas en cada escalón. Esto es lo que Beanstalk no ofrecía y que aquí sí se puede hacer.
5. Terminar el entorno de Beanstalk cuando lleve una semana sin tráfico.

La lección general vale para cualquier decisión de este tipo: el encierro no se mide por el servicio, sino por dónde vive el estado y cuánta configuración es específica. Si el estado está fuera y la configuración es traducible, empezar por lo simple y migrar después es una estrategia perfectamente razonable, y casi siempre mejor que construir la arquitectura definitiva antes de tener clientes.

Beanstalk no cobra: pagas EC2, el ALB, EBS, el tráfico y las métricas de CloudWatch. Un entorno de producción típico de MercadoFresco —dos m6i.large, un ALB, estado mejorado— rondaría los 165 USD al mes, exactamente lo mismo que costaría montado a mano, porque son los mismos recursos.

Dos fuentes de gasto invisible: las versiones de aplicación se acumulan en S3 sin borrarse, y el límite por omisión es de 1.000 versiones, tras el cual los despliegues fallan con un error que no menciona la causa; y los entornos de desarrollo olvidados, que cuestan lo mismo que los de producción si tienen ALB. Un entorno con --single (una instancia con IP elástica y sin balanceador) baja el coste de un entorno de pruebas a menos de 10 USD al mes, y es lo correcto para desarrollo.

eb terminate borra la pila de CloudFormation subyacente y con ella todos los recursos del entorno. Si creaste la base de datos dentro, ahí se va.

Error: crear la base de datos dentro del entorno. Es el error clásico y el más caro. Consejo: RDS y Aurora siempre fuera, conectados por variables de entorno y grupos de seguridad. La única excepción es un entorno de desarrollo desechable.

Error: modificar a mano los recursos que Beanstalk gestiona. Cambiar el ASG desde la consola parece funcionar hasta la siguiente operación del entorno, que lo sobrescribe. Consejo: todo cambio, por option_settings o por eb config.

Error: confundir aplicación, versión y entorno. Muchos «no se despliega mi cambio» son en realidad un eb deploy contra el entorno equivocado. Consejo: eb status antes de desplegar y eb use para fijar el entorno por defecto.

Error: usar «todas a la vez» en producción. Está por omisión en algunos caminos de creación y produce un corte de servicio en cada despliegue. Consejo: Immutable o blue/green por CNAME en producción; «todas a la vez» solo en desarrollo.

Error: desplegar desde el portátil con eb deploy. Empaqueta lo que hay en el directorio y salta todo el pipeline. Consejo: que lo ejecute CodeBuild con --version sobre un artefacto ya construido.

Error: no activar el estado mejorado. Sin él, el diagnóstico se queda en «unhealthy» sin causa. Consejo: actívalo siempre y monta alarmas sobre ApplicationRequests5xx y InstancesSevere.

Consejo: guarda configuraciones con eb config save. Producen una plantilla reutilizable con la que crear entornos idénticos: es la forma que tiene Beanstalk de evitar que preproducción y producción diverjan.

Consejo: si usas entornos de trabajador, apunta a la cola existente. WorkerQueueURL evita duplicar colas y permite convivir con el resto de la arquitectura de 07-01.

Consejo: revisa /var/log/eb-engine.log antes que ningún otro registro. Cuando un despliegue falla sin motivo aparente, la causa suele estar ahí, no en los registros de la aplicación.

Consejo: pon una política de ciclo de vida de versiones el primer día. El límite de 1.000 versiones se alcanza antes de lo que parece con un pipeline activo, y el error que produce no dice que el problema sean las versiones.

Consejo: usa --single en los entornos de desarrollo. Sin balanceador, el coste cae a menos de una quinta parte y para desarrollar no se pierde nada relevante.

Consejo: activa las actualizaciones de plataforma gestionadas con una ventana explícita. Es la ventaja de Beanstalk que más trabajo ahorra a largo plazo, y la que más gente deja sin configurar. Martes de madrugada, nunca viernes.

Marta quiere evaluar en serio sustituir el asg-mercadofresco-trabajadores por un entorno de trabajador de Beanstalk que consuma de cola-mercadofresco-pedidos. Describe cómo lo montarías: qué tipo de entorno, cómo se conecta a la cola existente, qué cambia en el código del trabajador respecto al consumo actual con receive_message, qué pasa con la DLQ mercadofresco-pedidos-fallidos y con la idempotencia de 07-05, cómo se configura el escalado y qué política de despliegue usarías. Termina con tres argumentos a favor y tres en contra de hacer el cambio.

Para cada uno de estos cuatro casos, elige política de despliegue de Beanstalk y justifícala en términos de tiempo, coste, riesgo y capacidad disponible: (a) entorno de desarrollo donde Luis despliega quince veces al día; (b) preproducción, donde se valida cada versión antes de producción; (c) producción un martes por la mañana con una versión que solo cambia textos; (d) producción un jueves con una versión que cambia la biblioteca de acceso a la base de datos y el proceso de arranque. Indica en cuáles la reversión es rápida y cómo se hace exactamente.

Imagina que MercadoFresco hubiera adoptado Beanstalk en el módulo 2, con la tienda monolítica en un entorno de servidor web y Aurora fuera del entorno. Han pasado los ocho módulos del curso y han aparecido las mismas necesidades: colas, Lambdas, CloudFront, WAF, DynamoDB, un pipeline con canario. Responde: (a) en qué momento exacto del curso Beanstalk habría empezado a estorbar y por qué; (b) qué tres necesidades concretas no habría podido cubrir; (c) si la salida habría sido más cara que no haber entrado nunca; (d) qué regla general extraes para elegir el nivel de abstracción de una plataforma.

Solución 1

El montaje. Un entorno de trabajador (eb create mercadofresco-trabajadores --tier worker) sobre la misma plataforma Python, en las subredes snet-mercadofresco-app-a/-b de la VPC existente y con el SG sg-mercadofresco-tienda o uno propio que pueda alcanzar Aurora y ElastiCache. La conexión a la cola existente se hace con las opciones de sqsd, no creando una cola nueva:

Qué cambia en el código. Desaparece todo el bucle de consumo: receive_message, delete_message, la gestión de la visibilidad, el control del lote y el manejo de reintentos. El trabajador pasa a ser un manejador HTTP: recibe un POST en /tareas/pedido con el cuerpo del mensaje, procesa y devuelve 200. Un error o un tiempo agotado se traduce en un código distinto de 2xx y el mensaje vuelve a la cola. Es menos código y menos superficie de error, y el rol de instancia solo necesita permisos de lectura y borrado sobre la cola.

La DLQ y la idempotencia. La DLQ no cambia en absoluto: sigue siendo la política de reintentos de la propia cola de SQS, definida en su RedrivePolicy con maxReceiveCount, y mercadofresco-pedidos-fallidos sigue recibiendo lo que agote los intentos. Hay un matiz importante: MaxRetries de sqsd y maxReceiveCount de la cola son dos contadores distintos, y manda el menor de los dos; configurarlos con valores incoherentes produce el clásico «los mensajes no llegan nunca a la DLQ». La idempotencia sigue siendo responsabilidad del código: sqsd no aporta ninguna garantía de entrega única, así que la tabla mercadofresco-idempotencia de 07-05 se mantiene tal cual.

Escalado y despliegue. Escalado por profundidad de la cola, no por CPU: una alarma sobre ApproximateNumberOfMessagesVisible de cola-mercadofresco-pedidos conectada al disparador del ASG. Es lo correcto para un trabajador, porque la CPU puede estar baja mientras se acumulan miles de mensajes esperando a la base de datos. Política de despliegue inmutable: un trabajador no atiende usuarios, así que no hay prisa, y a cambio se obtienen instancias limpias con validación completa antes de aceptar carga.

Tres a favor: desaparece código de infraestructura del trabajador —el bucle de consumo es donde vivían dos errores del módulo 7—; los parches del sistema operativo pasan a ser actualizaciones gestionadas; y el escalado y las comprobaciones de estado vienen resueltos.

Tres en contra: introduce un segundo modelo de infraestructura conviviendo con el CDK, que es exactamente lo que la lección anterior evitó; la configuración del trabajador se reparte entre .ebextensions en el repositorio de la aplicación y el CDK en mercadofresco-infra, con lo que la fuente de verdad deja de ser única; y el modelo HTTP oculta el control fino del lote, que en el pico de los viernes puede importar.

Veredicto razonable: técnicamente funciona bien y es el mejor encaje de Beanstalk en MercadoFresco hoy, pero el argumento de la unidad del modelo pesa más. Si la evaluación se hace, debe hacerse comparándolo con Fargate (10-02), que resuelve lo mismo sin abrir un segundo modelo.

Solución 2

(a) Desarrollo, quince despliegues al día: todas a la vez. Es la más rápida —un par de minutos—, no cuesta instancias extra y el corte de servicio no importa porque solo lo sufre Luis. Con quince despliegues diarios, cualquier política más lenta se traduce en horas perdidas a la semana. Reversión: volver a desplegar la versión anterior; tarda lo mismo y no pasa nada.

(b) Preproducción: inmutable. Aunque el riesgo de negocio sea nulo, preproducción existe para ensayar el despliegue de producción, y ensayarlo con otra política no ensaya nada. Además, la inmutable es la que detecta los problemas de arranque en frío, que es precisamente lo que se quiere descubrir antes de producción. El coste extra es aceptable porque los despliegues son pocos.

(c) Producción, martes, solo textos: renovación con lote adicional. El cambio es de bajo riesgo y no toca dependencias ni arranque, así que la garantía extra de la inmutable no compensa su tiempo. El lote adicional mantiene el 100 % de capacidad durante todo el proceso —crítico en una tienda— a cambio de una sola instancia extra durante unos minutos. Reversión: redesplegar la versión anterior con la misma política; unos minutos.

(d) Producción, jueves, biblioteca de base de datos y arranque: blue/green por intercambio de CNAME. Es el caso de mayor riesgo del ejercicio: un cambio en el proceso de arranque puede fallar solo en instancias nuevas, y un cambio de biblioteca de base de datos puede degradar el rendimiento sin fallar ninguna comprobación de estado. El entorno verde permite ejecutar las pruebas de humo con tráfico real controlado y, sobre todo, el entorno azul sigue vivo: la reversión es un eb swap de vuelta, en segundos.

Y la lectura transversal, que enlaza con 08-05: la reversión es rápida solo en (d). En (a), (b) y (c) revertir significa desplegar otra vez, es decir, minutos con el sistema en el estado malo. Esa es la diferencia real entre blue/green y todo lo demás, y el motivo por el que la política se elige por el riesgo del cambio, no por costumbre. Un detalle final: el eb swap depende del TTL del CNAME, así que conviene bajarlo a 60 segundos días antes de un despliegue así.

Solución 3

(a) Beanstalk habría empezado a estorbar en el módulo 7, con la integración de aplicaciones. Hasta ahí, la arquitectura era una aplicación web con una base de datos, y eso es exactamente lo que Beanstalk hace bien; el módulo 3 (VPC, ALB, CloudFront) y el 4 (IAM, WAF) habrían convivido sin problema, porque Beanstalk puede desplegarse en una VPC existente y CloudFront se pone delante de cualquier ALB. El punto de inflexión es el momento en que la aplicación deja de ser un proceso y pasa a ser un sistema de piezas coordinadas: colas, temas, un bus y una máquina de estados que Beanstalk no gestiona. A partir de ahí, el entorno pasa de ser «la arquitectura» a ser «una pieza más», que es justo lo que no es.

(b) Tres necesidades no cubiertas: el despliegue canario con reversión automática por métricas de negocio de 08-03 y 08-04, que no tiene equivalente; la orquestación de las cinco Lambdas y la máquina de estados de 07-04, completamente fuera de su ámbito; y la infraestructura como código unificada y revisable de este módulo, porque la configuración de Beanstalk vive en .ebextensions dentro del repositorio de la aplicación, mezclando dos ciclos de vida que 09-01 recomienda separar.

(c) No, la salida no habría sido más cara que no haber entrado. Con la base de datos fuera —que era la condición del enunciado—, el estado no está atrapado, y lo que hay que traducir son option_settings y ganchos, un trabajo de días, no de meses. La migración se habría hecho con enrutamiento ponderado de Route 53 sin corte de servicio. Frente a eso, la alternativa era haber construido en el módulo 2 una infraestructura que el equipo no sabía diseñar todavía, para una arquitectura que aún no existía: probablemente se habría hecho mal y habría habido que rehacerla igualmente, pero sin haber tenido nada en producción mientras tanto. El coste de entrar y salir es real, pero es menor que el coste de la parálisis inicial.

(d) La regla general. Elige el nivel de abstracción más alto que cubra tus requisitos actuales, siempre que el estado quede fuera y la configuración sea traducible. Las tres condiciones importan: «requisitos actuales» y no imaginados, porque construir para una arquitectura futura que quizá no llegue es la forma más cara de equivocarse; «el estado fuera», porque es lo único que no se migra sin dolor; y «configuración traducible», porque es lo que convierte el cambio de plataforma en un proyecto de días. La regla se aplica hacia arriba y hacia abajo: por eso MercadoFresco, que hoy necesita control fino, usa CDK, y por eso mismo en 10-02 se planteará subir de nuevo el nivel de abstracción con Fargate.

Elastic Beanstalk convierte un fichero comprimido y una cadena con la versión del lenguaje en una aplicación en producción con balanceador, autoescalado, grupos de seguridad, alarmas y perfil de instancia, y lo hace generando una plantilla de CloudFormation y desplegando una pila —awseb-e-xxxx-stack— con las mismas reglas de 09-01. Es una plataforma como servicio que no oculta la infraestructura: puedes entrar por SSH, mirar los registros y ver los recursos, con la contrapartida de que modificarlos a mano rompe el modelo, porque Beanstalk los sobrescribe en la siguiente operación.

Tienes sus cinco conceptos, y en particular la separación entre versión de aplicación —el artefacto inmutable de 08-02, que se promociona con eb deploy --version— y entorno, que es donde está todo el coste. Tienes los entornos de trabajador, con sqsd traduciendo mensajes de SQS en peticiones HTTP a localhost: el bucle de consumo escrito por AWS, con la advertencia de que la idempotencia sigue siendo tuya y de que MaxRetries y maxReceiveCount son dos contadores distintos donde manda el menor. Y tienes la personalización con .ebextensions y .platform, con leader_only para las migraciones y el aviso de que un gancho lento multiplica el tiempo de despliegue por el número de instancias.

Las cinco políticas de despliegue cubren el espectro completo entre velocidad, coste y riesgo, y la comparación con 08-03 es la parte más útil de la lección: la inmutable da garantías reales sin configurar nada y detecta los fallos que solo aparecen en instancias recién arrancadas; el blue/green por intercambio de CNAME es lo único que permite revertir en segundos, con la salvedad del TTL del DNS. Pero no hay canario, ni reversión automática por métricas de negocio, ni ganchos de validación, y esa ausencia es la que descarta a Beanstalk para una tienda con 900 pedidos/hora los viernes. Más la trampa mejor conocida del servicio: la base de datos nunca dentro del entorno, porque eb terminate se la lleva.

Y la decisión honesta, que tiene dos caras. Beanstalk habría sido excelente en el módulo 2 —un monolito, tres personas sin experiencia en AWS, dos de los cuatro problemas resueltos en una tarde y coste idéntico, porque el servicio es gratis—. Y hoy ya no encaja, no porque haya empeorado, sino porque la tienda web pasó de ser la arquitectura a ser una pieza de veinte: cinco Lambdas, cuatro colas, un bus, una máquina de estados, cuatro bases de datos y un pipeline con canario que quedarían fuera del entorno, obligando a mantener dos modelos de infraestructura a la vez. La regla que queda es más valiosa que el servicio: elige el nivel de abstracción más alto que cubra tus requisitos actuales, siempre que el estado quede fuera y la configuración sea traducible, porque entonces la ruta de salida es un proyecto de días y no una condena.

Queda un problema que Beanstalk tampoco resolvía y que ninguna de las tres lecciones de este módulo ha tocado todavía. Toda la infraestructura de MercadoFresco —las nueve pilas del CDK, los tres entornos, el pipeline que se despliega a sí mismo— vive en una sola cuenta, la 111122223333. Un cdk destroy mal dirigido alcanza producción, las cuotas de direcciones IP elásticas y de instancias se comparten entre desarrollo y producción, ninguna política de IAM aísla del todo a quien ya tiene permisos amplios, y la factura no separa de verdad lo que cuesta cada entorno. La infraestructura es reproducible, pero el radio de explosión no está acotado.

En 09-04, «AWS Organizations», se cierra el módulo atacando exactamente eso: cuentas separadas por entorno, unidades organizativas, políticas de control de servicios que limitan lo que se puede hacer incluso siendo administrador, facturación consolidada, acceso con IAM Identity Center para que Marta, Luis y Sara trabajen en cuatro cuentas sin multiplicar usuarios, y una línea base que se despliega sola en cada cuenta nueva con los StackSets de 09-01.