Le 27 avril dernier a eu lieu le premier TIAD Camp. Avec ce nouveau format, l’objectif est de réunir la communauté plus régulièrement et d’approfondir des sujets techniques au travers de keynotes ciblées, de bootcamps et d’ateliers au format novateur. Pour ce premier rendez-vous c’est le sujet du Serverless qui a été choisi : comment sommes-nous arrivés au Serverless ? Quel est l’état des lieux du marché ? Quels sont les challenges opérationnels rencontrés en production ? Pour répondre à ces questions, nous avons réuni des intervenants issus de Ippon Technology, Google, Alsanium, Microsoft, Adways et D2SI.

Pour commencer la journée, Gauthier Wallet est revenu rapidement sur presque deux années d’expérience autour de Lambda chez D2SI. C’est en effet en novembre 2015 qu’AWS a annoncé Lambda et API Gateway, deux services qui ont tout de suite suscité l’adhésion chez D2SI parce qu’ils permettaient de répondre rapidement aux besoins clients. Passé le premier POC, nous avons rapidement mené un premier projet client, toujours en service à ce jour. D’autres projets ont suivi, plus importants, autour des serveurs de données, du big data, de la sécurité : les champs d’application du Serverless sont nombreux.

Clément Hussenot est ensuite rapidement revenu sur le concept de fonction, qui est derrière le Serverless : les fonctions réagissent en réponse à un événement. On parle d’ailleurs maintenant de Function as a Service. Les fonctions peuvent être implémentées dans différents langages, AWS Lambda a par exemple récemment pris en charge le code C# en complément de Java, Node.js et Python. Il faut par ailleurs rappeler que Serverless est un concept, qui non seulement ne se limite pas à AWS (Google, Azure, IBM proposent ou vont proposer des services équivalents), mais qui dépasse également la notion de fonctions. Le concept de Serverless implique de nombreux services managés : à partir du moment où on se lance dans le Serverless, on n’utilise plus les outils classiques les bases de données relationnelles, mais des services managés de haut niveau comme S3, Cloud Storage, etc. Aujourd’hui beaucoup d’offres sont disponibles dans le Cloud, mais le marché est encore jeune et évolue très rapidement.

Les offres autour de Serverless

L’outillage est encore globalement insuffisant, même s’il existe des frameworks comme Apex, Serverless. D’ici un à deux ans, le marché sera très bien outillé pour faire du serverless, mais nous n’y sommes pas encore. De fait, Gauthier Wallet a mis en garde l’assistance contre la facilité supposée des développements en Serverless. En effet, ces nouvelles architectures affranchissent le développeur d’un certain nombre de problèmes, mais tout n’est pas si simple. Il est essentiel de bien prévoir son usage et adapter son architecture pour ne pas avoir de mauvaises surprises de facturation. Développer en Serverless demande également un effort accru de monitoring. Que les Ops se rassurent donc : dans un monde de Serverless, on aura toujours besoin de leurs compétences !

Gauthier Wallet a ensuite souligné la très forte dépendance au provider; par exemple, il faut parfois migrer pour une version supérieure du code suite aux mises à jour du provider. Si on reste sur une ancienne version du code, comme Node.js 0.10, il n’est pas certain que le code sera toujours fonctionnel dans un an. Il est donc important de suivre de près l’actualité du Cloud provider concerné.

Le serverless, pour qui ? C’est évidemment un progrès pour les développeurs qui peuvent maintenant déployer leur code sans intervention extérieure, mais également un aide au quotidien pour les ops. Les cas d’usages sont nombreux, et on pense notamment aux start-ups qui n’ont pas toujours les moyens d’investir dans des ops. Le serverless leur permet également de prototyper et de tester rapidement sans risques financiers : si le service n’est pas sollicité, il n’y a pas de coûts; et dans le cas contraire, la solution est scalable. Cette première keynote s’est conclue sur le fait que s’il y a un potentiel Serverless dans tous les projets, il reste néanmoins indispensable, comme toujours, d’utiliser avant tout l’outil le plus adapté au besoin : ce n’est pas parce que le Serverless est dans la tendance du moment qu’il faut l’inclure dans tous les projets.

