Les 14 et 15 février 2017 Paris a accueilli pour la première fois en France la ServerlessConf, conférence communautaire dédiée aux architectures serverless. Après une journée de workshops, la seconde journée de la ServerlessConf a réuni des speakers de Google, Expedia, AWS, IBM et des professionnels de l’IT du monde entier venus partager leur expérience concrète sur des projets Serverless. Voici un compte-rendu, non exhaustif, de quelques-uns des sujets de cette journée.

The present and future of Serverless observability, par Yan Cui

Le premier talk est dédié aux principes de l’observabilité et du serverless. Commençons par une description de l’observabilité. Qu’est-ce que l’observabilité ? En quoi est-ce différent du monitoring ? Pour Yan Cui, ce principe permet bien sûr de récupérer des données en cas d’erreur, mais aussi d’avoir un état de santé complet du service en temps réel.

Mais récupérer ces données requiert l’accès à l’OS, au serveur et d’autres composants. Sans accès au serveur, comment récupérer les informations du serveur, installer des agents, ou exécuter des processus et tracer les logs et invocations lors d’appel de fonctions ? Yan a proposé quelques outils répondant à ces questions et permettant d’avoir du monitoring et/ou de l’observabilité, chacun ayant leurs avantages et défauts. Et ensuite ? Et si le futur de l’observabilité était de penser le service comme un système vivant, comme un organe? Et d’observer le système comme un IRM analyse un cerveau, le tout illustré d’un exemple du projet conçu par Netflix, vizceral. Pour terminer, Yan a évoqué plusieurs projets ayant l’ambition de répondre à ces besoins en proposant des solutions innovantes :

• Thundra
• Epsagon
• Iopipe

Accelerating DevOps with Serverless par Michael H. Oshita

Michael Oshita a présenté durant 15min un de ses projets permettant de créer des environnements de déploiement test pour chaque branche d’un projet GIT. L’utilisation de scripts serverless relié à d’autres services Amazon et Github permet la création d’un environnement pour de tester son application lors de la création d’une branche sur GIT.

Les environnements sont créés sur le Elastic Container Service. Des Lambda vont recevoir des événements lors de la création d’une nouvelle branche sur le dépôt GIT et créer l’environnement associé. Une fois la branche détruite, l’environnement est également détruit.

End-to-end Serverless par Randall Hunt

Randall, dans un spectaculaire show, a proposé une démonstration en direct de Lambda sur Amazon Web Services et de son intégration avec les autres services AWS. En quelques minutes, Randall a créé une Lambda régissant à des événements. Dans cet exemple, une photo envoyée sur un bucket S3 fait réagir différents services AWS. La plupart sont compatibles et les possibilités sont multiples: modification, analyse de l’image, machine learning …
Il est ainsi possible de modifier une photo pour reconnaître et/ou remplacer des visages, analyser une photo afin de déterminer où elle a été prise, etc.

Quelques exemples de bot créés par Randall hunt sur Twitter : @AWSCloudNinja (Cloud Ninja est un bot Twitter qui modifie automatiquement les photos qu’on lui envoie en ajoutant un masque de ninja sur les visages, comme testé ci-dessous) et @WhereML

With Great Scalability Comes Great Responsibility par Dana Engebretson

Dana Engebretson nous a raconté l’aventure de la construction d’un data-pipeline, et les différentes étapes d’architecture par lesquelles elle est passée afin de parvenir à un data-pipeline répondant au mieux à ses besoins.
Tout commence avec le besoin de traiter des données via une application python sur une instance EC2. Plusieurs méthodes ont été utilisées : lancement en continu, par intermittence ou utilisation de spot-instances. Le prix diminue progressivement, mais il y a toujours des problématiques de récupération de jobs, de maintenance ou de scaling, et Dana voit encore des possibilités d’améliorations.

Elle se tourne alors vers une solution Serverless s’appuyant sur AWS Lambda. Mais ce n’est pas si simple. Lambda, bien que très puissant, possède aussi ses limitations : le temps d’exécution est limité, il faut prendre en compte le poids du code et de ses dépendances, etc.

L’idéal est donc d’orchestrer les Lambdas, et Dana nous explique les différentes architectures essayées afin d’obtenir le meilleur résultat. L’imbrication de lambda semblait une bonne idée, mais ce genre d’imbrication n’est pas encore possible avec ce service. Dana a alors envisagé une solution utilisant un bucket S3 et un déclenchement d’événements lors du dépôt de fichier sur ce bucket. Et ça fonctionne, de façon très rapide…. trop rapide ! Il n’est pas possible de temporiser la vitesse d’invocation des lambdas, on atteint donc facilement la limite d’exécution simultané.

L’utilisation de queues SQS et de règles CloudWatch (similaire à crontab) pourrait résoudre le problème. Chaque Lambda peut être exécutée à intervalle donné. Cette solution résout les inconvénients des autres solutions mais en crée de nouveaux. L’un des inconvénients est l’intervalle d’exécution des lambdas qui ne peut être au minimum que toutes les minutes.

En conclusion, Dana attend plusieurs évolutions sur le service Lambda, notamment en cas de traitement parallèle et d’utilisation du service SQS.

Conclusion

Ma journée à la ServerlessConf Paris a été riche en apprentissage. Les sujets de conférences étaient diversifiés avec des présentations théoriques sur l’architecture, des scénarios de tests et de l’observabilité ainsi que des présentations plus pratiques sur différents outils et des démonstrations sur différentes solutions Cloud (AWS, GCP, Azure, IBM).

Mais la ServerlessConf Paris était aussi l’endroit où rencontrer des contacts et/ou collègues que l’on croiserait rarement en dehors de ce genre d’événement international. C’était l’occasion d’échanger avec des personnes ou entreprises évoluant dans le même domaine…. et de compléter sa collection de goodies !