Les dues lliçons anteriors han posat la infraestructura de MercadoFresco sota control: plantilles declaratives, constructes reutilitzables, proves i un pipeline que desplega la infraestructura i s'actualitza a si mateix. És el resultat de vuit mòduls de feina. I ara toca fer-se una pregunta incòmoda: calia tot això?

Existeix una alternativa que ningú de l'equip no va avaluar en el seu moment, perquè al mòdul 1 ningú no sabia que existia. Elastic Beanstalk desplega una aplicació lliurant-li un fitxer comprimit i una cadena amb la versió del llenguatge; a canvi, aprovisiona i manté EC2, autoescalat, balancejador, grups de seguretat i mètriques. Aquesta lliçó explica què fa exactament, què controla i què no, i acaba amb la decisió honesta per a MercadoFresco —que no és la que un esperaria després de dues lliçons d'infraestructura com a codi—.

Avís de cost. Beanstalk és gratuït: pagues exactament els recursos que crea. Un entorn de proves d'un sol t3.small amb balancejador costa uns 0,04 USD/hora, és a dir, al voltant d'1 USD al dia; si a més és un entorn de servidor web amb ALB, el balancejador tot sol ja són uns 0,025 USD/hora més el trànsit. L'apartat de neteja acaba l'entorn amb una ordre. Dades fictícies.

1. Què és una plataforma com a servei
2. Què crea Beanstalk per sota
3. Conceptes: aplicació, versió, entorn i plataforma
4. Entorns de servidor web i entorns de treballador
5. Plataformes admeses i desplegament de la botiga pas a pas
6. Personalització amb .ebextensions i .platform
7. Polítiques de desplegament, configuracions guardades i IaC
8. Escalat, estat millorat i tauler de salut
9. Beanstalk amb una base de dades
10. La decisió honesta per a MercadoFresco
11. Comparativa amb CDK, Fargate, App Runner i Amplify
12. La via de sortida
13. Cost i neteja
14. Errors habituals i consells
15. Exercicis
16. Conclusió

Una plataforma com a servei (PaaS) és un model en què el proveïdor gestiona tot el que hi ha per sota del teu codi: el sistema operatiu, el temps d'execució del llenguatge, el servidor d'aplicacions, el balanceig, l'escalat i el monitoratge bàsic. Tu lliures el codi i unes poques decisions de configuració.

Beanstalk se situa en un punt concret d'aquesta escala: més control que Lambda, molta menys feina que EC2. I, a diferència d'una PaaS tancada, no t'amaga la infraestructura: els recursos que crea són EC2, ASG, ALB i grups de seguretat normals, visibles a la consola i accessibles per la CLI. Pots entrar per SSH a les instàncies, mirar els registres i modificar l'ASG. Aquesta transparència és la seva virtut més gran, i també l'origen dels seus problemes quan algú toca a mà el que Beanstalk creu governar.

Quan crees un entorn, Beanstalk genera una plantilla de CloudFormation i desplega una pila. Ho has estat fent servir sense saber-ho des de 09-01: si llistes les piles d'un compte amb Beanstalk, en veuràs una anomenada awseb-e-abc123xyz-stack.

Això té tres conseqüències que convé tenir clares des del principi:

• No és màgia, és CloudFormation. Els mateixos estats, els mateixos temps i els mateixos límits de 09-01. Un desplegament que es queda a mitges deixa la pila en UPDATE_ROLLBACK_COMPLETE.
• La pila és de Beanstalk, no teva. Modificar-la directament trenca el model: Beanstalk la sobreescriurà en la següent operació. Tot canvi es fa a través de les opcions de configuració de Beanstalk.
• A cada instància hi ha un agent. És qui rep l'ordre de desplegar, descarrega la versió des d'S3, executa els ganxos i informa de l'estat. Quan alguna cosa falla de manera estranya, els seus registres a /var/log/eb-engine.log són el primer lloc on mirar.

Beanstalk té cinc conceptes i la confusió entre els tres primers és la causa del 80 % dels errors inicials.

La relació és d'un a molts a cada nivell: una aplicació té N versions i M entorns, i cada entorn té desplegada una versió concreta. Això encaixa perfectament amb la disciplina de 08-05: es construeix l'artefacte una vegada i aquest mateix objecte es promociona pels entorns. A Beanstalk es tradueix en eb deploy --version v1.6.0 sobre cada entorn, sense reconstruir res.

Les actualitzacions de plataforma mereixen atenció perquè són la feina que Beanstalk no elimina, només redueix. Cada branca de plataforma té versions (Python 3.12 running on 64bit Amazon Linux 2023/4.2.1) i AWS en publica una de nova cada poques setmanes amb correccions de seguretat. Hi ha dues maneres d'aplicar-les:

