Microservices : de no-code à lambda & Kubernetes, comment choisir ?
Cloud Will Become a Business Necessity by 2028
Introduction
Là où le cloud était autrefois simplement une innovation technologique offrant flexibilité et accélération du time-to-market, il est désormais un véritable atout stratégique que les entreprises adoptent de plus en plus.
Vous envisagez peut-être de vous lancer dans cette aventure ; cependant, face à la multitude d’options disponibles, vous vous demandez sûrement comment faire le meilleur choix. Cet article devrait vous apporter quelques pistes de réflexion à ce sujet.
La démarche suivie dans cet article est la suivante :
Pourquoi des microservices sur le cloud ?
L’approche traditionnelle des applications repose sur une architecture monolithique, où tous les composants et fonctionnalités sont regroupés dans un seul livrable. Cependant, si ce monolithe était divisé en petits modules fonctionnels, indépendants les uns des autres, leur développement et leur maintenance seraient grandement simplifiés. Mieux encore, ces modules pourraient être réutilisés dans d’autres applications : ce sont les microservices.
Il s’agit de l’architecture privilégiée pour assurer une mise à l’échelle efficace. Cependant, elle nécessite des compétences solides pour gérer l’infrastructure, les déploiements, et d’autres aspects techniques. Le no-code offre une solution à ce problème : il simplifie le développement, permet de se concentrer sur la création de valeur, et n’exige aucune gestion d’infrastructure. Toutefois, il présente certaines limites. En effet, les plateformes no-code sont des SaaS basés sur l’utilisation, ce qui peut entraîner des coûts additionnels importants.
C’est ici que le cloud devient une alternative intéressante : en déléguant toujours la gestion de l’infrastructure au fournisseur (via le serverless) mais en conservant le contrôle sur le code, il est possible de réduire significativement les coûts.
Application fil rouge
Pour mieux illustrer ce point, prenons l’exemple de l’application « Fil rouge », qui servira de fil conducteur tout au long de cet article. Fil rouge est une application backend, structurée en microservices versionnés et indépendants. Actuellement hébergée sur une plateforme no-code, elle réalise environ 50 000 exécutions par mois, ce qui coûte environ 800 $.
Cependant, avec une augmentation de la charge prévue (par exemple 10 millions d’exécutions mensuelles), Fil rouge devra être migrée vers une plateforme plus adaptée. Rester sur la plateforme no-code entraînerait des coûts dépassant les 150 000 $ par mois ! Il est évident qu’une mise à l’échelle massive est irréaliste sur une plateforme no-code.
Choix de l’architecture
Pour créer une application en microservices sur le cloud, plusieurs options d’architecture sont envisageables :
- Lambdas (FaaS)
- Conteneurs (CaaS ou PaaS avec Kubernetes, Docker ou Podman)
Il est important de prendre en compte la portée du projet, la complexité de sa mise en œuvre et de sa maintenance, ainsi que les compétences nécessaires. Cela élimine Kubernetes pour l’application Fil rouge, car il est beaucoup trop complexe par rapport à la portée du projet et n’est pas du tout serverless.
Il est plus difficile de trancher entre lambdas et conteneurs :
- Conteneurs : ils sont plus flexibles, limitent le risque de dépendance à un fournisseur (vendor lock-in), et offrent de meilleures performances. Leur mise en œuvre facilitée par le cloud reste complexe. De plus, les conteneurs consomment des ressources en continu, même lorsqu’ils ne sont pas utilisés.
- Lambdas: elles sont plus simples à appréhender et, par nature, encouragent à découper le code en microservices. Leur modèle de consommation à la demande permet de ne payer que pour ce qui est réellement utilisé. Toutefois, les ressources ne sont allouées qu’à l’exécution, ce qui peut entraîner une latence initiale (cold start).
Les deux modèles de tarification diffèrent également (en tenant compte que le système d’exploitation et l’architecture processeur influencent aussi le coût) :
- Lambdas: facturées par tranche de millions d’exécutions et par Go.s consommés mensuellement, avec un quota mensuel gratuit.
- Conteneurs : facturés en vCPU par heure et en Go par heure.
Le graphique suivant illustre la tendance des coûts entre conteneurs et lambdas en fonction du nombre d’exécutions mensuelles (pour 1 lambda et 1 conteneur, tous deux configurés au minimum) :
Sur de faibles volumes, l’offre gratuite mensuelle des lambdas réduit considérablement le coût d’exploitation. En revanche, un conteneur étant facturé en fonction du temps d’exécution, son coût reste constant, indépendamment de l’activité.
Cependant, lorsque le volume d’exécutions augmente, la tendance s’inverse : les lambdas deviennent progressivement plus coûteuses, tandis que les conteneurs restent plus avantageux à grande échelle. Il est important de souligner que la courbe pourrait être encore plus marquée si plusieurs lambdas sont actives en parallèle.
Ainsi, le choix entre ces deux options devient clair : si la charge estimée reste modérée, les lambdas sont la solution la plus rentable. En revanche, pour des volumes élevés ou en cas de montée en charge importante, les conteneurs se révèlent plus profitables.
Choix du provider
Il existe de nombreux critères à prendre en compte lors du choix d’un fournisseur cloud, tels que les coûts, la facilité de prise en main, l’écosystème, et l’accès aux technologies les plus récentes. Dans le cadre de Fil rouge, Amazon Web Services (AWS) et Microsoft Azure offrent les tarifs les plus compétitifs.
Ainsi, la comparaison entre ces deux géants du marché se fera principalement sur ce critère pour le projet Fil rouge. En projetant une charge de 10 millions d’exécutions mensuelles :
AWS propose, pour les besoins de Fil rouge, des offres plus attractives. Cependant, il est important de noter que ces chiffres peuvent varier considérablement en fonction des services spécifiques utilisés et des modèles de tarification choisis. De plus, cette comparaison ne prend en compte que les coûts liés à la partie métier. Il faudra également ajouter les frais liés à l’utilisation du réseau, au stockage des données ainsi qu’à d’autres services annexes, qui peuvent significativement impacter le coût total du projet.
Conclusion
Les microservices sont souvent associés aux conteneurs, mais ce n’est pas la seule solution disponible. L’utilisation d’une plateforme no-code ou low-code pour des microservices à petite échelle reste une option envisageable. Cependant, pour un déploiement en production à grande échelle, d’autres solutions doivent être envisagées.
Les FaaS peuvent devenir très coûteuses en cas de forte consommation, mais pour un usage modéré, elles constituent une solution parfaitement viable. Afin de préparer une future montée en charge, il serait judicieux de concevoir une architecture de microservices très modulaire, facilitant une éventuelle conteneurisation voire une architecture hybride.
Mettre des microservices dans le cloud, ce n’est pas une solution magique. Comment gérer les connexions entre les services distribués dans le monde avec une latence minimal ? Quels compromis entre serverless et sécurité ? Comment maitriser les coûts du cloud ? Ce n’est qu’avec les réponses à ces questions que le cloud deviendra un incontournable allié business.
