Lambda té una característica molt comentada: els cold starts (arrencades en fred). És el «preu» que a vegades es paga pel model sota demanda del subcapítol 14.1. En aquest subcapítol entendràs què són, per què passen i què pots fer per reduir-ne l’impacte.

Recorda com funciona Lambda: el teu codi no està sempre encès, sinó que AWS l’arrenca quan arriba un esdeveniment. Doncs bé, aquesta arrencada té dos escenaris:

• Cold start (arrencada en fred): és la primera vegada que s’invoca la funció (o després d’una estona sense usar-se). AWS ha de preparar l’entorn des de zero: reservar recursos, carregar el teu codi, inicialitzar el runtime (Python, Java...), carregar les llibreries. Això afegeix un retard extra, normalment de centenars de mil·lisegons a un parell de segons.

• Warm start (arrencada en calent): si la funció s’ha usat fa poc, AWS reutilitza l’entorn que ja estava preparat. Aquí no hi ha retard de preparació: la funció respon a l’instant.

Analogia: un cold start és com arrencar un cotxe un matí d’hivern: el motor fred triga una mica a posar-se a punt. Un cop en marxa (calent), arranques i accel·leres a l’instant. Si el deixes aparcat una bona estona, torna a refredar-se.

L’impacte del cold start depèn del tipus d’aplicació:

• Importa en aplicacions interactives on l’usuari espera una resposta ràpida (una API que respon a una app mòbil). Un retard d’1-2 segons en la primera petició pot notar-se.
• No importa en tasques de fons o asíncrones (processar un fitxer pujat, buidar una cua). Si la tasca triga uns segons més a començar, a ningú li afecta.

També depèn del llenguatge: runtimes lleugers com Python o Node.js tenen cold starts curts; runtimes més pesats com Java o .NET arranquen més a poc a poc (tot i que hi ha tècniques per millorar-ho).

És la solució més directa: li dius a AWS que mantingui un nombre d’entorns sempre calents i a punt, esperant peticions. Així, aquestes invocacions mai pateixen cold start.

És com tenir diversos cotxes amb el motor ja encès a l’aparcament, a punt per sortir. El compromís: pagues per mantenir-los calents (fins i tot sense ús), així que s’utilitza quan la latència de la primera petició és crítica.

Una tècnica senzilla: programar una invocació cada pocs minuts (amb CloudWatch, recorda el subcapítol 14.2) perquè l’entorn no es refredi. És un truc econòmic, tot i que menys fiable que la provisioned concurrency, sobretot si hi ha moltes peticions simultànies.

Com menys codi i llibreries hagi de carregar AWS, més ràpida és l’arrencada. Per això convé:

• Incloure només les llibreries que realment utilitzes (recorda el subcapítol 14.3).
• Usar capes per no inflar el paquet.
• Evitar dependències pesades innecessàries.

Si el cold start és crític i pots triar llenguatge, Python o Node.js solen arrencar més ràpid que Java o .NET. (Per Java existeixen optimitzacions específiques, però d’entrada és més pesat.)

El que poses fora del handler (connexions, configuració) s’executa una sola vegada per entorn i es reutilitza en els warm starts. Aprofitar-ho bé evita repetir feina costosa a cada invocació:

No al principi. Per a la majoria d’aplicacions, els cold starts ocasionals són perfectament assumibles, i runtimes com Python o Node els fan molt suportables. Preocupa-te’n només si tens una aplicació interactiva sensible a la latència i mesures que els cold starts molesten els usuaris. Llavors aplica la provisioned concurrency i la resta d’estratègies. Recorda: optimitzar abans de tenir un problema mesurat sol ser temps perdut.

• Un cold start (arrencada en fred) és el retard extra la primera vegada que s’invoca una Lambda (o després d’una estona sense ús), perquè AWS prepara l’entorn des de zero. En els warm starts aquest entorn es reutilitza i no hi ha retard.
• Importa en aplicacions interactives sensibles a la latència; no importa en tasques de fons. Runtimes lleugers (Python, Node) arranquen més ràpid.
• Estratègies: Provisioned Concurrency (entorns sempre calents), invocacions periòdiques, reduir la mida del paquet, runtime lleuger i inicialitzar connexions fora del handler per reutilitzar-les.
• No t’obsessionis d’entrada: optimitza els cold starts només si mesures que afecten de veritat els teus usuaris.

A l’últim subcapítol del capítol veurem els límits de Lambda i els antipatrons: quan Lambda no és l’eina adequada.