Les actualitzacions de plataforma gestionades són una de les raons de pes per triar Beanstalk: apliquen les correccions del sistema operatiu en una finestra definida, amb desplegament immutable i reversió automàtica si falla. És exactament la feina que al mòdul 2 obligava a reconstruir l'AMI a mà.

Beanstalk té dos tipus d'entorn, i el segon encaixa de manera gairebé literal amb l'arquitectura de MercadoFresco.

Un entorn de servidor web (web server) rep trànsit HTTP a través d'un ALB i té un nom DNS públic del tipus mercadofresco-tienda-produccion.eu-west-1.elasticbeanstalk.com.

Un entorn de treballador (worker) no té balancejador ni trànsit entrant. En comptes d'això, Beanstalk crea una cua d'SQS i desplega a cada instància un dimoni, sqsd, que llegeix missatges de la cua i els lliura a la teva aplicació com a peticions HTTP POST a localhost en una ruta configurable.

El detall important és com es tradueix el resultat: si el teu codi respon 200, sqsd esborra el missatge de la cua; si respon un error o exhaureix el temps, el missatge torna a la cua i, després de MaxRetries intents, va a la cua de missatges fallits. És exactament el patró de 07-01 i 07-05 —visibilitat, reintents i DLQ— però amb el bucle de consum escrit per AWS.

Això té un avantatge i un parany. L'avantatge: el teu codi de treballador es converteix en un manejador HTTP normal, sense biblioteca d'SQS, sense receive_message, sense gestió de la visibilitat. El parany: la idempotència continua sent responsabilitat teva, perquè un missatge es pot lliurar més d'una vegada exactament igual que a 07-05. La taula mercadofresco-idempotencia continua fent falta.

Beanstalk permet a més fer servir una cua existent en comptes de crear-ne una: a les opcions de l'entorn, aws:elasticbeanstalk:sqsd/WorkerQueueURL apunta a cola-mercadofresco-pedidos. Amb això, l'asg-mercadofresco-trabajadores del mòdul 7 es podria substituir per un entorn de treballador sense tocar ni la cua ni el productor. És el cas d'ús on Beanstalk continua sent competitiu avui a MercadoFresco.

Un apunt útil: sqsd admet també tasques periòdiques mitjançant un fitxer cron.yaml al paquet, amb la qual cosa substitueix una regla programada d'EventBridge per a treballs recurrents senzills.

Les dues últimes files mereixen un aclariment: Beanstalk pot desplegar contenidors, tant una imatge solta com diverses amb ECS per sota. És una via perfectament vàlida, però si l'arquitectura ha de ser de contenidors, el raonable és fer servir ECS o Fargate directament —mòdul 10— en comptes d'una capa que els embolcalla. La botiga de MercadoFresco és Python, així que encaixa a la primera fila.

El requisit de la plataforma Python és senzill: un objecte WSGI anomenat application a application.py, o la ruta indicada a la configuració, i un requirements.txt.

Aquesta única ordre eb create triga entre cinc i set minuts i crea l'ALB, el grup de destinació, l'ASG, la plantilla de llançament, dos grups de seguretat, el perfil d'instància d'IAM, dues alarmes de CloudWatch i el grup de registres. És el contingut d'aplicacion-mercadofresco.yaml de 09-01, sense escriure una línia. Aquesta frase és tot l'argument a favor de Beanstalk.

El cicle de treball diari és igual de curt:

Dos advertiments sobre eb deploy que provoquen sorpreses el primer dia. El primer: empaqueta el contingut del directori, no de l'últim commit —tret que facis servir eb deploy --staged o configuris artefactes—, així que un fitxer sense desar o un .env local pot acabar desplegat. El segon, conseqüència de l'anterior: eb deploy és exactament el «desplegar des del portàtil» que el mòdul 8 va eliminar. En un projecte seriós, eb deploy l'executa el pipeline, no una persona.

Beanstalk és opinat, però no tancat. Hi ha dos mecanismes de personalització i serveixen per a coses diferents.

