En muchos casos, separar la funcionalidad en diferentes funciones puede proporcionar un mejor rendimiento y también hacer que una aplicación sea más fácil de mantener y sea escalable. Sin embargo, los “monolitos” de Lambda pueden ser un trampolín útil para migrar una aplicación existente.
¿Cuánta funcionalidad debe contener una sola función de Lambda?
La función debe realizar una sola tarea en el flujo de datos entre los servicios de AWS de su microservicio. Sin embargo, si la tarea funcional es demasiado pequeña, esto puede provocar una latencia adicional en la aplicación y una sobrecarga a la hora de administrar un gran número de funciones. El alcance exacto de una función viene determinado por el caso de uso.
¿Pueden las aplicaciones basadas en Lambda funcionar en varias regiones?
Sí, muchos servicios sin servidor proporcionan replicación y compatibilidad con varias regiones, incluidas DynamoDB y Amazon S3. Las funciones de Lambda se pueden implementar en varias regiones como parte de una canalización de implementación y API Gateway se puede configurar para que sea compatible con esta configuración. Consulte este ejemplo de arquitectura
¿Se pueden ejecutar las funciones de Lambda en un horario programado?
Sí, puede usar expresiones programadas para que las reglas de EventBridge activen una función de Lambda. Este formato usa la sintaxis cron y se puede configurar con una granularidad de un minuto. Vea este tutorial para encontrar un ejemplo.
¿Cómo puede una función de Lambda retener el estado entre las invocaciones?
En muchos casos, una tabla de DynamoDB es una forma ideal de retenerlo, ya que proporciona acceso a los datos de baja latencia y se puede escalar con el servicio Lambda. También puede almacenar datos en Amazon EFS para Lambda
¿Qué tipos de cargas de trabajo son adecuados para las arquitecturas basadas en eventos?
Las arquitecturas basadas en eventos se comunican entre diferentes sistemas mediante redes, que introducen una latencia variable. Para las cargas de trabajo que requieren una latencia muy baja, como los sistemas de negociación en tiempo real, este diseño puede no ser la mejor opción. Sin embargo, para cargas de trabajo altamente escalables y disponibles, o aquellas con patrones de tráfico impredecibles, las arquitecturas basadas en eventos pueden proporcionar una forma eficaz de satisfacer estas demandas.
¿Por qué el servicio de Lambda tiene un límite de 15 minutos para las funciones?
Las funciones de Lambda existen para procesar eventos y la mayoría de los eventos se procesan muy rápido (normalmente, menos de 1 segundo para la mayoría de las invocaciones de producción). La duración de una función viene determinada por el tiempo que se tarda en procesar un evento. Si bien hay algunas cargas de trabajo que requieren un uso intensivo de recursos informáticos y que pueden tardar varios minutos en completarse, muy pocas requieren 15 minutos.
Si considera que necesita una duración mayor, asegúrese de que el código de función procese eventos individuales, realice tareas únicas y utilice las prácticas recomendadas descritas en este documento. En muchos casos, las funciones se pueden rediseñar para procesar eventos individuales y reducir el tiempo necesario para procesarlos.
¿Por qué una función con simultaneidad reservada que no escala para adaptarse al tráfico entrante?
La simultaneidad reservada para una función de Lambda también actúa como un valor de capacidad máxima. Aumentar el límite de la simultaneidad total no afecta este comportamiento. Si necesita una función con simultaneidad reservada para procesar más tráfico, puede actualizar el valor de simultaneidad reservada, lo que aumenta el rendimiento máximo de la función.
¿Por qué una función con simultaneidad aprovisionada todavía experimenta arranques en frío?
Puede medir los arranques en frío a medida que Lambda escale verticalmente y que agregue la monitorización de X-Ray a su función. Una función que utiliza la simultaneidad aprovisionada no presenta un comportamiento de arranque en frío, ya que el entorno de ejecución se prepara antes de la invocación. Sin embargo, la simultaneidad aprovisionada se debe aplicar a una versión o alias específicos de una función, no a la versión $LATEST. En los casos en los que aún se produzca un comportamiento de arranque en frío, asegúrese de invocar la versión del alias con la simultaneidad aprovisionada configurada.
¿Cuál es el mejor tiempo de ejecución para mi función de Lambda?
Lambda es independiente del tiempo de ejecución que elija. Para funciones sencillas, los lenguajes interpretados como Python y Node.js ofrecen el rendimiento más rápido. Para las funciones con cálculos más complejos, los lenguajes compilados como Java suelen ser más lentos a la hora de inicializarse, pero se ejecutan rápidamente en el controlador de Lambda. La elección del tiempo de ejecución también depende de las preferencias del desarrollador y de su familiaridad con el lenguaje.
¿Cómo me aseguro que la versión del SDK no cambie?
Los SDK incrustados pueden cambiar sin previo aviso a medida que AWS publique nuevos servicios y características. Puede bloquear una versión del SDK al crear una capa de Lambda con la versión específica necesaria. Entonces, la función siempre usa la versión de la capa, incluso si la versión que se incrusta en el servicio cambia.
¿Cómo puedo probar que una aplicación basada en Lambda puede escalar para cumplir con el tráfico esperado?
Para garantizar que su aplicación escale según lo esperado, utilice las pruebas de carga en su proceso de desarrollo para simular el nivel de tráfico esperado.
¿Qué cargas de trabajo son adecuadas para la simultaneidad aprovisionada?
La simultaneidad aprovisionada está diseñada para que las funciones estén disponibles con tiempos de respuesta de milisegundos de dos dígitos. Por lo general, las cargas de trabajo interactivas son las que más se benefician de esta característica. Se trata de aplicaciones en las que los usuarios inician solicitudes, como las aplicaciones web y móviles y son las más sensibles a la latencia. Las cargas de trabajo asíncronas, como las canalizaciones de procesamiento de datos, suelen ser menos sensibles a la latencia y, por lo tanto, no suelen necesitar la simultaneidad aprovisionada.
¿Por qué una función de Lambda no registra ningún resultado?
Si una función de Lambda no se registra en CloudWatch, primero asegúrese de que la persona que llama esté invocando la función. Compruebe los registros del servicio de llamadas y cualquier métrica de CloudWatch que indique que un evento ha activado la función. A continuación, compruebe la función en los Registros de CloudWatch. Todas las funciones de Lambda registran tres líneas, incluso si no hay ningún otro registro explícito en el código personalizado de la función:
Si no aparece ningún registro en CloudWatch a pesar de haber invocado la función, compruebe los permisos de la función. El rol de IAM debe incluir permisos de registro. De lo contrario, la función no podrá escribir registros en el servicio. Puede asociar la política AWSLambdaBasicExecutionRole al rol de ejecución de la función para conceder estos permisos.
