Comment les architectures FaaS changent la donne
Introduites publiquement par AWS et leur service AWS Lambda en 2014, les architectures FaaS (Functions as a Service) ont été à l’origine d’un changement majeur dans la conception et la mise en production de nouveaux services. Les autres acteurs majeurs du cloud ont mis quelques années à proposer un service concurrent, mais aujourd’hui, les FaaS sont omniprésentes tant sur les cloud publics que dans certains services indépendants.
Principes des FaaS
Le principe fondamental des FaaS est simple : on développe ses applications sous la forme de fonctions afin de les découper en services métiers et techniques qui communiquent entre eux. En retour, les services FaaS promettent un scaling automatique et quasi-infini, et un pricing à la consommation. Ainsi, lorsqu’une application n’est pas utilisée, elle ne coûte virtuellement rien.
C’est une solution qui découle des choix architecturaux autour des microservices. Avec leur avènement et le déclin des monolithes, il fallait une solution qui permette de déployer facilement et simplement cette “nouvelle” façon de faire. Ainsi, les services FaaS proposent un environnement de runtime partagé sur lequel chaque fonction tourne en isolation.
De nombreux avantages découlent de ces choix. Tout d’abord, le besoin en ops est inexistant sur la partie applicative, et engendre donc une réduction des coûts. Plus besoin de penser à mettre à jour son OS ou les bibliothèques systèmes, ou de gérer un pare-feu par machine, le cloud provider s’en charge et en est responsable. Toute la partie networking est également gérée par le fournisseur, bien qu’il vaille mieux, dans la plupart des cas, mettre en place un VPC et des règles de networking internes. Cela génère un autre avantage, les environnements sont sécurisés et performants ! En effet, le scaling automatique permet de ne pas se soucier des pics de charge, et des outils sont disponibles pour surveiller le trafic et le coût, afin de mettre en place des limites et des alertes. Un autre point important à souligner est l’intégration forte avec les différents systèmes de monitoring présents dans les différents cloud providers, qui permet de surveiller et analyser facilement tout le trafic, les erreurs et les logs des différentes fonctions.
Nos clients nous demandent souvent de les aider à faire leurs choix technologiques Nous recommandons très régulièrement l’utilisation des services FaaS des différents Cloud Providers, que nous développions des microservices ou non. La promesse de coûts réduits, tant en ops qu’en infrastructure, peut être très attrayante. Savoir qu’il est toujours possible de passer sur un système plus classique est un argument fort. La question du vendor lock-in se pose forcément, mais elle n’est en général pas un problème.
Séparer son application en plusieurs microservices apporte également de nombreux avantages, comme la séparation des préoccupations, la facilité de maintenance, l’amélioration de la qualité de service. Nous avons rédigé un dossier sur les microservices, n’hésitez pas à y jeter un œil.
Présent et Projections
Aujourd’hui, de plus en plus d’applications sont développées sur des systèmes FaaS. Les perspectives de simplicité de déploiement et l’attrait de leur coût opérationnel très faible en font une solution alléchante, tant pour des PoC (Proof of Concept) que pour des applications industrialisées et déployées à grande échelle. Seules des applications à très fort trafic pourraient pâtir d’un coût supérieur par rapport à un hébergement sur Kubernetes, par exemple. Ainsi, les applications dites serverless tendent à devenir la norme. On s’éloigne des machines et du code natif pour des applications qui peuvent tourner partout.
Chaque service a toutefois ses spécificités. Une application développée sur une architecture FaaS sur AWS ne fonctionnera pas instantanément chez GCP ou Azure, même si la seule différence de code sera au niveau du Front Controller et des services externes utilisés. Les limitations de l’environnement de runtime ne sont en revanche pas les mêmes et peuvent apporter des contraintes fortes. Des initiatives comme OpenFaaS commencent à voir le jour. Il n’est pas impossible que les différents cloud providers s’alignent sur les entrées et sorties de ces fonctions si une organisation comme la CNCF (Cloud Native Computing Foundation) prend le sujet en main, comme elle a pu le faire pour Kubernetes.
En tout cas, les cloud providers misent sur ces technologies et proposent de plus en plus de solutions tournant autour de ces Fonctions. Aujourd’hui, il est possible de mettre en place des machines à état qui se basent sur les sorties de fonctions et en lancent d’autres précisément. Elles fonctionnent également très bien dans des contextes événementiels, qui pullulent dans les clouds publics. Des cas typiques comme “à l’upload d’un fichier, exécuter tel morceau de code” sont possibles avec une simplicité extrême. Cette façon de concevoir apporte de nombreuses améliorations. Les applications sont ainsi de plus en plus asynchrones, et permettent une scalabilité horizontale bien meilleure que traditionnellement.
Chez Neoxia, nous avons pu mettre en place de nombreuses solutions utilisant les infrastructures FaaS, pour des clients de toutes tailles. Aujourd’hui, nous développons tous nos projets à l’aide d’APIs. Sur AWS, par exemple, nous utilisons API Gateway pour définir nos routes, et mappons ces APIs aux fonctions que nous développons généralement avec NodeJS. Nous utilisons également les Streams DynamoDB que nous branchons à des Lambdas pour mettre à jour en continu, presque en temps réel, les données qui y sont stockées.
Les architectures FaaS ne sont pas seulement présentes côté back. De nombreux services permettent également de lancer divers scripts sous certaines conditions. Par exemple, Auth0, sous la forme de rules, va inciter les développeurs à découper les différentes règles métier de connexion et d’inscription en scripts unitaires. CloudFlare, de son côté, propose de déployer des scripts sur des serveurs at edge pour modifier le comportement d’une application front ou améliorer le cache.
Inconvénients et difficultés
Les architectures FaaS n’apportent pas que des avantages, évidemment. Comme j’ai pu l’écrire précédemment, sur des applications à très fort trafic, le coût peut devenir plus important. À spécifications équivalentes, une machine virtuelle qui tourne en continu sera toujours moins chère qu’une lambda appelée constamment. Mais le prix n’est pas le seul point d’attention.
Il est toujours possible de configurer le nombre de ressources allouées à une fonction, mais en général, il n’est pas possible de décorréler le besoin en CPU de celui en RAM. Ainsi, pour de nombreux types de workloads, les architectures FaaS peuvent devenir inefficientes. Si votre code a besoin de beaucoup de mémoire, il profitera automatiquement de plus de vitesse de calcul. Même s’il ne l’utilise pas, tout cela sera quand même facturé.
De plus, puisque l’environnement de runtime est géré par le cloud provider, il n’est pas possible de faire des optimisations de bas niveau. Dans certains cas, l’utilisation d’une librairie système peut être également nécessaire et donc rendre impossible le développement sous architecture FaaS. Sur ce point là, toutefois, AWS est en avance, puisqu’ils proposent aux utilisateurs d’utiliser un runtime custom. Vous pouvez donc directement installer les bibliothèques nécessaires au bon fonctionnement de votre code.
Ainsi, les FaaS ne sont pas toujours suffisantes. Il arrive souvent qu’une partie de la charge soit directement affectée à des machines virtuelles pour optimiser les coûts.
Conclusion
L’architecture FaaS prend de l’ampleur et continue de se démocratiser au sein des entreprises. Aujourd’hui, elle répond à un grand nombre de cas d’usages et beaucoup de technologies viennent enrichir son écosystème. Ce n’est qu’un début car si aujourd’hui, AWS conserve son avance, la concurrence progresse à grands pas. Cette course va forcément faire naître de nouvelles idées et permettre à ces technologies d’ores et déjà production ready de continuer à s’améliorer pour peut-être devenir la norme ?