.ebextensions/*.config són fitxers YAML dins del paquet que configuren l'entorn i els recursos: opcions de Beanstalk, paquets del sistema, fitxers, ordres i recursos de CloudFormation addicionals.

.platform/ és el mecanisme modern, disponible a les plataformes basades en Amazon Linux 2 i posteriors, i substitueix bona part de l'anterior amb fitxers normals en comptes de YAML:

Les opcions s'organitzen en espais de noms, i conèixer els principals estalvia molt de temps de cerca a la documentació:

Un exemple que en reuneix uns quants i que és, a la pràctica, la configuració mínima seriosa per a un entorn de producció de MercadoFresco:

Fixa't en PreferredStartTime: la finestra d'actualització de plataforma és una decisió de negoci, igual que la finestra de desplegament de 08-05. Un dimarts de matinada és acceptable; un divendres a la tarda, amb cinc vegades més comandes en joc, no.

Els límits d'aquest model són reals i convé conèixer-los abans de casar-se amb Beanstalk. leader_only només s'aplica en desplegaments, no quan l'ASG llança una instància nova, així que una migració a container_commands no s'executa en escalar —cosa que està bé— però tampoc no hi pots confiar per a inicialitzacions. Els ganxos s'executen a cada instància, així que tot el que facin ha de ser idempotent i ràpid: un ganxo lent multiplica el temps de desplegament pel nombre d'instàncies. I hi ha coses que senzillament no es poden canviar: l'estructura de la pila, el model d'un procés per instància o el fet que l'entorn sigui la unitat de tot.

Aquí és on Beanstalk es pot comparar de tu a tu amb CodeDeploy (08-03), i la comparació és instructiva.

Dues notes sobre les dues últimes, que són les úniques acceptables en producció:

Immutable és l'equivalent més proper al blue/green de 08-03 dins d'un mateix entorn: instàncies noves des de zero, sense residus de configuració, i si les comprovacions d'estat fallen es destrueixen les noves i no ha passat res. El seu avantatge sobre la renovació és que detecta problemes que només apareixen en una instància acabada d'arrencar —una dependència que ja no es descarrega, un permís que faltava— que en un desplegament per renovació queden emmascarats.

Blue/green per intercanvi de CNAME és el model de 08-03 portat a l'extrem: es crea un entorn complet amb la versió nova, es prova amb la seva pròpia URL i després eb swap intercanvia els CNAME dels dos entorns. És l'única opció que permet revertir en segons, perquè l'entorn blau continua viu.

I aquí arriba la comparació honesta amb 08-03, que té dues parts.

El que Beanstalk fa igual de bé: les polítiques cobreixen l'espectre complet de compromisos entre velocitat, cost i risc, i la immutable ofereix garanties reals sense configurar res.

El que no fa: no hi ha canari —no es pot enviar el 10 % del trànsit a la versió nova i observar—, no hi ha reversió automàtica basada en mètriques de negoci, no hi ha ganxos de cicle de vida equivalents a BeforeAllowTraffic amb una Lambda de validació, i l'intercanvi de CNAME depèn del TTL del DNS: els clients amb l'entrada a la memòria cau continuen anant a l'entorn vell durant minuts. La porta de qualitat de 08-04, amb els seus quinze minuts de mètriques i la seva reversió en noranta segons, no té equivalent aquí. Aquesta diferència és la que fa que una botiga amb 900 comandes/hora els divendres no es pugui conformar amb Beanstalk.

El problema que va obrir aquest mòdul —que preproducció no és igual que producció— també té resposta dins de Beanstalk, encara que més limitada que la de 09-02. Una configuració guardada és una foto de totes les opcions d'un entorn, emmagatzemada a S3 i aplicable a un altre:

El fitxer resultant és llegible i comparable amb diff, que és justament el que calia:

La diferència amb el config/entornos.ts de 09-02 és de grau: aquí la configuració es desa, es versiona i es compara, però no es genera des d'una sola font, així que res no impedeix que algú canviï una opció en un entorn i no a l'altre. És una foto, no un contracte.

Beanstalk i la infraestructura com a codi no són excloents: hi ha tipus de recurs natius, de manera que un entorn pot viure dins del model unificat de 09-01 i 09-02.

Això resol parcialment l'objecció de «la configuració viu al repositori de l'aplicació»: les opcions estructurals passen a la plantilla o al CDK, i .ebextensions es reserva per al que acompanya el codi. És la manera correcta de fer servir Beanstalk en un equip que ja practica infraestructura com a codi, i convé conèixer-la abans de descartar-lo per aquest motiu.

L'escalat és el del mòdul 2, perquè és un ASG: es configuren mínim, màxim i un disparador basat en una mètrica.

La peça pròpia de Beanstalk que sí que aporta valor real és l'estat millorat (enhanced health reporting). Un agent a cada instància combina mètriques del sistema, del servidor web i del balancejador i produeix un estat per instància i un estat global de l'entorn, amb causes concretes.

eb health --refresh mostra aquest tauler al terminal amb les causes —«el procés de l'aplicació no respon al port 8080»—, que és força més útil que un gràfic de CPU. L'estat millorat publica a més mètriques pròpies a CloudWatch (ApplicationRequests5xx, ApplicationLatencyP99, InstancesSevere), sobre les quals es poden muntar les alarmes de 05-01 i connectar-les a alertas-mercadofresco.

Un advertiment que costa disgustos: l'estat millorat no ve activat en tots els camins de creació, i sense ell Beanstalk es limita a la comprovació bàsica de l'ALB. Activa'l sempre; és gratis tret de les mètriques de CloudWatch.

Beanstalk permet crear una instància d'RDS dins de l'entorn, i és el parany més conegut del servei.

Si ho fas, la base de dades passa a formar part de la pila de l'entorn. Això significa que eb terminate l'esborra, que una recreació de l'entorn la recrea buida, i que la base de dades hereta el cicle de vida de l'aplicació, que és justament el contrari del que ha de passar: l'aplicació canvia quatre vegades per setmana i les dades han de sobreviure a tot. És el mateix principi de partició per cicle de vida de 09-01, i aquí es viola de manera flagrant.

És còmode per a una demostració o per a un entorn de desenvolupament que es destrueix cada nit. Per a qualsevol altra cosa, la base de dades viu a fora i l'entorn s'hi connecta:

La contrasenya no va en una variable d'entorn: va a Secrets Manager (04-03) i l'aplicació la resol en arrencar amb el rol d'instància, exactament igual que al mòdul 4. I la connectivitat es resol amb grups de seguretat com a 03-02: el SG que Beanstalk crea per a les instàncies s'autoritza com a origen a sg-mercadofresco-basedatos.

Si ja vas cometre l'error i tens la base de dades a dins, la sortida existeix però és incòmoda: instantània, restauració fora de l'entorn, canvi de la variable de connexió, verificació i desplegament. Amb una finestra de manteniment, perquè l'endpoint canvia.

Aquí hi ha el cor de la lliçó, i la resposta té dues parts que semblen contradictòries.

Beanstalk hauria estat una decisió excel·lent al mòdul 2. En aquell moment, MercadoFresco tenia un monòlit Python en un servidor, un equip de tres persones sense experiència a AWS i quatre problemes urgents. Beanstalk n'hauria resolt dos —les caigudes dels divendres, amb autoescalat i balancejador; i bona part del risc de desplegament, amb la política immutable— en una tarda en comptes de en tres mòduls. El cost hauria estat idèntic, perquè Beanstalk no cobra res, i l'equip hauria guanyat mesos.

I avui ja no encaixa. No perquè Beanstalk sigui pitjor del que era, sinó perquè l'arquitectura ha canviat per sota:

La botiga web és avui una peça d'una arquitectura de vint, i Beanstalk està dissenyat per ser *l'*arquitectura. Ficar la botiga en un entorn de Beanstalk deixaria el 80 % del sistema fora, gestionat amb CDK, i crearia dos models d'infraestructura convivint: la pitjor de les dues opcions.

El criteri general, que serveix més enllà d'aquest cas:

I hi ha un cas concret on sí que continua tenint sentit per a MercadoFresco avui: els treballadors. Un entorn de treballador apuntant a cola-mercadofresco-pedidos eliminaria el codi de consum, la gestió de visibilitat i l'escalat de l'asg-mercadofresco-trabajadores, a canvi d'acceptar un segon model per a una peça acotada. La Marta ho deixa anotat com a opció a avaluar, no com a decisió presa.

App Runner és, en certa manera, «el Beanstalk dels contenidors»: li dones una imatge o un repositori i ell s'encarrega de tot, inclòs l'escalat a partir de zero peticions. És més simple que Beanstalk i també més limitat: control de xarxa reduït i menys opcions de desplegament.

Amplify resol un problema diferent —aplicacions web frontals amb allotjament, CI/CD i backend gestionat—, i per a MercadoFresco seria rellevant si el catàleg se servís com a aplicació d'una sola pàgina, no com a substitut de la botiga.

Fargate és la comparació important, i es desenvolupa a 10-02. La diferència essencial amb Beanstalk és què desapareix: Beanstalk gestiona les instàncies per tu, però continuen existint, cal apedaçar-les i triguen dos minuts a arrencar; Fargate elimina les instàncies, i la unitat passa a ser el contenidor. És exactament el problema amb què es tanca aquest mòdul.

Un temor raonable abans d'adoptar qualsevol PaaS és quedar-se tancat. Amb Beanstalk el tancament és moderat, i convé saber per què abans de decidir.

El que no és específic de Beanstalk: el teu codi, que és una aplicació WSGI normal; els recursos que crea, que són EC2, ASG i ALB estàndard; i la base de dades, si la vas posar a fora. El que sí que ho és: els fitxers .ebextensions, el dimoni sqsd dels treballadors, les variables d'entorn definides a l'entorn i els ganxos de .platform.

La via de sortida, en cinc passos i sense tall de servei:

1. Treure l'estat. Si la base de dades era a dins, es treu primer. No es mou res més fins que això estigui fet.
2. Traduir la configuració. Cada option_setting té el seu equivalent en CDK o CloudFormation, i cada ganxo, el seu lloc a l'AppSpec de CodeDeploy o a les dades d'usuari de la plantilla de llançament.
3. Aixecar la infraestructura nova en paral·lel, amb el seu propi ALB i el seu propi grup de destinació, sense trànsit.
4. Moure el trànsit gradualment amb Route 53 (03-05), amb encaminament ponderat: 10 %, 50 %, 100 %, observant les mètriques a cada esglaó. Això és el que Beanstalk no oferia i que aquí sí que es pot fer.
5. Acabar l'entorn de Beanstalk quan porti una setmana sense trànsit.

La lliçó general val per a qualsevol decisió d'aquest tipus: el tancament no es mesura pel servei, sinó per on viu l'estat i quanta configuració és específica. Si l'estat és a fora i la configuració és traduïble, començar pel que és simple i migrar després és una estratègia perfectament raonable, i gairebé sempre millor que construir l'arquitectura definitiva abans de tenir clients.

Beanstalk no cobra: pagues EC2, l'ALB, EBS, el trànsit i les mètriques de CloudWatch. Un entorn de producció típic de MercadoFresco —dos m6i.large, un ALB, estat millorat— voltaria els 165 USD al mes, exactament el mateix que costaria muntat a mà, perquè són els mateixos recursos.

Dues fonts de despesa invisible: les versions d'aplicació s'acumulen a S3 sense esborrar-se, i el límit per omissió és de 1.000 versions, després del qual els desplegaments fallen amb un error que no menciona la causa; i els entorns de desenvolupament oblidats, que costen el mateix que els de producció si tenen ALB. Un entorn amb --single (una instància amb IP elàstica i sense balancejador) baixa el cost d'un entorn de proves a menys de 10 USD al mes, i és el correcte per a desenvolupament.

eb terminate esborra la pila de CloudFormation subjacent i amb ella tots els recursos de l'entorn. Si vas crear la base de dades a dins, allà se'n va.

Error: crear la base de dades dins de l'entorn. És l'error clàssic i el més car. Consell: RDS i Aurora sempre a fora, connectats per variables d'entorn i grups de seguretat. L'única excepció és un entorn de desenvolupament rebutjable.

Error: modificar a mà els recursos que Beanstalk gestiona. Canviar l'ASG des de la consola sembla que funciona fins a la següent operació de l'entorn, que el sobreescriu. Consell: tot canvi, per option_settings o per eb config.

Error: confondre aplicació, versió i entorn. Molts «no es desplega el meu canvi» són en realitat un eb deploy contra l'entorn equivocat. Consell: eb status abans de desplegar i eb use per fixar l'entorn per defecte.

Error: fer servir «totes alhora» en producció. Està per omissió en alguns camins de creació i produeix un tall de servei a cada desplegament. Consell: Immutable o blue/green per CNAME en producció; «totes alhora» només en desenvolupament.

Error: desplegar des del portàtil amb eb deploy. Empaqueta el que hi ha al directori i se salta tot el pipeline. Consell: que ho executi CodeBuild amb --version sobre un artefacte ja construït.

Error: no activar l'estat millorat. Sense ell, el diagnòstic es queda en «unhealthy» sense causa. Consell: activa'l sempre i munta alarmes sobre ApplicationRequests5xx i InstancesSevere.

Consell: desa configuracions amb eb config save. Produeixen una plantilla reutilitzable amb la qual crear entorns idèntics: és la manera que té Beanstalk d'evitar que preproducció i producció divergeixin.

Consell: si fas servir entorns de treballador, apunta a la cua existent. WorkerQueueURL evita duplicar cues i permet conviure amb la resta de l'arquitectura de 07-01.

Consell: revisa /var/log/eb-engine.log abans que cap altre registre. Quan un desplegament falla sense motiu aparent, la causa sol ser-hi, no als registres de l'aplicació.

Consell: posa una política de cicle de vida de versions el primer dia. El límit de 1.000 versions s'assoleix abans del que sembla amb un pipeline actiu, i l'error que produeix no diu que el problema siguin les versions.

Consell: fes servir --single als entorns de desenvolupament. Sense balancejador, el cost cau a menys d'una cinquena part i per desenvolupar no es perd res rellevant.

Consell: activa les actualitzacions de plataforma gestionades amb una finestra explícita. És l'avantatge de Beanstalk que més feina estalvia a llarg termini, i la que més gent deixa sense configurar. Dimarts de matinada, mai divendres.

La Marta vol avaluar seriosament substituir l'asg-mercadofresco-trabajadores per un entorn de treballador de Beanstalk que consumeixi de cola-mercadofresco-pedidos. Descriu com el muntaries: quin tipus d'entorn, com es connecta a la cua existent, què canvia al codi del treballador respecte al consum actual amb receive_message, què passa amb la DLQ mercadofresco-pedidos-fallidos i amb la idempotència de 07-05, com es configura l'escalat i quina política de desplegament faries servir. Acaba amb tres arguments a favor i tres en contra de fer el canvi.

Per a cadascun d'aquests quatre casos, tria política de desplegament de Beanstalk i justifica-la en termes de temps, cost, risc i capacitat disponible: (a) entorn de desenvolupament on el Luis desplega quinze vegades al dia; (b) preproducció, on es valida cada versió abans de producció; (c) producció un dimarts al matí amb una versió que només canvia textos; (d) producció un dijous amb una versió que canvia la biblioteca d'accés a la base de dades i el procés d'arrencada. Indica en quins la reversió és ràpida i com es fa exactament.

Imagina que MercadoFresco hagués adoptat Beanstalk al mòdul 2, amb la botiga monolítica en un entorn de servidor web i Aurora fora de l'entorn. Han passat els vuit mòduls del curs i han aparegut les mateixes necessitats: cues, Lambda, CloudFront, WAF, DynamoDB, un pipeline amb canari. Respon: (a) en quin moment exacte del curs Beanstalk hauria començat a fer nosa i per què; (b) quines tres necessitats concretes no hauria pogut cobrir; (c) si la sortida hauria estat més cara que no haver-hi entrat mai; (d) quina regla general n'extreus per triar el nivell d'abstracció d'una plataforma.

Solució 1

El muntatge. Un entorn de treballador (eb create mercadofresco-trabajadores --tier worker) sobre la mateixa plataforma Python, a les subxarxes snet-mercadofresco-app-a/-b de la VPC existent i amb el SG sg-mercadofresco-tienda o un de propi que pugui arribar a Aurora i ElastiCache. La connexió a la cua existent es fa amb les opcions d'sqsd, no creant una cua nova:

Què canvia al codi. Desapareix tot el bucle de consum: receive_message, delete_message, la gestió de la visibilitat, el control del lot i el maneig de reintents. El treballador passa a ser un manejador HTTP: rep un POST a /tareas/pedido amb el cos del missatge, processa i retorna 200. Un error o un temps exhaurit es tradueix en un codi diferent de 2xx i el missatge torna a la cua. És menys codi i menys superfície d'error, i el rol d'instància només necessita permisos de lectura i esborrat sobre la cua.

La DLQ i la idempotència. La DLQ no canvia en absolut: continua sent la política de reintents de la mateixa cua d'SQS, definida al seu RedrivePolicy amb maxReceiveCount, i mercadofresco-pedidos-fallidos continua rebent el que exhaureixi els intents. Hi ha un matís important: MaxRetries d'sqsd i maxReceiveCount de la cua són dos comptadors diferents, i mana el menor dels dos; configurar-los amb valors incoherents produeix el clàssic «els missatges no arriben mai a la DLQ». La idempotència continua sent responsabilitat del codi: sqsd no aporta cap garantia de lliurament únic, així que la taula mercadofresco-idempotencia de 07-05 es manté tal qual.

Escalat i desplegament. Escalat per profunditat de la cua, no per CPU: una alarma sobre ApproximateNumberOfMessagesVisible de cola-mercadofresco-pedidos connectada al disparador de l'ASG. És el correcte per a un treballador, perquè la CPU pot estar baixa mentre s'acumulen milers de missatges esperant la base de dades. Política de desplegament immutable: un treballador no atén usuaris, així que no hi ha pressa, i a canvi s'obtenen instàncies netes amb validació completa abans d'acceptar càrrega.

Tres a favor: desapareix codi d'infraestructura del treballador —el bucle de consum és on vivien dos errors del mòdul 7—; les correccions del sistema operatiu passen a ser actualitzacions gestionades; i l'escalat i les comprovacions d'estat vénen resolts.

Tres en contra: introdueix un segon model d'infraestructura convivint amb el CDK, que és exactament el que la lliçó anterior va evitar; la configuració del treballador es reparteix entre .ebextensions al repositori de l'aplicació i el CDK a mercadofresco-infra, amb la qual cosa la font de veritat deixa de ser única; i el model HTTP amaga el control fi del lot, que en el pic dels divendres pot importar.

Veredicte raonable: tècnicament funciona bé i és el millor encaix de Beanstalk a MercadoFresco avui, però l'argument de la unitat del model pesa més. Si l'avaluació es fa, s'ha de fer comparant-lo amb Fargate (10-02), que resol el mateix sense obrir un segon model.

Solució 2

(a) Desenvolupament, quinze desplegaments al dia: totes alhora. És la més ràpida —un parell de minuts—, no costa instàncies extra i el tall de servei no importa perquè només el pateix el Luis. Amb quinze desplegaments diaris, qualsevol política més lenta es tradueix en hores perdudes a la setmana. Reversió: tornar a desplegar la versió anterior; triga el mateix i no passa res.

(b) Preproducció: immutable. Encara que el risc de negoci sigui nul, preproducció existeix per assajar el desplegament de producció, i assajar-lo amb una altra política no assaja res. A més, la immutable és la que detecta els problemes d'arrencada en fred, que és precisament el que es vol descobrir abans de producció. El cost extra és acceptable perquè els desplegaments són pocs.

(c) Producció, dimarts, només textos: renovació amb lot addicional. El canvi és de baix risc i no toca dependències ni arrencada, així que la garantia extra de la immutable no compensa el seu temps. El lot addicional manté el 100 % de capacitat durant tot el procés —crític en una botiga— a canvi d'una sola instància extra durant uns minuts. Reversió: redesplegar la versió anterior amb la mateixa política; uns minuts.

(d) Producció, dijous, biblioteca de base de dades i arrencada: blue/green per intercanvi de CNAME. És el cas de més risc de l'exercici: un canvi al procés d'arrencada pot fallar només en instàncies noves, i un canvi de biblioteca de base de dades pot degradar el rendiment sense fallar cap comprovació d'estat. L'entorn verd permet executar les proves de fum amb trànsit real controlat i, sobretot, l'entorn blau continua viu: la reversió és un eb swap de tornada, en segons.

I la lectura transversal, que enllaça amb 08-05: la reversió és ràpida només a (d). A (a), (b) i (c) revertir significa desplegar una altra vegada, és a dir, minuts amb el sistema en l'estat dolent. Aquesta és la diferència real entre blue/green i tota la resta, i el motiu pel qual la política es tria pel risc del canvi, no per costum. Un detall final: l'eb swap depèn del TTL del CNAME, així que convé baixar-lo a 60 segons dies abans d'un desplegament així.

Solució 3

(a) Beanstalk hauria començat a fer nosa al mòdul 7, amb la integració d'aplicacions. Fins allà, l'arquitectura era una aplicació web amb una base de dades, i això és exactament el que Beanstalk fa bé; el mòdul 3 (VPC, ALB, CloudFront) i el 4 (IAM, WAF) haurien conviscut sense problema, perquè Beanstalk es pot desplegar en una VPC existent i CloudFront es posa davant de qualsevol ALB. El punt d'inflexió és el moment en què l'aplicació deixa de ser un procés i passa a ser un sistema de peces coordinades: cues, temes, un bus i una màquina d'estats que Beanstalk no gestiona. A partir d'aquí, l'entorn passa de ser «l'arquitectura» a ser «una peça més», que és justament el que no és.

(b) Tres necessitats no cobertes: el desplegament canari amb reversió automàtica per mètriques de negoci de 08-03 i 08-04, que no té equivalent; l'orquestració de les cinc Lambda i la màquina d'estats de 07-04, completament fora del seu àmbit; i la infraestructura com a codi unificada i revisable d'aquest mòdul, perquè la configuració de Beanstalk viu a .ebextensions dins del repositori de l'aplicació, barrejant dos cicles de vida que 09-01 recomana separar.

(c) No, la sortida no hauria estat més cara que no haver-hi entrat. Amb la base de dades a fora —que era la condició de l'enunciat—, l'estat no queda atrapat, i el que cal traduir són option_settings i ganxos, una feina de dies, no de mesos. La migració s'hauria fet amb encaminament ponderat de Route 53 sense tall de servei. Davant d'això, l'alternativa era haver construït al mòdul 2 una infraestructura que l'equip encara no sabia dissenyar, per a una arquitectura que encara no existia: probablement s'hauria fet malament i s'hauria hagut de refer igualment, però sense haver tingut res en producció mentrestant. El cost d'entrar i sortir és real, però és menor que el cost de la paràlisi inicial.

(d) La regla general. Tria el nivell d'abstracció més alt que cobreixi els teus requisits actuals, sempre que l'estat quedi a fora i la configuració sigui traduïble. Les tres condicions importen: «requisits actuals» i no imaginats, perquè construir per a una arquitectura futura que potser no arribarà és la manera més cara d'equivocar-se; «l'estat a fora», perquè és l'única cosa que no es migra sense dolor; i «configuració traduïble», perquè és el que converteix el canvi de plataforma en un projecte de dies. La regla s'aplica cap amunt i cap avall: per això MercadoFresco, que avui necessita control fi, fa servir CDK, i per això mateix a 10-02 es plantejarà tornar a pujar el nivell d'abstracció amb Fargate.

Elastic Beanstalk converteix un fitxer comprimit i una cadena amb la versió del llenguatge en una aplicació en producció amb balancejador, autoescalat, grups de seguretat, alarmes i perfil d'instància, i ho fa generant una plantilla de CloudFormation i desplegant una pila —awseb-e-xxxx-stack— amb les mateixes regles de 09-01. És una plataforma com a servei que no amaga la infraestructura: pots entrar per SSH, mirar els registres i veure els recursos, amb la contrapartida que modificar-los a mà trenca el model, perquè Beanstalk els sobreescriu en la següent operació.

Tens els seus cinc conceptes, i en particular la separació entre versió d'aplicació —l'artefacte immutable de 08-02, que es promociona amb eb deploy --version— i entorn, que és on hi ha tot el cost. Tens els entorns de treballador, amb sqsd traduint missatges d'SQS en peticions HTTP a localhost: el bucle de consum escrit per AWS, amb l'advertiment que la idempotència continua sent teva i que MaxRetries i maxReceiveCount són dos comptadors diferents on mana el menor. I tens la personalització amb .ebextensions i .platform, amb leader_only per a les migracions i l'avís que un ganxo lent multiplica el temps de desplegament pel nombre d'instàncies.

Les cinc polítiques de desplegament cobreixen l'espectre complet entre velocitat, cost i risc, i la comparació amb 08-03 és la part més útil de la lliçó: la immutable dóna garanties reals sense configurar res i detecta les fallades que només apareixen en instàncies acabades d'arrencar; el blue/green per intercanvi de CNAME és l'única cosa que permet revertir en segons, amb la salvetat del TTL del DNS. Però no hi ha canari, ni reversió automàtica per mètriques de negoci, ni ganxos de validació, i aquesta absència és la que descarta Beanstalk per a una botiga amb 900 comandes/hora els divendres. Més el parany més conegut del servei: la base de dades mai dins de l'entorn, perquè eb terminate se l'emporta.

I la decisió honesta, que té dues cares. Beanstalk hauria estat excel·lent al mòdul 2 —un monòlit, tres persones sense experiència a AWS, dos dels quatre problemes resolts en una tarda i cost idèntic, perquè el servei és gratis—. I avui ja no encaixa, no perquè hagi empitjorat, sinó perquè la botiga web va passar de ser l'arquitectura a ser una peça de vint: cinc Lambda, quatre cues, un bus, una màquina d'estats, quatre bases de dades i un pipeline amb canari que quedarien fora de l'entorn, obligant a mantenir dos models d'infraestructura alhora. La regla que en queda és més valuosa que el servei: tria el nivell d'abstracció més alt que cobreixi els teus requisits actuals, sempre que l'estat quedi a fora i la configuració sigui traduïble, perquè llavors la via de sortida és un projecte de dies i no una condemna.

Queda un problema que Beanstalk tampoc no resolia i que cap de les tres lliçons d'aquest mòdul no ha tocat encara. Tota la infraestructura de MercadoFresco —les nou piles del CDK, els tres entorns, el pipeline que es desplega a si mateix— viu en un sol compte, el 111122223333. Un cdk destroy mal dirigit arriba a producció, les quotes d'adreces IP elàstiques i d'instàncies es comparteixen entre desenvolupament i producció, cap política d'IAM no aïlla del tot qui ja té permisos amplis, i la factura no separa de veritat el que costa cada entorn. La infraestructura és reproduïble, però el radi d'explosió no està acotat.

A 09-04, «AWS Organizations», es tanca el mòdul atacant exactament això: comptes separats per entorn, unitats organitzatives, polítiques de control de serveis que limiten el que es pot fer fins i tot sent administrador, facturació consolidada, accés amb IAM Identity Center perquè la Marta, el Luis i la Sara treballin en quatre comptes sense multiplicar usuaris, i una línia base que es desplega sola a cada compte nou amb els StackSets de 09-01.