En esta publicación MUY llena de opiniones, compartiré mis pensamientos sobre las extensiones de AWS Lambda, lo bueno y lo malo, y cuándo debería usarlas o no.
Tabla de contenido
Introducción a las extensiones Lambda
Las extensiones Lambda son un mecanismo interesante. AWS recomienda usarlas para mejorar sus funciones con capacidades de caja negra desarrolladas por AWS o proveedores externos.
Utilice extensiones Lambda para integrar funciones con sus herramientas preferidas de monitoreo, observabilidad, seguridad y gobernanza - AWS
Puedes pensar en ellos como cajas negras que puedes conectar a tu Lambda, que funciona como una capa Lambda y disfrutar de nuevas funciones.
Aquí hay una lista de usos clásicos que me vienen a la mente:
Obtenga la configuración, los secretos y los parámetros y almacénelos en la memoria caché. Recupérelos automáticamente una vez cada varios minutos. Piense en obtener secretos desde el Administrador de secretos o el Almacén de parámetros.
Envíe registros, seguimientos y métricas a un proveedor de observabilidad externo como Lumigo, DataDog y otros.
Supervise la CPU, la memoria, el uso del disco y otros parámetros interesantes de la máquina de la función Lambda y envíelos a un sistema de monitoreo, como la extensión Lambda Insights .
Puede encontrar más casos de uso de extensiones en este repositorio . Algunos están respaldados por AWS y otros son de terceros.
Para utilizar una extensión Lambda, solo tienes que adjuntarla como capa Lambda. Consulta mi publicación para obtener más información sobre las capas Lambda y cuándo usarlas. Me parecen especialmente útiles para la optimización de la implementación.
El caso de las extensiones Lambda
En el papel, las extensiones suenan como un mecanismo fantástico: agregas una capa Lambda y algunas variables de entorno y, listo, ya estás integrado con un proveedor externo de observabilidad y obtienes una nueva funcionalidad que no desarrollaste.
Y se pone aún mejor: los desarrolladores de extensiones pueden desarrollar extensiones en Rust, un lenguaje compilado que ofrece un rendimiento increíblemente rápido, un inicio en frío menor, es independiente del entorno y puede ejecutarse en funciones Lambda que usan un tiempo de ejecución diferente.
La ventaja de un ejecutable es que se compila en código nativo y está listo para ejecutarse. La extensión es independiente del entorno, por lo que puede ejecutarse junto con una función Lambda escrita en otro entorno de ejecución. - Optimización de extensiones de AWS Lambda en C# y Rust
Sin embargo, las extensiones Lambda a menudo tienen un coste que supera estas ventajas.
Repasemos mis razones y los casos de uso para los que actualmente uso extensiones.
El caso contra las extensiones Lambda
Las extensiones Lambda son una herramienta poderosa que hereda la mayoría de sus problemas del mecanismo sobre el que se construyen: las capas Lambda . Repasemos los casos en contra de las extensiones Lambda.
Podemos dividir los casos en varias categorías:
Seguridad
Experiencia de desarrollador
Rendimiento y costo
Seguridad
Las extensiones son similares a cualquier biblioteca SDK de código abierto. Sin embargo, hay una particularidad adicional.
Las extensiones pueden exponerlo a un riesgo de seguridad ya que nunca está seguro de lo que está incluido en la capa (algunos proveedores de extensiones documentan y hacen un buen trabajo, pero muchos no lo hacen).
Además, según la documentación de AWS:
Las extensiones tienen acceso a los mismos recursos que las funciones, ya que se ejecutan dentro del mismo entorno que la función ( documentación de AWS)
Si utiliza una versión comprometida de una extensión (piense en los piratas informáticos que obtienen acceso y publican su versión de la capa en la cuenta oficial de AWS del editor de la capa), pueden acceder a cualquier recurso que tenga su función en su proceso de ejecución de caja negra. Hasta ahora, esto es bastante similar a un SDK de código abierto comprometido.
Pero hay un giro en la trama.
Las canalizaciones CI/CD seguras incluyen un escáner de vulnerabilidades, como Synk , que escanea sus archivos de dependencias de Python ( poesía.to ml), verifica si hay alguna versión comprometida y hace que su canalización falle antes de que una versión comprometida se implemente en producción.
No sucede lo mismo con las capas y extensiones de Lambda. Su código se agrega a Lambda durante la invocación, donde herramientas como Amazon Inspector pueden escanear las capas, el código y las dependencias de Lambda y encontrar código comprometido.
Sin embargo, ya es demasiado tarde. La extensión comprometida ya se está ejecutando en producción.
Por lo tanto, existe un riesgo de seguridad añadido.
Experiencia del desarrollador
Configurar un entorno de desarrollo local con extensiones es difícil. Debes averiguar qué dependencias externas trae la capa de extensión e instalarlas localmente para probar tu código y depurarlo en el IDE. Esto puede resultar complicado, especialmente en casos en los que hay conflictos de versiones. Una discrepancia entre el entorno de desarrollo local y el entorno de funciones Lambda puede provocar fallas y errores que solo ocurren en producción y no en entornos locales.
Además, algunas extensiones de Lambda requieren que el código de su función Lambda interactúe con ellas (probablemente a través de llamadas de red del host local ), lo que hace que sea casi imposible probar su código en el IDE. Si no tiene idea de lo que estoy hablando, consulte mi sesión de AWS re:invent 2023 y mi serie de pruebas de Lambda , donde muestro cómo puede probar localmente sus funciones. Las extensiones rompen esta experiencia.
Otra experiencia crítica para el desarrollador está relacionada con el mantenimiento y las actualizaciones.
Las extensiones Lambda se habilitan a través de capas Lambda.
Las capas lambda tienen problemas inherentes:
Control de versiones: las capas tienen versiones y su función siempre consume una versión específica que cambia entre regiones, lo que complica aún más su trabajo (en una región, es la versión 55, en otra, la 43). La versión es parte del ARN de la capa.
Actualizaciones: debes estar al tanto de las nuevas versiones (de alguna manera) y cambiarlas manualmente a la última versión. Las capas Lambda no tienen un administrador de paquetes como Python y otros lenguajes, por lo que las actualizaciones se convierten en una tarea manual.
El tamaño total descomprimido de la función y todas las capas no puede superar la cuota de tamaño de paquete de implementación descomprimido de 250 MB. Su extensión ocupa una parte de esta cuota.
Rendimiento y costo
No hay comidas gratis. Las extensiones comparten recursos de funciones, como CPU, memoria y almacenamiento, y es posible que veas una mayor duración de la función facturada.
Además, cada extensión debe completar su inicialización antes de que Lambda invoque la función. Por lo tanto, una extensión que consume un tiempo de inicialización significativo puede aumentar la duración del arranque en frío de la función. Puede que valga la pena para ti, pero es un hecho que debes tener en cuenta.
Cuándo utilizar extensiones Lambda
Cubramos varios casos de uso para ver si se ajustan a las extensiones Lambda o no.
Obtener configuración
Recientemente leí un blog que demostraba que una extensión puede obtener la configuración más rápido que la función Lambda de Node que la usa. Probablemente eso se deba a que la extensión está escrita en Rust, que es más rápido que Node. Sin embargo, una vez que se obtiene el secreto, se almacena en un caché durante varios minutos. Powertools for AWS , una increíble biblioteca de código abierto, proporciona las mismas funciones sin una extensión. Una extensión le ahorra unas pocas docenas de milisegundos en la primera llamada (y para la primera llamada cada vez que caduca el caché), pero es lo mismo una vez que el caché no está vacío. A menos que obtenga un volumen ridículamente alto de secretos en la función, probablemente no valga la pena agregar la complejidad y los problemas mencionados anteriormente para ahorrar una docena de milisegundos cada pocos minutos.
TL;DR — no uses una extensión.
Enviar registros a un proveedor de observabilidad de terceros
Este es uno de los casos de uso más comunes para el uso de la extensión Lambda. Funciona, funciona bien y probablemente no necesite que su código interactúe con ella directamente en el IDE. Parece adecuado para la mayoría de las empresas.
Sin embargo, como venimos de una empresa de seguridad, elegimos una ruta diferente. Escribí una publicación en el blog sobre por qué es mejor usar un servicio centralizado para enviar todos los registros de su cuenta de AWS a un proveedor de observabilidad de terceros en lugar de que todas las funciones de Lambda los envíen individualmente. Es simple cuando tiene pocos servicios, pero se vuelve complicado a gran escala, especialmente cuando desea tener la misma configuración y gobernanza de filtrado de registros en cientos de servicios. Es mejor escribir los datos en CloudWatch y usar un mecanismo centralizado para enviar sus datos a cualquier proveedor que desee y filtrar los datos que no desea enviar. Es más seguro y funciona mejor, pero paga más (¡pero vale la pena!). Consulte mi publicación aquí para conocer los pros y los contras detallados.
TL;DR: usa una extensión, pero es posible que quieras reconsiderarlo a gran escala.
Monitoreo de métricas de contenedores de Lambda
Este es un gran caso de uso y no encuentro ningún problema con él, salvo que debería venir de fábrica en Lambda. No quiero pensar en ello ni adjuntar extensiones. Quiero habilitarlo a través de la configuración de IaC y ver las estadísticas en CloudWatch.
TL;DR — usa una extensión
Ingeniería del caos
Otro caso de uso único con extensiones en ingeniería del caos es donde las extensiones Lambda son una herramienta práctica.
Koby Aharon abordó los conceptos de ingeniería del caos sin servidor en sus dos fantásticas publicaciones invitadas en mi sitio web y brindó detalles de implementación. Realizó su experimento de caos utilizando una extensión Lambda. Puede revisar su publicación de introducción aquí y los detalles de su experimento aquí .
"Instaló" la extensión al comienzo del experimento, dejando su código de implementación y código de función limpios de extensiones y capas, y lo eliminó una vez que terminó el experimento. Es súper limpio y lo hace solo durante un experimento de caos, que se realiza en una cuenta separada, por lo que no afecta la producción. En este ejemplo, el mantenimiento es un problema menor y los desarrolladores no necesitan estar al tanto de él durante el desarrollo. Cero desventajas y obtienes todas las ventajas de la extensión.
TL;DR — usa una extensión
No he cubierto todas las extensiones del mundo, pero estos ejemplos cubren un gran porcentaje de los casos de uso más extendidos.
Resumen
En esta publicación, he revisado varios casos de uso comunes de extensiones Lambda.
He enumerado los pros y contras de las extensiones lambda y he sugerido los casos de uso más adecuados.
En resumen, si su código interactúa activamente con la extensión, está haciendo algo mal y debe reemplazar la extensión con el código de función Lambda normal o, en la mayoría de los casos, con una biblioteca de código abierto que haga el mismo trabajo, a veces incluso con más funciones.
El hecho de que puedas hacerlo con una extensión no significa que debas hacerlo .
La observabilidad y la ingeniería del caos, por otro lado, son buenos ejemplos del uso adecuado de las extensiones.