Second article de notre série revenant sur les annonces nous ayant marqué lors de la récente AWS re:Invent, nous vous présentons aujourd’hui les nouveautés annoncées du côté d’AWS Lambda, qui est à l’honneur avec de nombreuses améliorations. Si vous aviez encore des doutes sur la maturité du service, ces annonces devraient être en mesure de les balayer !

Pour rappel, les autres articles de cette série de décembre sont :

1. Vendredi 8 décembre : Orchestration de conteneurs
2. Lundi 11 décembre : Une flopée d’annonces pour Lambda (vous êtes ici)
3. Jeudi 14 décembre : Stockage de données
4. Lundi 18 décembre : Service mobile, EC2 et Active MQ
5. Jeudi 21 décembre : Réalité virtuelle & augmentée et Machine Learning

Pondération du trafic entre versions de Lambda

Jusqu’à présent un alias ne pouvait pointer que sur une seule version de Lambda. Cela signifiait que lors d’un déploiement l’intégralité du trafic était aiguillé vers la nouvelle version. À présent, un alias peut pointer simultanément vers deux versions ayant chacune un poids défini (principe de Canary Testing)

Les contraintes :

• Les deux versions doivent avoir la même DLQ ou la même absence de DLQ
• Les deux versions doivent avoir le même rôle IAM
• L’alias ne doit pas pointer vers $LATEST. 
  
  

Limitation du nombre d’exécutions concurrentes

Ce nouveau paramètre cape le nombre d’exécutions simultanées d’une même fonction Lambda. C’est notamment utile lorsque le backend appelé par la Lambda ne possède pas des capacités de mise à l’échelle poussées (une base de données par exemple). De plus, dans le cas où la Lambda est intégrée à un VPC, cela permet également de contrôler la création d’Elastic Network Interface (ENI).

Une nouvelle métrique Cloudwatch “ConcurrentExecutions” est également disponible.

En invoquant la Lambda avec le mode “RequestResponse” l’erreur est la suivante :

An error occurred (TooManyRequestsException) when calling the Invoke operation (reached max retries: 4): Rate Exceeded

Augmentation de la mémoire maximum des Lambda

Auparavant limitée à 1536MB, la nouvelle taille maximale de mémoire est de 3008MB. Cela ouvre la voie à des charges de travail plus consommatrices en mémoire et en CPU. Pour rappel, les ressources CPU sont proportionnelles à la taille mémoire. 

Intégration de Cloudtrail pour l’exécution des Lambda

Jusqu’à présent, seules les actions de configuration des Lambdas étaient historisées dans Cloudtrail (ajout, modification, suppression). À l’instar des “data event” de S3, ClouldTrail permet désormais de logguer les appels de fonctions Lambda. Il est ainsi possible de connaître les Lambdas exécutées durant les derniers jours ainsi que la source des invocations pour prendre des actions restrictives si nécessaire.

Mise à disposition des Serverless Application Repository (preview)

AWS fournit le Serverless Application Repository, une collection d’applications serverless publiées par des développeurs, des sociétés et des partenaires AWS.

Les packages à disposition vont plus loin que les blueprint des Lambdas car ils se basent sur Serverless Application Modèle (SAM). Au menu : des lambdas, des tables DynamoDB, de l’API Gateway !

Le Serverless Application Repository permet de rechercher, de configurer et de déployer des stacks serverless prêtes à l’emploi.

Le tour d’horizon de Lambda n’aurait pas été complet sans parler du support de Go :

Toutes les annonces liées au service Lambda sont disponibles dans ces liens : concurrence, mémoire, Serverless Application Repository, pondération du trafic, CloudTrail.