Le voyage d’un serveur, de AIX au Zero Ops

Mais qu’est-ce qui pousse les entreprises à suivre le rythme (parfois effréné) des innovations technologiques ? Pierre Baillet, consultant DevOps et développeur depuis 1987, a commencé son talk par une mise en perspective des évolutions sociales de l’IT (la généralisation de son enseignement, les nouveaux moyens d’apprentissage, l’apparition de nouveaux métiers comme les Ops et les DevOps…), des évolutions techniques (langages et frameworks), et des évolutions du marché (mondialisation et digitalisation). Les entreprises innovent pour assurer leur survie, vendre et continuer à gagner de l’argent : si le business est le moteur, c’est maintenant la technologie qui permet de réduire le TCO (coût des opérations), de disrupter, de créer de nouveaux usages, voire d’ouvrir de nouveaux marchés.

Le voyage d’un serveur donc, c’est celui qui nous a vu passer de l’ère du « owned » (ce que je possède) au « provided » (ce qui est fourni) : l’infrastructure physique, le « metal » (datacenter, serveurs, switches…), les ops, les dev. Pierre Baillet a ainsi retracé plus de 40 années d’évolution de l’informatique avec des étapes comme la création de Linux, la sortie de Visual Basic, jusqu’à l’arrivée en 2006 de l’infrastructure as a service, ou le Cloud. C’est le moment de la rupture, celui où l’infrastructure et les serveurs peuvent être fournis à l’entreprise. Dans la foulée, de nouveaux services sont proposés, comme les bases de données relationnelles. En contrepartie, le vendor lock-in devient plus fort. Alors, aujourd’hui le serverless, demain Everything as a Service ? Quoiqu’il en soit, pour Pierre Baillet comme pour les autres intervenants, nous aurons toujours besoin des Ops !

Les challenges opérationnels derrière les infrastructures Serverless

Laurent Bernaille est ensuite intervenu pour partager un retour d’expérience sur des projets serverless volumineux (ce retour d’expérience est consacré à AWS Lambda, étant donné que c’est surtout Lambda qui est en production actuellement). Que se passe-t-il quand on fait tourner du serverless sur de larges infrastructures et avec de forts enjeux ? Le premier point abordé est le monitoring : comment vérifier qu’une plateforme Serverless fonctionne correctement ? Pas de souci de monitoring quand on POC du lambda, mais quand on passe en production il est essentiel de comprendre comment les fonctions se comportent. Or, il n’existe aujourd’hui pas vraiment d’équivalent à des outils comme New Relic ou Datadog. La recommandation officielle d’AWS est donc d’utiliser Cloudwatch. Mais l’outil est-il vraiment adapté à la complexité d’une application utilisant de nombreuses fonctions ? Laurent Bernaille a donné pour exemple (voir ci-dessous) un graphique retraçant le nombre d’invocations/mn et leur durée moyenne. Avec seulement une quinzaine de fonctions, le graphique n’est pas simple à interpréter. Imaginez alors sur des applications plus complexes, avec un plus grand nombre de fonctions.

La seconde partie du graphique concerne la durée d’exécution des Lambdas : c’est un point à surveiller, car il y a des enjeux de performance et de coûts, puisque les Lambdas sont facturées au temps d’exécution. On a donc tout intérêt à ce qu’elles s’exécutent rapidement. Ici on peut donc constater que la plupart des Lambdas s’exécutent vite, entre 200 et 300 ms, alors que d’autres durent 10 secondes.  Est-ce normal ? Une autre Lambda semble évoluer par pics, de plus en plus longs. Dans le cas de cette application, ces comportements ont une explication : les traitements sont complexes, il est donc normal qu’ils prennent du temps. Quand à la lambda qui évolue par pics, elle a plus d’éléments à processer au fil du temps, et donc le comportement est normal. Néanmoins cet exemple pose la problématique du monitoring : comment monitorer des applications complexes avec un grand nombre de fonctions ? Ici on n’a qu’une vue granulaire, qui ne permet pas de savoir comment l’application se comporte globalement.

