Technologies

Les lacunes intrinsèques de l'informatique serverless

---

Le serverless est une approche populaire pour les applications cloud, mais elle est loin d'être la meilleure dans tous les cas. Trop souvent, elle n'apporte tout simplement aucune valeur ajoutée.

PublicitéUn récent rapport publié par Datadog, fournisseur de services cloud de monitoring et d'observabilité, dépeint une informatique serverless plus populaire que jamais. Une analyse de l'utilisation du serverless chez les utilisateurs de Datadog établit que plus de 70 % des clients d'AWS, 60 % des clients de Google Cloud et 49 % des clients de Microsoft Azure utilisent une ou plusieurs solutions de ce type.

Rien de nouveau ici : le serverless est une tendance établie et s'inscrit dans le développement du cloud lorsqu'il s'agit de choisir la meilleure plateforme pour les applications cloud native ou opérant leur migration vers ces environnements. C'est rapide, cela ne nécessite pas une planification poussée en termes l'infrastructure (presque aucune en réalité) et les applications semblent bien fonctionner. Pas de problème donc ? Pas si vite.

La promesse du serverless consiste à réduire les tâches de gestion de l'infrastructure et à améliorer la productivité des développeurs. Mais, comme toute technologie, elle présente des inconvénients qu'il ne faut pas occulter. Or la plupart des personnes qui choisissent le serverless ne voient peut-être pas le tableau dans son ensemble. C'est peut-être votre cas.

Latence du démarrage à froid

L'une des principales préoccupations de l'informatique sans serveur réside le temps de latence de démarrage à froid. Contrairement aux modèles traditionnels de cloud computing, où les machines virtuelles ou les conteneurs sont préprovisionnés, les fonctions serverless doivent être instanciées à la demande. Bien que cela permette une mise à l'échelle dynamique, cela introduit un délai connu sous le nom de démarrage à froid. Ce facteur négatif peut avoir un impact sur le temps de réponse de l'application.

Bien que les fournisseurs aient travaillé sur ce problème, il peut demeurer préoccupant pour les applications ayant des exigences strictes en matière de performances temps réel. Quelques personnes m'ont ainsi indiqué qu'elles devaient abandonner le serverless à cause de ce facteur, ce qui va inévitablement peser sur le temps de développement pendant que l'entreprise se démène pour trouver une autre plateforme.

Vous pensez peut-être que ce problème ne concerne que les quelques applications qui exigent des performances en temps réel ? Mais ces applications sont plus nombreuses que vous ne le pensez. Il s'agit peut-être d'une exigence de l'application que vous êtes sur le point de pousser vers une plateforme serverless.

Verrouillage à un fournisseur

Aussi surprenant que cela puisse paraître, je rencontre encore des développeurs et des architectes qui croient que les applications serverless sont facilement portables d'un fournisseur de cloud à l'autre. Non, les conteneurs sont portables, mais l'informatique serverless est différente. J'ai vu 'Eviter le verrouillage par les fournisseurs' dans plus d'une présentation sur l'informatique serverless, ce qui est un peu choquant.

PublicitéChaque fournisseur de cloud possède sa propre implémentation serverless, ce qui rend difficile tout changement de fournisseur sans modifications importantes du code et de l'infrastructure. Cela peut limiter la flexibilité d'une organisation et entraver sa capacité à s'adapter à l'évolution de ses besoins ou à tirer parti d'offres concurrentes. Aujourd'hui, avec le mouvement vers les déploiements multicloud, il s'agit là d'une limitation sérieuse qui doit être prise en compte.

Débogage et monitoring

Les techniques de débogage traditionnelles, telles que la connexion à un serveur et l'inspection du code, peuvent ne pas être accessibles dans un environnement serverless. En outre, le monitoring des performances et de la santé des fonctions serverless individuelles peut s'avérer complexe, en particulier lorsqu'il s'agit de monitorer de nombreuses fonctions serverless réparties sur différents services.

Les organisations doivent investir dans des outils et techniques spécialisés pour déboguer et surveiller efficacement leurs applications serverless. Ce qu'elles finissent généralement par mieux comprendre lorsque le besoin s'en fait réellement sentir, mais à ce moment-là, cela peut entraîner des retards et des dépassements de coûts dans les projets.

Gestion des coûts

Mais le principal problème du serverless réside dans la gestion des coûts des systèmes déployés. Certes ce choix d'architecture peut permettre de réaliser des économies en éliminant la nécessité de gérer et de provisionner l'infrastructure (avantage que beaucoup de développeurs et architectes bousillent en surprovisionnant les ressources). Cependant, il est essentiel de surveiller et de contrôler efficacement les coûts, et comme les systèmes serverless allouent dynamiquement les ressources en tâche de fond, gérer directement les coûts de ces ressources cloud s'avère des plus ardus. En outre, à mesure que les applications deviennent de plus en plus complexes, le nombre de processus et de ressources associées peut augmenter, ce qui entraîne des dépassements de budget inattendus.

Les organisations devraient monitorer de près l'usage des ressources et mettre en oeuvre des stratégies de gestion des coûts pour éviter les surprises, mais la plupart d'entre elles ne le font pas, ce qui rend le serverless moins rentable. De nombreuses organisations peuvent exploiter des applications de manière plus rentable en adoptant une approche différente du serverless pour certaines applications.

Le serverless permet d'accroître la productivité des développeurs et de réduire les frais de gestion de l'infrastructure. C'est un raccourci pratique pour déployer des applications. Cependant, il est crucial de prendre en compte ses inconvénients potentiels et de prendre des décisions d'architecture en connaissance de cause. Une planification minutieuse, une conception architecturale appropriée et un monitoring efficace peuvent aider les organisations à relever ces défis et à tirer pleinement parti des avantages du serverless - ou à décider qu'il n'est pas adapté à certains de leurs besoins applicatifs.

Article rédigé par

David S. Linthicum, IDGNS (adapté par Reynald Fléchaux)

Partager cet article