Lambda és meravellós, però no és una bala de plata. Com tota eina, té límits tècnics i hi ha situacions on fer-la servir és una mala idea (antipatrons). Tanquem el capítol aprenent a reconèixer quan Lambda no és la resposta correcta: saber-ho t’estalviarà disgustos i et farà un millor arquitecte.

Lambda imposa una sèrie de restriccions. No cal memoritzar números exactes (canvien amb el temps), però sí conèixer què està limitat:

El límit més important de recordar és el dels 15 minuts: una funció Lambda no pot executar-se més de 15 minuts. Si la teva tasca triga més, Lambda no és l’eina.

Un antipatró és fer servir una eina per a una cosa per a la qual no està pensada. Aquests són els casos on Lambda no encaixa:

Si un procés triga més de 15 minuts (processar un vídeo enorme, un càlcul científic, una migració massiva de dades), Lambda el tallarà a la meitat.

Millor alternativa: contenidors (ECS/Fargate, Capítol 17), instàncies EC2, o serveis de processament per lots. Per a fluxos llargs formats per passos curts, es poden orquestrar diverses Lambdes amb Step Functions (Capítol 28).

Lambda és genial per a trànsit intermitent o impredictible (pagues només per ús). Però si tens un trànsit enorme i constant les 24 hores, els milers de milions d’execucions poden sortir més cares que un grup de servidors sempre encesos.

Millor alternativa: EC2 amb Auto Scaling (Capítol 13) o contenidors, que a volum constant molt alt poden ser més econòmics. (Convé fer números: depèn molt del cas.)

Lambda és sense estat (stateless): cada invocació pot executar-se en un entorn diferent, i no pots confiar que la memòria es conservi entre crides. Si la teva aplicació necessita mantenir dades en memòria entre peticions (una sessió d’usuari en RAM, una memòria cau local persistent), Lambda no és adequat.

Millor alternativa: guardar l’estat fora de la funció, en serveis pensats per a això: DynamoDB (subcapítol 8.3), ElastiCache (subcapítol 8.4) o S3 (Capítol 5). Aquesta és, de fet, la forma correcta de dissenyar: l’estat va a un servei extern, no a la funció.

Com que Lambda pot crear milers d’execucions en paral·lel, cadascuna intentant obrir una connexió a una base de dades relacional (RDS, Capítol 8), pot esgotar les connexions disponibles i tombar la base de dades.

Millor alternativa: fer servir RDS Proxy (que gestiona i reutilitza les connexions), bases de dades serverless com Aurora Serverless (subcapítol 8.2) o DynamoDB, que escalen millor amb Lambda.

Si necessites latència ultrabaixa i garantida en cada petició, i els cold starts (subcapítol 14.4) són un problema constant fins i tot amb provisioned concurrency, potser un servei sempre encès sigui millor.

Lambda no substitueix els servidors: és una altra eina més a la teva caixa. Un bon arquitecte combina serveis: fa servir Lambda per al processament d’esdeveniments i les tasques curtes, contenidors o EC2 per a càrregues constants i llargues, i serveis gestionats (DynamoDB, S3, cues) per a l’estat i les dades.

La pregunta clau no és «faig servir Lambda?», sinó «quina eina encaixa millor amb aquesta feina concreta?». A vegades és Lambda, a vegades no, i moltes arquitectures reals en fan servir diverses alhora.

• Lambda té límits: el més important és el de 15 minuts màxims d’execució; també hi ha límits de memòria, mida de paquet, emmagatzematge temporal i concurrència.
• Antipatrons (quan NO fer servir Lambda): tasques de més de 15 min, trànsit constant altíssim 24/7, necessitat d’estat en memòria entre peticions, i mala gestió de connexions a bases de dades relacionals a gran escala.
• L’estat ha d’anar fora de la funció (DynamoDB, ElastiCache, S3): Lambda és sense estat.
• Alternatives segons el cas: ECS/Fargate o EC2 (tasques llargues/constants), Step Functions (fluxos llargs per passos), RDS Proxy / Aurora Serverless / DynamoDB (bases de dades a escala).
• La pregunta correcta és «quina eina encaixa millor amb aquesta feina?», no «faig servir Lambda per a tot?».

Has acabat el Capítol 14 i domines els fonaments de serverless! Al Capítol 15 veurem les peces que connecten totes aquestes funcions i serveis: la missatgeria i els esdeveniments (SQS, SNS, EventBridge), clau per construir sistemes desacoblats.