Première conférence mondiale dédiée à la tendance serverless, Serverlessconf est une conférence communautaire, dont l’objectif est de partager les expériences autour du développement d’applications sur des architectures dites serverless. Randall Hunt (AWS), speaker lors de cet événement, a accepté de répondre à nos questions sur l’évolution du Serverless en 2018.

Randall Hunt

Randall Hunt est évangéliste technique senior et ingénieur logiciel chez AWS. Si Python est son langage favori, on le trouve parfois aussi du côté obscur du C++. Randall est l’auteur de  gitshots, apodtwitter, isthe7running, et contributeur à MongoDB, Homebrew, boto et d’autres outils et librairies Open Source. Avant, il aidait la NASA et SpaceX à lancer des fusées, puis il s’est pris de passion pour la programmation à MongoDB. Randall est aussi un « space nerd », passionné par l’espace et tout ce qui y touche.

Peut-on parler de révolution Serverless ? En quoi le serverless change le développement des applications ?

Je n’utiliserais pas le mot « révolution », mais le Serverless est un paradigme qui va durer. Nous avons vu les débuts de ce paradigme il y a de nombreuses années avec du computing basé sur des événements, sans avoir à gérer d’infrastructure, avant même l’arrivée d’AWS Lambda. En 2014, AWS Lambda a apporté tout un nouvel ensemble de possibilités pour invoquer des FaaS (Function as a Service). On peut les déclencher suite à un upload sur S3, sur un webhook (fonction de rappel HTTP), les possibilités sont nombreuses… autant de choses qu’on ne pouvait pas faire auparavant sans avoir de nombreux serveurs. Aujourd’hui, nous assistons à l‘évolution du Serverless, plutôt qu’une révolution : l’outillage gagne en maturité, et nous développons la capacité à construire des architectures et des applications plus complexes. Aurora Serverless par exemple : l’infrastructure peut être réduite à zéro, ce qui signifie ne pas avoir à payer pour ce qui n’est pas utilisé, ne plus avoir besoin d’une base de donnée toujours ON. Je pense que c’est ce vers quoi le Serverless se dirige, de plus en plus de produits où on ne paie pas pour du compute non utilisé.

Avec le Serverless, il y a également un fort changement du côté des opérations. Beaucoup disent qu’il n’y a plus de DevOps avec le Serverless, mais je pense que le Serverless apporte des problématiques opérationnelles différentes, mais tout de même plus simples à gérer que celles liées aux serveurs.

Comment le Serverless répond aux besoins actuels de l’IT ?

Il y a de nombreux exemples d’utilisation du Serverless dans notre industrie, des sociétés comme acloud.guru ont construit toute leur plateforme autour de Lambda, S3 et DynamoDB. Quels sont les besoins actuels de l’IT ? Nous avons besoin d’agilité, de maintenabilité, et de capacité à faire les choses. En tant que développeurs, nous aimons bricoler autour de ces nouveaux outils, c’est fun, c’est inspirant, mais l’industrie IT a besoin a de produits finis, d’outils fonctionnels pour résoudre des vraies problématiques métiers. Des sociétés comme le Washington Post utilisent le Serverless pour accomplir des objectifs métiers complexes, et ça fonctionne ! On voit beaucoup d’études de cas à propos de l’impact sur les coûts, mais il ne s’agit pas que des coûts, c’est une question d’agilité et de maintenabilité. Et cela ne concerne pas que les webapps… certains gèrent toute la mise en conformité de leur industrie avec de simples fonctions Lambda.

Comment les services Cloud classiques sont-ils complémentaires du Serverless ?

Je pense que la plupart des services AWS sont aujourd’hui construits dans l’optique de tirer parti du paradigme Serverless. L’annonce d’Aurora Serverless au re:Invent 2017 est l’exemple d’une base de donnée stateful et persistente dont l’architecture repose sur des portions du paradigme Serverless. Les bases de données ne se prêtent pas facilement à ces aspects entièrement managés. DynamoDB est populaire parce qu’il n’y a aucun serveur à gérer… si on arrive à amener le même type de synergie avec les autres services AWS, on rendra possible de nouveaux workloads. Lambda, en particulier, fonctionne bien avec tous types de services, et à mesure que l’éco-système s’améliore, nous aurons de plus en plus de sources d’événements. On nous demande beaucoup de pouvoir invoquer des événements depuis SQS, ou depuis un type d’événement particulier dans un stream DynamoDB, plutôt que de devoir appeler tout le stream dans Kinesis. Il y a encore beaucoup de possibilités de développement dans l’invocation des Lambdas. La fonction est au coeur du Serverless, et c’est vrai pour tous les acteurs du Cloud, pas seulement AWS, nous allons voir de plus en plus de FaaS (Function as a Service). Nous aurons peut-être besoin de sources d’événements chez différents Cloud providers, mais qui ne demandent pas de modifier le code en profondeur pour passer de Lambda à quelque chose d’autre. C’est ma vision du futur, je n’ai pas de certitude sur ce qui va arriver, mais je pense que les gens vont vouloir tirer le maximum du Serverless.

