Un article rédigé par Aristide Fumagalli (DevOps Consultant) et Alan Craig (DevOps Consultant, Devtoeam UK) et publié à l’origine ici.
Les technologies serverless font beaucoup parler d’elles en ce moment et les fournisseurs de services cloud poussent grandement à leur adoption. La question à se poser : est-ce juste une mode ou y a-t-il un vrai avantage à basculer sur ce modèle ? Cet article vise à éclairer sur les capacités d’une architecture serverless, aujourd’hui, et demain.
Le serverless est un sérieux prétendant et pourrait s’imposer dans de nombreux aspects du développement et du déploiement d’applications. Nous avons établi quatre points de comparaison clés entre cette approche serverless et des approches plus traditionnelles – à savoir la virtualisation (EC2s) ou la conteneurisation (Kubernetes) basées sur la plateforme AWS. Ces quatre critères sont :
- le coût
- la scalabilité
- la facilité d’usage
- la durabilité
LE COÛT : LA BONNE NOUVELLE POUR VOS COMPTES DE RÉSULTAT
Le coût est vraiment le point sur lequel le serverless s’illustre comparativement à ses alternatives. Les applications serverless ont démontré qu’elles représentaient une charge financière moindre que ses équivalents dans bien des cas. Mais avant de revenir à ces considérations budgétaires, voyons plus précisément ce que l’on entend par « serverless », et pourquoi il s’agit ici d’un nom plus que d’un adjectif.
En fait, l’approche serverless consiste à exécuter du code sans avoir à manager ses propres machines. L’idée est de remplacer, voire même d’évacuer complètement la notion de serveur en marche en permanence au profit de processus déclenchés par des événements. De cette manière, les coûts peuvent être considérablement réduits dans la plupart des applications dont les tâches ne nécessitent pas de grandes capacités de calcul ou pour lesquelles une grande puissance de traitement est mobilisée pour manipuler d’énormes quantités de données.
Comment cela est rendu possible ? Le principal avantage du serverless est son modèle pay-as-you-go, qui ne charge son utilisateur que pour la mémoire, les capacités de calcul et la data qu’il consomme effectivement. Le temps qu’une application passe « en veille » ou n’est pas utilisée, ne coûte rien à son propriétaire (à la différence d’un cluster Kubernetes ou d’instances EC2). À titre d’exemple, AWS Lambda est tarifé au nombre de requêtes (0,20$ par million de requêtes) et au coût des ressources informatiques utilisées durant ce temps (0.0000166667$ pour chaque GB/seconde). L’exécution de Lambda pour 128 Mo pendant 100 ms coûterait donc 0,00000041$ dans la zone Irlande par exemple.
Prenons une application web simple, typiquement, une application de vote. En principe, elle s’exécuterait sur un EKS (Elastic Kubernetes Service ) en manageant des pods contenant les différentes applications requises pour faire fonctionner la webapp, de bout en bout. Ces pods, selon leur dimension, peuvent ou non résider dans le même nœud. Dans tous les cas, une telle application web nécessiterait une puissante instance EC2 pour permettre à 5 différentes applications de tourner en continu.
Par ailleurs, une implémentation serverless de cette même application web comprendrait des composants qui ne fonctionnent pas en continu, n’exploitant ainsi qu’une fraction des capacités de calcul utilisées par ses alternatives. Et dans la plupart des cas, ce type d’applications web est bien plus optimisé pour un usage cloud.
Imaginons que cette application soit l’objet de 50 sessions en une journée. Via le Cost Calculator développé par Xavier Lefèvre basé sur la solution officielle d’AWS, on peut estimer que cette application coûterait 0,50$ par mois si elle était développée via une architecture serverless, en y incluant la partie gratuite. C’est très peu comparé au coût nécessaire pour exécuter la moindre instance EC2 sur un mois complet (t3a.nano à 3,43$, ce qui ne serait toujours pas suffisant pour exécuter l’ensemble du cluster K8s). Avant même de considérer le coût d’un monitoring et d’une scalabilité auto-gérés, on voit d’ores et déjà se dessiner le potentiel de réduction des coûts à plus large échelle.
LE SERVERLESS PEUT-IL ÊTRE MIS À L’ÉCHELLE ?
La scalabilité est une autre caractéristique phare des architectures serverless. Pourquoi ? Revenons-en à notre exemple d’application de vote. Avec Kubernetes, quand les charges augmentent et que les pods individuels sont sursollicités, des pods supplémentaires sont automatiquement créées pour répondre à la demande (seulement si vous avez spécifié un Deployment/ReplicaSet). Cela signifie que les nouveaux conteneurs sont lancés sur de nouveaux nœuds et que plus d’instances EC2 sont lancées, augmentant les coûts en conséquence.
Par ailleurs, les composants serverless comme les Lambdas permettent un grand nombre de d’exécutions simultanées, ce qui veut dire qu’il n’y a plus de temps d’attente pour déclencher les machines virtuelles et la mise à l’échelle est quasiment instantanée. En zone Irlande, 3000 Lambdas sont lancés simultanément durant un pic de charge et AWS augmente ses capacités à hauteur de 500 chaque minute. Et ce, automatiquement, sans effort à fournir.
La principale différence réside dans le fait que si le développeur n’a pas à se préoccuper des politiques de mise à l’échelle dans le cadre d’une approche Serverless (car elles sont entièrement gérées par le fournisseur de cloud computing), il n’en va pas de même avec les conteneurs, pour lesquels cette automatisation doit être mise en place et configurée au préalable.
LA FACILITÉ D’UTILISATION EN QUESTION
Le serverless est particulièrement adapté aux cas d’utilisation où le time to market est important et où l’équipe de développement n’a aucune connaissance opérationnelle, ou n’a pas le temps de s’occuper de l’infrastructure sous-jacente. Cela a pour avantage que les développeurs peuvent consacrer plus de temps à l’application plutôt qu’à déployer l’infrastructure qui la prend en charge.
Avec le serverless, les développeurs peuvent créer des applications rapidement. Les composants serverless font abstraction de l’infrastructure et en confient sa gestion à AWS. Cela permet aux développeurs ayant peu ou pas d’expérience sur AWS de créer et déployer rapidement des applications. En résumé, ils sont libres de se concentrer sur ce qui est important pour eux et n’ont pas à se soucier de la mise à niveau et du patching des serveurs.
Les développements rapides sont également facilités par Lambda, qui prend en charge un large éventail de langages de programmation, ce qui permet à des développeurs aux compétences diverses d’utiliser ce service.
Lambda n’est cependant pas la seule alternative serverless à réduire le time to market de cette même manière. Fargate est un autre service d’AWS qui permet de continuer à utiliser Kubernetes sur le principe du pay-as-you-go, sans avoir à redévelopper totalement l’application pour l’adapter à une nouvelle architecture. Il s’agit d’une option très populaire pour les applications legacy, car elle est beaucoup plus simple à gérer qu’une instance EC2 traditionnelle.
AWS se charge de la maintenance de l’infrastructure de Fargate, il n’y a donc pas à prendre en charge les coûts liés aux correctifs et aux mises à jour. Si une faille de sécurité apparaît, les utilisateurs d’EC2 doivent la corriger manuellement, tandis que les utilisateurs de Fargate n’ont pas à s’en soucier, car AWS prend en charge sa correction. C’est notamment la raison pour laquelle Fargate est considéré comme une option plus sûre.
Généralement, l’utilisation de Fargate ne permet pas de réaliser des économies significatives par rapport à EC2, mais elle offre de nombreux avantages pour l’utilisateur. Fargate a un modèle pay-as-you-go qui facture selon le nombre de cœurs de processeur et la mémoire utilisés par seconde, vous ne payez que pour ce que vous utilisez. Avec EC2, les utilisateurs peuvent sous-approvisionner leurs instances, c’est-à-dire qu’ils ne disposent pas d’un nombre d’instances suffisant pour les besoins de leur application, ou plus communément sur-approvisionner leurs instances, c’est-à-dire qu’ils paient en plus pour les ressources qu’ils utilisent. Fargate, par contre, dimensionne cela automatiquement dès le départ, ce qui élimine ce problème (et rend le dispositif beaucoup plus facile à utiliser).
AWS fournit également une suite d’outils de développement serverless pour construire un workflow CICD pour applications, ce qui permet de réduire le time to market. Ces services comprennent le CodeCommit (contrôle de la source), le CodeBuild (intégration continue), le CodeDeploy (service de déploiement), le CodePipeline (livraison continue), le CodeArtifact (stockage d’artefacts). L’avantage de ces services entièrement gérés par AWS est qu’ils nécessitent une configuration minimale par rapport à des alternatives telles que Jenkins et Gitlab. Dans le schéma ci-dessus, on peut voir comment ces services peuvent être intégrés ensemble et se faire une idée de l’architecture associée.
DURABILITÉ : QUELLE SOLUTION EST LA PLUS ÉCOLOGIQUE ?
La durabilité est un aspect important qu’il faut avoir à l’esprit lors de la conception dans la mesure où elle est de la responsabilité de l’utilisateur. Exécuter une application dans une architecture serverless peut être un moyen efficace de réduire l’empreinte carbone de ses activités.
Comparons l’empreinte carbone d’une application exécutée sur EC2 et sur Lambda. Si on exécute une application sur une instance EC2, il peut y avoir des périodes où l’instance est inactive. Cela veut dire que l’instance est sous-utilisée et gaspille de l’énergie.
L’exécution via Lambda est plus économe en énergie. Lorsqu’un Lambda est déclenché, il s’exécute dans une microVM sur une instance EC2 gérée par AWS. Lorsque le Lambda a terminé son exécution, la microVM est remplacée par une autre afin que le Lambda d’un autre utilisateur puisse s’exécuter. Cette approche garantit une meilleure utilisation des ressources existantes, par opposition à l’utilisation de nouvelles ressources.
EST-IL TEMPS DE PASSER AU SERVERLESS ?
Après avoir comparé ces solutions d’architecture, on peut conclure que le serverless ne convient pas à tous les cas d’utilisation et que la conteneurisation reste la meilleure option pour certaines applications.
En effet, il existe de nombreux cas où le serverless n’est pas la bonne solution et peut finir par coûter plus cher que les alternatives plus classiques. C’est le cas, par exemple, des applications où Java/JVM sont utilisés, où des tâches longue durée sont nécessaires, ou lors de la création d’applications qui nécessitent des API de bas niveau (par exemple, le contrôle des threads).
En outre, des restrictions réglementaires peuvent empêcher certaines entreprises (comme celles qui fournissent des services financiers ou des organisations gouvernementales) d’utiliser des logiciels et de l’équipement partagés entre plusieurs clients. Il est alors préférable qu’elles utilisent des hôtes dédiés si elles veulent quand même utiliser le cloud. Les applications serverless ne sont généralement pas disponibles sur des hôtes dédiés et ne conviennent donc pas à ces cas d’utilisation.
Toutefois, lorsque le serverless est mis en œuvre correctement, il permet de réaliser des économies importantes par rapport aux approches traditionnelles, se positionnant non seulement comme une alternative valable, mais aussi comme une solution offrant des améliorations significatives par rapport aux technologies actuelles.
____________