¿Qué causa los cold starts en las funciones serverless y cómo los manejas?

Un cold start ocurre cuando llega una petición y no hay ningún entorno de ejecución caliente disponible, así que la plataforma tiene que aprovisionar uno, descargar y descomprimir tu código, arrancar el runtime y ejecutar tu inicialización antes de atender la petición. Redúcelo achicando el paquete, eligiendo un runtime más ligero, sacando la configuración pesada del camino de la petición y reutilizando conexiones. Para los caminos sensibles a la latencia, usa concurrencia aprovisionada en vez de trucos de calentamiento.

Un cold start es la plataforma construyendo un entorno de ejecución nuevo porque no hay uno caliente libre. Eso significa aprovisionarlo, descargar y descomprimir tu artefacto, arrancar el runtime y ejecutar tu código de inicialización antes de que se llame siquiera a tu handler. Las partes que controlo son el tamaño del artefacto y la inicialización, así que recorto dependencias sin piedad, porque un paquete gordo añade tiempo real a cada cold start, y saco cosas como la carga de configuración y la construcción de clientes fuera del handler para que se ejecuten una vez por entorno en lugar de una vez por petición y se reutilicen en las invocaciones calientes. La elección de runtime también importa; un runtime ligero arranca mucho más rápido que una máquina virtual pesada salvo que use la función de snapshot de la plataforma. Cuando el camino es de cara al usuario y la latencia de cola importa, dejo de optimizar y compro concurrencia aprovisionada para la base esperada, porque eso mantiene entornos ya inicializados. Lo que ya no hago es hacer ping a las funciones con un temporizador para mantenerlas calientes; no es fiable con concurrencia real. Para trabajo dirigido por colas o por lotes normalmente lo acepto sin más.