BLOG

Le Serverless ne concerne pas les serveurs, mais les applications

Miniature de Lori MacVittie
Lori MacVittie
Publié le 12 juin 2017

Il existe une grande confusion autour du concept de « informatique sans serveur ». Cela pourrait être dû au fait que son nom est tout à fait erroné. Il ne s’agit ni de serveurs ni d’informatique. Du moins pas au sens traditionnel du terme dans lequel la plupart des professionnels de l’informatique l’utilisent.

Il est préférable d'appeler Serverless Functions as a Service (FaaS) car c'est ce qu'il offre. De la même manière que le FaaS est sans serveur, le SaaS l’est aussi, et, pourrait-on raisonnablement en conclure, le PaaS. C’est parce que le serveur – le calcul – est retiré de l’équation du point de vue de son consommateur, qui est généralement un développeur. Les ressources de calcul (serveur, réseau) sont cachées sous les couvertures, automatiquement provisionnées, gérées et mises à l'échelle via un réseau d'automatisation et d'orchestration finalement régi par le fournisseur du service. Vous payez pour cela, mais vous n’aurez jamais à le voir.

Le FaaS sans serveur ne remplace pas le SaaS, ni le PaaS, ni le cloud en général. Il s’agit d’une autre option superposée aux modèles existants qui offre aux développeurs la possibilité intéressante d’invoquer des fonctions à la demande. Il est piloté par événement, ce qui signifie que la fonction est déclenchée par un événement. Cet événement est souvent l'invocation d'un appel d'API, qui prend la forme d'une requête HTTP avec un URI très spécifique. Oui, un appel d'API.

Le cas d’utilisation le plus souvent cité pour FaaS est le traitement d’images ou de vidéos. Cela est dû au fait que les ressources requises sont souvent imprévisibles, mais en termes de fréquence et de capacité. FaaS fournit un moyen abordable et efficace de traiter ces médias appel par appel. Un autre exemple pourrait être lié à l’espace IoT, où les actions sont déclenchées par des événements qui se produisent soit via une application de contrôleur, soit à partir de l’objet lui-même. Et il y a toujours le cas d’utilisation du backend de l’API , qui a souvent plus de sens pour la plupart des gens que tout autre cas d’utilisation, car les API sont souvent décrites comme des URI invoquant des fonctions.  Quelle que soit l'action de la fonction, elle s'exécute uniquement lorsqu'elle est déclenchée par un événement spécifique et est censée être une fonction unique et isolée.

décomposition d'application

Ce n’est pas un nuage comme nous avons l’habitude de le voir ou d’en discuter. C'est parce que le cloud (IaaS) concerne l'infrastructure et les opérations, tandis que le FaaS (et le PaaS et le SaaS) concernent les applications. Ils sont conçus comme un environnement de développement dans lequel les développeurs peuvent implémenter du code pour effectuer certaines tâches dans le cadre d'une initiative application plus vaste. Pouvez-vous créer une application à partir de plusieurs implémentations FaaS ? Absolument. En effet, à cet égard, le FaaS est au SaaS ce que les microservices sont aux monolithes.

Mais c’est précisément là le problème. FaaS concerne les applications, pas les serveurs. Vous ne pouvez pas implémenter un cloud avec FaaS, mais vous pouvez développer une application. Vous ne pouvez pas déplacer une application vers un environnement « sans serveur ». Il doit être déconstruit puis reconstruit, voire réarchitecturé comme une collection de FaaS.

Les combinaisons (ou s'agit-il de permutations ?) sont nombreuses. On peut intégrer FaaS avec PaaS à partir d’une application déployée dans IaaS. L'IaaS et le PaaS peuvent être sur site, tandis que le FaaS est public.

Le problème avec SaaS, PaaS et FaaS, c'est que vous ne voyez jamais les « serveurs ». Ce n’est pas vrai dans l’IaaS, où nous appelons les serveurs des « instances » et sommes tenus de les gérer et de les entretenir. C’est parce que l’IaaS – qu’il soit sur site ou public – concerne la fourniture d’infrastructures et d’opérations, et non applications. Cela a toujours été vrai, mais nous avons pu l'ignorer au cours de la dernière décennie parce que « serveur == application» a été la norme pendant si longtemps.

Mais avec l'essor des microservices et des API, et maintenant du FaaS, nous ne pouvons plus fonctionner dans un mode où « serveur == application», car ce n'est tout simplement plus vrai.

En fin de compte, FaaS ne concerne pas les serveurs, ni même réellement le cloud (au sens où nous l’entendons). Mais il s’agit d’un changement significatif dans la manière dont nous pourrions concevoir et développer des applications.