Parmi les nombreuses nouveautés autour du Serverless annoncées par AWS, qu’est-ce qui t’intéresse le plus ?

Beaucoup de mises à jour autour de Lambda sont géniales : le fait de pouvoir contrôler le nombre d’exécutions simultanées par fonction est très utile pour moi (Lambda imposant une limite d’exécutions parallèles sur chaque compte AWS, il peut être intéressant pour un développeur de limiter une fonction à un nombre fini d’exécutions simultanées, de façon à ne pas impacter les autres lambdas du compte, par exemple celles liées à d’autres projets / fonctionnalités)- ou d’avoir 3GB de mémoire. Avant le re:Invent, nous avons également annoncé beaucoup de nouveautés sur Lambda@Edge, qui permet maintenant de choisir dynamiquement une origine ou même de faire tourner toute une application sur le CDN. SageMaker n’est pas entièrement Serverless, mais pouvoir lancer un conteneur Docker (un conteneur, c’est retourner vers les serveurs!) de façon managée, pouvoir invoquer des requêtes sur ce conteneur et servir un modèle d’IA, c’est vraiment puissant. Bien sûr il faut toujours gérer les directories et les workspaces, donc appeler ça du Serverless est peut-être un abus de langage. Il y a aussi Aurora Serverless, Cloud9 IDE, et beaucoup de nouveaux services… c’est une année géniale pour le Serverless, et pour le Cloud en général. Je me souviens en 2014, j’étais dans le public au moment de l’annonce de lambda, et j’ai essayé d’évaluer les réactions : la moitié de la salle n’avait pas saisi les implications. Aujourd’hui cette moitié n’existe plus, tout le monde veut savoir comment migrer les architectures et les applications vers du Serverless, comment réécrire ses logiques métiers pour Lambda… tout a vraiment changé en seulement quelques années, et nous n’en sommes qu’aux débuts !

Comment vois-tu l’évolution de l’éco-système Serverless ?

Je pourrais faire beaucoup de prédictions, mais je suis très excité par le développement des technologies Serverless, AWS Cloud9 IDE par exemple permet de travailler avec les fonctions Lambda et API Gateway beaucoup plus rapidement. Avec le Serverless Application Model (SAM), il devient plus facile de déployer une Lambda, API Gateway mais aussi une table DynamoDB, un bucket S3, et de connecter toutes ces sources d’invocation, et de les maintenir dans quelques fichiers facilement testables. On peut construire un pipeline CI/CD ou utiliser AWS CodeStar et lancer une application serverless basée sur Flask en quelques minutes. Et tout cela va encore progresser. Il y a aussi beaucoup d’intérêt du côté de la communauté, des développeurs qui construisent des framework comme  Zappa, Chalice, Serverless, Apex, Sparta et de nombreux autres… On peut s’attendre sous peu au support de.NET 2.0, Go ayant été annoncé il y a quelques jours. Et tant que les clients le demanderont, il y aura de plus en plus de sources d’événements.

X-Ray est également un sujet important, parce que le debug des applications Serverless est très différent de celui d’applications traditionnelles. Le serverless, ce sont des microservices massivement connectés… comme Ashley Sole de SkyScanner l’a fait remarquer lors d’une conférence à Londres en 2016, quand on visualise les dépendances avec X-Ray, on a toujours plus d’outputs qu’on ne le suspecte. X-Ray donne de la visibilité, et l’usage de technologie de tracing va devenir incontournable dans les applications serverless en 2018. Il faut un meilleur monitoring, il ne s’agit pas simplement de collecter des métriques mais de comprendre les appels distants et les invocations.

Quand on a de nombreuses petites fonctions, et autant de développeurs sur chaque service, il faut ajouter des tests, des contrats avec ceux vous invoquent, les données qui sont modifiées, etc. Avant, il n’y avait que des applications monolithiques, pour faire un changement il fallait déployer toute l’application, aujourd’hui l’unité de déploiement est beaucoup plus petite. Avec de plus petites unités de développement, on a plus d’agilité, plus de granularité, mais aussi plus de complexité dans le graphique des services. C’est pourquoi les outils de tracing, comme X-Ray ou d’autres, sont indispensables.