The Doppler Quarterly (FRANÇAIS) Printemps 2017 | Page 42

1. Sécurité Les mêmes meilleures pratiques que celles que vous devriez appliquer à vos déploie- ments basés sur un serveur s'appliquent aux fonctions sans serveur. Quelques idées à prendre en considération : • La gestion des identités reste une première ligne de défense. • Un modèle intéressant est apparu : le wrapper de fonctions. Il transmet la saisie de l'événement de déclencheur à un analyseur de sécurité (par exem- ple, Alert Logic) et ne lance la fonction principale que lorsqu'un résultat sat- isfaisant est renvoyé. • Utilisation des passerelles API en tant que front-end protecteur de vos terminaux. 2. Surveillance Ce point a été décrit comme une composante délicate de l'équation sans serveur, mais, par exemple, AWS utilise Amazon CloudWatch comme mécanisme de facto pour surveiller vos fonctions AWS Lambda, ce qui en fait un ajout homogène pour compléter votre surveillance AWS standard. 3. Latence La latence est un autre problème à considérer dans le cadre de l'informatique sans serveur. Notez que Java peut être lent à démarrer s'il n'est pas sollicité fréquem- ment en raison du démarrage de la machine virtuelle Java. Ce n'est pas le cas avec JavaScript ou Python. 4. Versions de langages Selon le langage choisi pour vos fonctions sans serveur, vous pouvez rencontrer des problèmes avec la version prise en charge par le service. Par exemple, AWS Lambda supporte actuellement Node. js v4.3.2 alors que la version recommandée est v6.10.0. Par ailleurs, AWS Beanstalk prend en charge la version v6.9.1. De fait, même le maintien de la cohérence entre les services au sein d'un prestataire de cloud donné est