L’avenir du cloud sera sans aucun doute serverless. Ses atouts indéniables n’empêchent pas la nuance, fruit de l’expérience. Cette technologie prometteuse n’est pas forcément adaptée à tous les usages, Amazon en sait quelque chose.
L’ère est au “Move to Cloud”. Les entreprises en pleine transformation numérique migrent de plus en plus de données et d’applications sur site, dites on premise, vers le cloud, un catalyseur d’innovation, qui permet de gagner en agilité, rapidité et efficacité.
Dans le giron du cloud, un nouveau paradigme, apparu en 2014 sous l’égide d’Amazon Web Service, fait parler de lui. Il s’agit du serverless, ou informatique sans serveur (FaaS Function As A Service).
L’informatique serverless a radicalement changé le quotidien des développeurs. Grâce à elle, ils peuvent créer des applications beaucoup plus rapidement sans avoir la contrainte de gérer l’infrastructure, car le fournisseur de services cloud (Cloud Provider) fournit, met à l’échelle et gère automatiquement l’infrastructure nécessaire pour exécuter leur code.
Gain de temps, de productivité, agilité, efficacité opérationnelle, optimisation des ressources, réduction des coûts sont au rendez-vous. Une aubaine, tant pour les développeurs que les entreprises qui peuvent se concentrer sur l’innovation, proposer de nouvelles fonctionnalités ou nouveaux services/produits plus rapidement.
Le serverless : catalyseur d’innovation et de business
Bien au-delà du buzzword qui entoure le serverless, cette technologie et architecture sont promises à un bel avenir. Qu’elle soit technique, opérationnelle ou économique, sa valeur ajoutée est indéniable.
La diminution de gestion de l’infrastructure permet aux développeurs de se concentrer sur la logique métier et le fameux triptyque “build, run, deploy” de nouvelles applications, fonctionnalités et services. L’adoption du serverless va également aider les entreprises à réduire les coûts TCO (total cost of ownership) d’un produit/service. Sa scalabilité adaptative “by design” permet de supporter une charge de travail imprévisible ou irrégulière. De tous ces avantages découlent un cycle de développement plus rapide, une réduction du Time to Market et une plus grande agilité des équipes de développement.
Enfin, à l’heure de la frugalité IT, un autre de ses avantages est la réduction des coûts et de son empreinte carbone. Basé sur un modèle de facturation “Pay as you go”, son coût est adapté et l’usage et évite les mauvaises surprises. Et côté coût énergétique, le serverless change également la donne. Dans le cas de création d’une application ou d’un nouveau service au sein de celle-ci, le développeur ne va utiliser que les ressources utiles pour exécuter son code. De plus, le trafic sur les applications oscille entre pics et périodes plus creuses. En consommant uniquement ce dont on a besoin, on limite ainsi leur empreinte carbone.
Serverless : le retour d’expérience pour éclairer son adoption
Si l’éloge de son adoption et usage peut se lire partout, il faut tout de même apporter quelques nuances. Le géant Amazon, précurseur et moteur du serverless, en sait quelque chose.
Tout récemment, les médias, comme la communauté serverless, ont vivement réagi en apprenant qu’Amazon basculait un des services d’Amazon Prime du serverless vers un monolithe. Certaines voix ont annoncé la fin du serverless, d’autres comme moi rejoignent la réflexion et conclusion suivantes: il faut s’écarter de toute tentation de vouloir suivre la “tendance” du serverless et bien réfléchir avant de l’adopter. Si beaucoup d’applications et de workflows peuvent déjà être développés en serverless, tous les projets/services ne s’y prêtent pas.
Le retour d’expérience d’Amazon en est la parfaite illustration. Explications
Leur service Prime Vidéo fournit des milliers de flux en direct à leurs clients. Il avait mis en place un outil pour surveiller chaque flux, identifier automatiquement les problèmes de qualité et déclencher une action pour les résoudre. Mais cet outil, qui n’a pas été prévu/conçu pour fonctionner à grande échelle, était coûteux et créait également des goulots d’étranglement. Amazon a donc fait le choix de réorganiser son infrastructure car l’approche distribuée n’offrait pas de bénéfices, bien au contraire.
Je rejoins Amazon dans son analyse. Les microservices et le serverless sont des outils puissants qui fonctionnent à très grande échelle, mais l’essentiel est avant tout de savoir s’il faut les utiliser sur le monolithe. Ceci doit être réfléchi et décidé au cas par cas.
Le déplacement d’une architecture serverless vers une application monolithe classique a permis de réduire le coût de leur infrastructure de plus de 90 % et d’accroître leurs capacités de mise à l’échelle, de gagner en résilience et bien évidemment de réduire les coûts.
Ce changement de cap d’Amazon ne remet pas du tout en cause la valeur ajoutée du serverless. Il rappelle que, comme tout choix technologique, il doit correspondre aux besoins du projet.
Lorsqu’il vient le choix d’adopter le serverless, il ne faut pas écouter naïvement le chant des sirènes mais s’appuyer sur des faits, la communauté ou l’expertise de ses pairs. Sans cela, vous perdrez du temps, de l’argent et sans nul doute vos talents.
