Tu función Lambda casi nunca está sola: necesita librerías (código de terceros) para hacer su trabajo —conectarse a una base de datos, procesar imágenes, llamar a una API—. En este subcapítulo veremos cómo se incluyen esas dependencias en una Lambda y cómo las capas (Layers) te permiten compartirlas y mantener tu función ligera.

Imagina una Lambda en Python que redimensiona imágenes. Para ello usa una librería popular como Pillow. Pero esa librería no viene incluida en Lambda por defecto: tienes que empaquetarla junto a tu código.

Si no incluyes la librería, al ejecutarse la función fallará con un error tipo «módulo no encontrado». Así que el reto es: ¿cómo meto las librerías en mi Lambda?

La forma más directa es incluir las librerías dentro del paquete que subes a Lambda. Instalas las dependencias en una carpeta junto a tu código y subes todo junto, normalmente en un archivo ZIP:

Funciona, pero tiene un inconveniente: si tienes muchas funciones que usan las mismas librerías, acabas repitiendo esas librerías en cada paquete. El código se duplica, los paquetes se hacen grandes y mantenerlos es engorroso (si actualizas una librería, hay que rehacer todos los paquetes).

Una capa (Layer) es un paquete de librerías o código común que puedes compartir entre varias funciones. En vez de meter las librerías en cada función, las pones una vez en una capa y luego conectas esa capa a todas las funciones que la necesiten.

Cada función incluye solo su propio código, y «toma prestadas» las librerías de la capa.

Analogía: una capa es como la despensa compartida de un edificio de apartamentos. En vez de que cada vecino tenga su propio saco de harina y azúcar (duplicado), hay una despensa común donde todos cogen lo que necesitan. Si hay que reponer la harina, se hace una vez para todos.

• Menos duplicación: las librerías comunes están en un solo sitio, no repetidas en cada función.
• Funciones más ligeras: tu paquete solo lleva tu código, así que es pequeño y se sube/despliega más rápido.
• Mantenimiento centralizado: actualizas la librería en la capa y todas las funciones se benefician.
• Reutilización: puedes tener una capa de «utilidades propias» que comparten todos tus equipos.

Ejemplo del mundo real: una empresa tiene 15 funciones Lambda que se conectan a la misma base de datos y usan las mismas utilidades internas (logging, validaciones). Crean una capa utilidades-empresa con todo ese código común. Las 15 funciones la usan. Cuando mejoran una utilidad, actualizan la capa una vez y las 15 funciones la heredan, sin tocar el código de cada una.

Para empezar: si tienes una sola función o estás aprendiendo, empaquetar las librerías junto al código es lo más sencillo. Las capas tienen sentido cuando creces y empiezas a repetir las mismas dependencias en varias funciones.

Lambda tiene límites de tamaño para el paquete de código y las capas (lo veremos en el subcapítulo 14.5). Por eso es importante no incluir librerías que no uses: cuanto más ligera sea la función, más rápido arranca (lo que conecta con los «cold starts» del siguiente subcapítulo). Si tus dependencias son muy grandes, existe también la opción de empaquetar la Lambda como una imagen de contenedor (recuerda Docker, que veremos en el Capítulo 17), que admite paquetes mucho mayores.

• Tu Lambda necesita sus dependencias (librerías de terceros) incluidas; si faltan, falla al ejecutarse.
• Opción 1 — empaquetar con el código: metes las librerías en el ZIP junto a tu función. Sencillo, pero duplica las librerías si tienes muchas funciones.
• Opción 2 — capas (Layers): pones las librerías o el código común una vez en una capa y la compartes entre varias funciones. Como una «despensa común».
• Las capas reducen duplicación, mantienen las funciones ligeras y permiten mantenimiento centralizado.
• Para empezar, empaquetar junto al código es lo más fácil; usa capas cuando repitas dependencias en varias funciones.

En el siguiente subcapítulo abordaremos uno de los temas más característicos de Lambda: los cold starts (arranques en frío) y cómo reducirlos.