....Développer de meilleures applications sans serveur dans AWS..Building Better Serverless Applications on AWS....

 

....

Développer de meilleures applications sans serveur dans AWS..

Building Better Serverless Applications on AWS....

....

Il y a quelques années, exécuter un code évolutif sans avoir à gérer l'architecture aurait relevé de la science-fiction. Maintenant que les technologies sans serveur gagnent en maturité, l’enjeu devient le suivant : comment développer mes applications pour exploiter pleinement les technologies sans serveur? Dans le cadre de la conférence re:Invent, j’ai eu l’occasion d’assister à la présentation intitulée Optimizing Serverless Applications de Chris Munns (chrismunns) et je tenais à souligner quelques points sur lesquels les utilisateurs devraient se concentrer lorsqu’ils créent des applications sans serveur. Cet article comporte deux volets : l’optimisation des fonctions et la configuration de l’environnement.

En ce qui concerne les fonctions Lambda elles-mêmes, il existe certains moyens d’améliorer les performances d’une fonction et d’en réduire les coûts d’exécution. Lambda étant lié, la plupart du temps, au processeur et à la mémoire, ces améliorations ont pour but de diminuer la contribution de l’un ou de l’autre. Pour réduire le temps consacré à l'exécution d'un lambda, il est essentiel de minimiser le nombre de liens d'une fonction, mais surtout, de réduire la quantité de code exécuté à chaque exécution de la fonction. On met souvent à tort tout le code dans la fonction de gestionnaire, obligeant ainsi la fonction à lancer le code d'initialisation à chaque fois. Voici un exemple de code avec initialisation :

..

Not having to manage architecture while running scalable code would have sounded like science fiction a few years ago. Now that serverless technologies are maturing, the dialog becomes how should I build my applications to fully utilize serverless technologies. I had the chance to attend Chris Munns’s (chrismunns) “Optimizing Serverless Application” at Re:Invent and wanted to highlight a few points people should focus when building serverless applications. I’m going to split this article in two parts, function optimizations and environment configuration.

Regarding the Lambda functions themselves, there are a few areas that can be used to improve a function’s performance and lower the running cost. Since Lambda are most of the time bound by CPU and memory, the goals of these improvements is to lower one or the other. To lower the amount of time a lambda runs, it is important to minimize the number of dependencies a function has but most importantly, it is important to minimize the amount of code that is ran each time the function executes. A common mistake is to put all the code in the handler function which causes the function to have to run the initialization code each time the code is called. Here is an example of code with an initialization: ....

 
 
import relevant.library;
initializeSecretsAndProperties(); initializeDataConnection();
exports.myHandler = function(event, context, callback) { saveDataCall(event); callback(null, result);  }
function saveDataCall(event) { //do the work here }
 
 

....

Une autre erreur fréquente consiste à utiliser la fonction pour orchestrer les appels. Il vaut mieux qu’une fonction ne serve qu’un seul but, et envoie ensuite le message à une autre fonction via SNS, SQS ou Kinesis. Cela réduit le temps d’exécution de la fonction et permet de limiter chaque fonction à une seule responsabilité.

L’autre façon d’optimiser les performances d’une fonction consiste, au départ, à vérifier qu’elle est bien configurée. Restreindre le temps consacré par la mémoire à l’exécution d’une fonction ne garantit pas que cette dernière sera exécutée à moindre coût, car le temps d’exécution de la fonction pourrait augmenter considérablement s’il dépend de la mémoire. Un autre élément à considérer dans la configuration d’une fonction est que son utilisation de 1,8 Go de mémoire activera 2 cœurs plutôt qu’un. Et puisque la plupart des fonctions sont conçues pour s’exécuter en tant que thread unique, il se peut qu’une augmentation de la mémoire au-delà de 1,8 Go ne permette pas d’améliorer la performance comme prévu.

Le dernier aspect à considérer est l’exécution de votre Lambda à partir de votre propre VPC. Contrairement à une idée préconçue, exécuter les Lambda dans votre propre VPC ne comporte aucun avantage en termes de sécurité (sauf celui évoqué spécifiquement ci-dessous), car, s’ils n’ont pas été configurés pour s’exécuter dans un VPC spécifique, ils continueront de s’exécuter dans le même environnement. L’exécution d’un Lambda dans un VPC spécifique a comme inconvénient que vous devez gérer la configuration réseau des fonctions. Vous ne devriez exécuter une fonction dans votre propre VPC que lorsque vous devez accéder à une ressource spécifique de ce VPC. Un excellent graphique sur le site d’AWS explique cette décision. En revanche, il pourrait être avantageux, sur le plan de la sécurité, d’exécuter la fonction dans un VPC, mais dans un sous-réseau non connecté à Internet, restreignant ainsi l’accès de la fonction aux seules ressources du VPC.

..

Another common mistake is to use the function to orchestrate the calls. It is better for a function to serve a single purpose and then send the message to another function either through SNS, SQS or Kinesis. This reduces the time to execute the function and it helps keeping a single responsibility for each function.

The other main area of optimization is to ensure that the functions are well configured. Limiting the memory to a minimum doesn’t ensure that the function will run with the cheapest cost as the time to execute the function might increase exponentially if it is memory bound. Another consideration for the configuration of a function is that any function configured with over 1.8GB of memory will enable 2 cores instead of one. Since most functions are meant to run as a single thread, it is possible that increasing the memory over 1.8GB will not improve performance as expected.

The last subject to consider is if you should run your Lambda’s in your own VPC. Contrary to popular belief, there are no security benefits (except a specific one described below). to run the Lambdas in your own VPC since they will still execute in the same environment that they do if they are not configured to run in a specific VPC. Running it in a specific VPC has the disadvantage that you have to manage the network configuration for the functions. You should only run a function in your own VPC if you need to access specific resource in this VPC. A good chart from AWS describes this decision. A security benefit of running the function in a VPC would be to run the function in a subnet that it cannot access the Internet, thus restricting the function access to only VPC resources. ....

 
 
 
 

....

Ce diagramme est tiré d’un excellent article sur le site Internet d’AWS qui fournit plus de détails.

En espérant qu’avec cela vous pourrez maintenant mieux optimiser vos fonctions Lambda !

..

This flow chart comes from a good article on the AWS website that provides more detail.

Hopefully that gave you a good start to start optimizing your Lambda functions!

....



 
FR
EN