Autre point à monitorer pour Laurent Bernaille, les erreurs. Si pour certains développeurs, il y a des erreurs « normales » (rires dans l’assemblée), qu’en est-il des erreurs remontées par Cloudwatch ? Pour Laurent Bernaille, ce qui rend compliqué le monitoring des erreurs Lambda est qu’il faut faire face à de nouveaux types d’erreur. Des erreurs liées à l’exécution, comme par exemple une Lambda mal dimensionnée, ou dont la durée d’exécution dépassé 5mn… Il faut également prendre en compte le fait que par défaut, une Lambda en erreur sera relancée deux fois, et donc, dans le lot d’erreurs remontées, toutes ne sont pas des erreurs uniques. Ensuite, on commence à investiguer l’origine des erreurs. Avec un groupe de logs par fonctions dans Cloudwatch, il faut naviguer dans de longues listes de fichiers ce qui peut vite s’avérer très fastidieux. L’outil est donc efficace pour capturer les logs, mais il faut lui ajouter une autre solution pour les analyser; Laurent Bernaille a également recommandé de prendre le temps de configurer Cloudwatch pour mieux exploiter ces données. Enfin pour la question des problèmes de performance, il n’existe aujourd’hui pas d’outil tout prêt. AWS X-Ray pourra répondre à ce besoin de tracing, mais cette fonction n’existe qu’en version preview, depuis le 19 avril dernier. L’éco-système autour de Serverless et Lambda est encore vraiment très jeune.

Les applications basées sur les événements posent de nouveaux challenges. Laurent Bernaille a pris l’exemple d’une fonction réagissant à une réception de fichier dans S3, générant un process puis une réécriture dans S3. Si la réécriture se fait au même endroit, alors la fonction se déclenche à nouveau ! C’est typiquement le genre de problème dont on s’aperçoit en vérifiant le coût de ses Lambdas. Autre cas d’usage fréquemment rencontré, la consommation de flux en provenance d’un moteur d’événement comme Kinesis. Si la Lambda crashe, le message est représenté, et la Lambda est relancée, ainsi de suite à l’infini… Pour éviter d’avoir une Lambda bloquée sur le processing d’un événement, il faut donc prévoir de ne pas représenter le message s’il a fait crasher le code.

Autre challenge à gérer avec les Lambdas : la latence. Une Lambda peut être très rapide dans son exécution, quand le traitement est un ensemble de Lambdas séquencées, on introduit plus de latence à cause du réseau. Il faut prendre également en compte que le temps de facturation minimum d’une Lambda est de 100 ms, et que donc dimensionner des Lambdas en dessous de cette limite n’est pas intéressant. Enfin, il faut noter que la première exécution d’une Lambda est toujours plus longue.

Comprendre les nouveaux services

Comme cela a déjà été souligné, l’un des enjeux du Serverless est de bien comprendre l’ensemble des services qui forment l’éco-système de Lambda. Laurent Bernaille a évoqué notamment les connaissances liées aux Lambdas (comme le démarrage), mais aussi les services qui sont souscrits comme S3 ou DynamoDB. Selon les sources, les événements sont reçus à l’unité (DynamoDB), ou par lots (Kinesis). Il faut prendre en compte également les limites du moteur : jusqu’à il y a peu de temps, la limite était de 100 exécutions simultanées par compte. Cette limite a été augmentée à 1000 exécutions le 4 mai dernier. Par contre, il n’existe aujourd’hui pas de métrique permettant de connaître le nombre d’exécutions concurrentes à un instant donné.

