En cuanto a la optimización del rendimiento de
Lambda, que debería ser ampliamente aplicable para la mayoría de las personas. Cuando se utiliza
Node.js y aún se utiliza la versión 2 del
AWS SDK, entonces es necesario configurar esta variable de entorno en todas sus funciones de
Lambda para habilitar el mantenimiento de la conexión HTTP, lo que le ahorrará aproximadamente de 10 a 20 milisegundos en cada solicitud que realice desde su función de
Lambda a otros servicios de
AWS.
Si está utilizando
Lambda con RDS, entonces debe utilizar los proxies de base de datos para gestionar el agrupamiento de conexiones. De lo contrario, es probable que se encuentre con problemas, ya que tiene demasiadas conexiones al clúster de RDS. En cuanto a los inicios de código, tener artefactos de implementación más pequeños también significa un tiempo de inicio más rápido. Pero desafortunadamente, agregar más memoria en realidad no ayuda a reducir el tiempo de inicio, porque durante el inicio, su función de
Lambda ya ejecuta el código de inicialización a plena capacidad de la CPU. Esto es cierto para, hasta donde yo sé, todos los tiempos de ejecución de lenguajes excepto Java, porque en Java parte de la inicialización ocurre durante la primera invocación después de la inicialización. Por eso creo que cuando se trata de Java, los recursos adicionales de la CPU que se obtienen al tener la configuración de memoria más alta también pueden ayudar a reducir el tiempo de inicio. Pero ese no es el caso para ninguno de los otros tiempos de ejecución de lenguajes que he probado. Lo que te ayudará más en términos de reducir el tiempo de inicio es simplemente recortar tus dependencias, tener menos dependencias, eso significa un artefacto de implementación más pequeño, pero también menos tiempo para que el tiempo de ejecución inicialice tus funciones. Y una cosa que encontré realmente útil es empaquetar mis dependencias en una capa de
Lambda para que no tenga que cargarlas cada vez cuando no hayan cambiado entre implementaciones. Y es una excelente manera de optimizar el tiempo de implementación, ayudándote a reducir tanto el tiempo de inicio como el tiempo de implementación. Sin embargo, las capas de
Lambda no son un buen sustituto de los administradores de paquetes de propósito general como
npm o Maven, y no deberías usarlas como la forma principal de compartir código entre proyectos, porque para empezar, hay muchos más pasos para hacer que funcione. Con algo como
npm, publicar un nuevo paquete y almacenarlo es muy sencillo, y hay soporte para escanear tus dependencias en busca de vulnerabilidades conocidas, mientras que publicar una nueva versión de una capa de
Lambda y luego incorporar esa nueva versión en un proyecto requiere mucho más trabajo, y no tienes versionado semántico ni otras herramientas que obtienes con
npm también. Mi forma preferida de usar las capas de
Lambda es usar este complemento con el marco del servidor, que empaqueta tus dependencias en una capa de
Lambda durante la implementación, la carga en S3 y luego actualiza todas tus funciones para que hagan referencia a esta capa. Y lo genial de este complemento es que detecta cuando tus dependencias han cambiado. Por lo tanto, si no han cambiado en una implementación posterior, no es necesario publicar una nueva versión de la capa, y tu implementación es mucho más rápida como resultado.
Y el truco para reducir el tiempo de inicio es no hacer referencia al SDK completo de
AWS. Entonces, si solo necesitas usar un cliente, esto también ayuda a reducir el tiempo que llevará al tiempo de ejecución de nodo inicializar el módulo de tu función, y por lo tanto, hace que tu tiempo de inicio sea más rápido. Y si estás utilizando
Lambda para procesar el evento de forma asíncrona, como con SNS, S3 o EventBridge, entonces también necesitas configurar algún tipo de DLQ o DeltaQ para capturar cualquier evento de invocación fallida para que no se pierdan. Hoy en día, se deben utilizar los destinos de
Lambda en lugar de los DeltaQ, porque los DeltaQ solo capturan una carga de invocación y no el error. Por lo tanto, debes volver a tus registros o lo que sea para averiguar por qué fallaste en primer lugar para poder decidir si el evento se puede reprocesar ahora o no. Pero con los destinos de
Lambda, se captura tanto la carga de invocación como el contexto alrededor de la invocación y la respuesta, que en caso de un fallo, captura el error del último intento. Por lo tanto, no tienes que buscarlos tú mismo.
Y eso concluye mi presentación. Como mencioné antes, paso la mayor parte de mi tiempo como consultor independiente, y si queremos hablar y ver cómo Serverless puede ayudarte y cómo podríamos trabajar juntos, ve a theburninmonk.com para ver cómo podríamos trabajar juntos para ayudarte a tener éxito con Serverless. Y si quieres aprender algunos de los consejos y trucos que he aprendido a lo largo del tiempo, también estoy impartiendo una masterclass en marzo, y puedes obtener un 15% de descuento con el código yenprs15. Y con eso, muchas gracias a todos por su atención. Y si tienen alguna pregunta, no duden en hacérmela saber, y podemos discutirla ahora. ¡Oh, wow, el 27% de nuestra audiencia ha estado utilizando Terraform como su marco de implementación, y en segundo lugar, tenemos un 23% para Serverless, un 18% para CloudFormation, un 14% para CDK, otro 40% para algo más y un 5% para SA. ¿Qué opinas de esto, Jan-Rust?