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