Les évolutions du SI (4) : le serverless fait abstraction des serveurs…

Je me suis précédemment penché sur les évolutions du SI qui ont mené des monolithes aux services et à la tendance actuelle des microservices. Si on fait un peu de prospective, il faut aussi s’intéresser à la notion de serverless et à son intérêt pour les fonctions « Métier » de l’entreprise.

Etape 4 : n’oubliez pas le cloud !

Puisque je parle d’évolutions dans l’IT, je ne peux pas ne pas mentionner le Cloud.

Même si je m’intéresse ici plus aux applications, qu’à l’infrastructure sous-jacente, le cloud change la donne.

La proposition de valeur du Cloud, c’est globalement de ne pas avoir à (trop) se soucier de l’infrastructure. Selon le bon vieil adage « loin des yeux, loin du cœur », les entreprises placent leur infrastructure IT dans le Cloud afin de moins s’en occuper et de faire des économies substantielles.

D’abord parce que l’infra est mutualisée entre plusieurs clients. Elle me coûte marginalement moins cher que si j’avais la même quote-part d’infra chez moi. Ensuite parce qu’elle est plus souple. Si j’ai besoin de plus de puissance, mon prestataire ré-alloue une partie de la capacité qu’il a déjà à sa disposition. Cela m’évite de commander à un fournisseur un serveur qu’il me faudra installer. Avant, cela prenait au mieux des jours, au pire des mois d’avoir plus de puissance; avec le cloud, cela devient quasi-instantané. Enfin, parce qu’une partie des tâches sont faites par le prestataire de façon automatique et plus économique (ex. installation, backup, ré-allocations,…).

Seulement, au niveau de la conception des applications, jusqu’à présent, le cloud n’a pas non plus bouleversé fondamentalement les choses. L’influence du cloud réside surtout dans le fait que les applications sont maintenant « conteneurisées » et qu’on les déploie sur des serveurs physiques ou virtuels, chez soi ou sur le cloud. Certes la notion de microservices a beaucoup de sens dans un contexte cloud, mais la promesse du cloud n’est pas pleinement atteinte pour l’instant: il faut encore s’occuper de l’infrastructure.

Le serverless, qu’est ce que c’est?

A partir de là, apparaît la notion de « serverless ». L’idée du serverless, contrairement à ce que le terme pourrait laisser entendre n’est pas de supprimer un serveur. L’idée est tout simplement de laisser le prestataire cloud gérer à 100% les ressources du serveur. Et dans ce cas-là… la promesse du cloud serait véritablement atteinte: plus besoin de s’occuper de l’infrastructure!

Dans une approche serverless, le développeur conçoit et met en oeuvre une application et la déploie sur son environnement cloud. Le prestataire cloud gère alors de façon automatisée et dynamique les ressources qui vont être alloués aux diverses fonctionnalités et microservices.

Je n’ai plus besoin de planifier, le prestataire garantit qu’il répondra à la demande.

Le Serverless a de nombreux avantages…

Globalement l’approche serverless s’inscrit dans une démarche continue de modularité et de souplesse de l’IT. On va donc comme toujours pouvoir déployer plus vite. On allait déjà plus vite en découpant l’application en microservices. Maintenant, vu que je m’occupe moins des préoccupations d’infrastructure, donc je vais plus vite.

L’autre avantage évident est qu’on a normalement une meilleure performance et une plus grande disponibilité. Et pour cause, c’est le prestataire qui s’en occupe et moi, je n’en porte plus la responsabilité!

Par ailleurs, cela joue sur les coûts. Puisque les ressources allouées sont toujours en ligne avec l’utilisation, je ne paye jamais de ressource que je n’utilise pas ! Personnellement, je me dis que cela présente aussi un intérêt environnemental, puisqu’on a théoriquement moins de gâchis. L’efficience est aujourd’hui une priorité. On manque toutefois encore trop de recul sur le serverless pour évaluer sa performance écologique.

Enfin, toujours sur les coûts, les fournisseurs de Serverless (ex.  Firebase de Google, Amazon et Microsoft) facturent à l’usage… Là encore, on ne paye que ce qu’on consomme. On variabilise donc un coût qui serait fixe en temps normal (le coût d’un serveur acheté ou loué).

… et quelques inconvénients!

La tendance du serverless est encore trop récente pour n’avoir que des avantages !

Les coûts variables, c’est bien, mais il faut les surveiller pour éviter qu’ils ne s’envolent. En tout cas, cela peut amener à revoir son pricing model. Il ne faut surtout pas que le métier se retrouve avec un prix de vente fixe et des coûts qui, eux, explosent parce qu’ils sont variables !

Une autre limite actuelle au serverless, c’est que pour profiter pleinement de l’infrastructure cloud, il faut tout de même adapter son code à la plateforme Cloud cible et utiliser des fonctions mises à disposition par le prestataire. Autrement dit, votre code Serverless pour Amazon sera légèrement différent de celui pour Microsoft ou Google. Cela créé donc une adhérence et limitera peut-être la possibilité de changer de prestataire dans la durée. Bien sûr des petits malins viendront proposer une couche d’abstraction qui permettra d’être agnostique par rapport au Cloud cible. Les premiers frameworks ont fait leur apparition.

Enfin, dernière précision. On présente parfois le serverless comme la fin du DevOps. C’est une erreur. En effet, les mécaniques d’intégration et de déploiement continus restent d’actualité. Et il faut que pendant le DEV on intègre les contraintes OPS (cf. le point sur l’adhérence ci-dessus). Ça ne rend donc pas le DevOps obsolète. Au mieux, ce que cela simplifie, c’est la partie OPS. Mais, c’est déjà beaucoup !

En tout cas, c’est la promesse du serverless… qu’il faudra suivre de près dans les prochaines années. Il faudra notamment voir quels sont les langages et les outils les plus adaptés à cette nouvelle tendance !

Découvrez l’interview de Jérémy Amourous, DSI de Colissimo, qui explique les nombreux bénéfices de la mise en place d’une Architecture Réactive en temps réel.

(Merci à Wilmer pour ses inputs sur cet article!)