Concernant les services associés, il faut changer ses habitudes : on n’utilise plus une base RDS ou un outil comme RabbitMQ, qui ne sont plus adaptés en termes d’architecture. Pour la base de données, on utilisera plutôt DynamoDB, mais cela demande de faire un véritable effort sur le design des tables pour la faire tourner avec des niveaux de performances et de coûts qui soient acceptables. DynamoDB propose en effet une facturation au nombre d’écritures/lectures par seconde, or ce nombre est lié à l’architecture de l’application et au design de la table. Ce n’est pas parce que le compute ne coûte quasiment rien que c’est la cas de la donnée : Laurent Bernaille a ainsi cité le cas d’une application quasi gratuite sur Lambda, mais avec près de 15 000$ de facture mensuelle en base de données ! Quid de la promesse du Cloud de la scalabilité alors ? Elle est tenable, mais ce n’est pas automatisé. Si on a besoin de plus de performance sur une table Dynamo, il faut le faire soi-même. Ce qui n’est pas toujours simple quand on est en production… on risque toujours un impact sur la performance au moment du changement.

Le Continuous Delivery dans le Serverless

Comment tester les fonctions ? Comment faire tourner une Lambda dans son environnement de CI ? Comme le plus souvent les fonctions utilisent des services AWS, il faut pouvoir faire des tests unitaires en utilisant ces services dans le moteur de CI. Le mocking est possible, mais les outils sont encore jeunes. Comme Laurent Bernaille l’a expliqué, les développeurs doivent aujourd’hui déployer sur AWS pour tester leur code. Et pour tester en local ?  C’est possible avec des images Docker, par exemple pour le service DynamoDB, mais si on vise des outils moins souvent utilisés, c’est plus compliqué. C’est un véritable enjeu, et différentes initiatives sont en cours pour y répondre; Localstack, par exemple, est un outil très récent qui permet de répliquer des services AWS localement. Laurent Bernaille a également abordé le point du versionning de code qui peut être fait avec les outils habituels, mais qui demande des actions manuelles si on veut déployer sur plusieurs environnements.

Pour finir cette keynote, Laurent Bernaille a interrogé l’assistance sur ce qu’est vraiment une application. Est-ce la fonction? Mais quand l’application inclut des centaines de fonctions, alors comment gérer des librairies partagées entre fonctions ? Aujourd’hui il n’y a pas de réponse toute faite à cette question : l’unité de déploiement n’est ni la fonction, ni l’ensemble des fonctions… la réponse est quelque part entre les deux, il faut raisonner par microservice, ou par périmètre applicatif.

En conclusion, Laurent Bernaille a estimé que le Serverless allait transformer les façons de faire dans l’IT, notamment parce que le Serverless permet au code d’être au plus près des enjeux métier. Mais il ne faut pas pour autant croire que tout sera extrêmement simple, que le Serverless fonctionnera sans Ops. Le métier des Ops change, il demande de comprendre les nouvelles architectures et backends, et un effort accru sur la supervision, avec de nouveaux outils pour optimiser les performances et les coûts.

Escape Game, Serverless low cost analytics, Google functions, Azure Functions…

Après le déjeuner, les participants ont été conviés à un Escape Game sur le thème du Serverless, au cours duquel ils ont eu à résoudre de nombreuses énigmes pour déjouer le virus « NoOps ». Deux sessions de bootcamp sur le thème « Bufferize my API » ont également été organisées : sur le sujet, vous pouvez lire l’article sur la construction d’un proxy d’API avec AWS Lambda.

L’après-midi était également riche en keynotes et retours d’expérience, avec :

• Serverless low cost analytics par Audric Guigon, Adways (lire l’article à ce sujet).
• Build chatbots with API AI & Google Cloud Function, par Guillaume Laforge, Google.
• Real time serverless data pipelines on AWS, par Farzad Senart, Alsanium.
• Azure Functions, par Benjamin Talmard, Microsoft.

Retrouvez l’ensemble des présentations du TIAD Camp sur Slideshare

Inscrivez-vous pour suivre l’actualité du TIAD :

Prochain TIAD Camp le 20/06/2017 :