Le serverless est la nouvelle coqueluche du monde du cloud : au moins une organisation sur trois (33 %) a déployé des applications serverless au cours de l’année écoulée. (Source : Enquête de DigitalOcean auprès des développeurs, 2e trimestre 2018) Parmi les personnes ayant répondu à une enquête de la CNCF réalisée en 2018, 38 % ont indiqué utiliser actuellement le serverless. Par ailleurs, 26 % prévoient d’adopter cette technologie au cours des douze prochains mois.
Cette option cloud émergente ne connaît pas seulement un essor fulgurant : elle est aussi souvent mal comprise et se voit attribuer des pouvoirs presque surnaturels, comme celui de réduire les coûts, d’accélérer la création de valeur et même de vous apporter le petit-déjeuner au lit.
Et comme si cela ne suffisait pas à semer la confusion, la fonction en tant que service (FaaS) est souvent assimilée au serverless. Or, il s’agit de deux concepts distincts, ce qui entraîne d’autres malentendus quant à la manière dont une entreprise classique pourrait tirer parti de cette formidable nouvelle technologie.
Aujourd’hui, nous allons donc déconstruire trois idées reçues que j’ai souvent entendues de la part de clients et de participants à des conférences au cours des six derniers mois. Car il est indispensable de comprendre ce qu’est cette technologie — et ce qu’elle n’est pas — avant de pouvoir déterminer s’il vaut la peine de vous y intéresser.
Commençons par clarifier la différence entre le serverless et le FaaS.
Mythe : le serverless === FaaS
Le serverless est un système. Une plateforme. Un framework. On peut le décrire au mieux comme un environnement d’exécution élastique et juste-à-temps. Le serverless vise à éliminer la charge opérationnelle et les frictions en exécutant quelque chose à la demande dans une forme d’environnement isolé. Cet environnement isolé est généralement un conteneur, mais il existe également des offres reposant sur des machines virtuelles ou WebAssembly. Par souci de concision, j’utiliserai le terme « conteneur » au sens large pour désigner ces trois technologies.
Le serverless est piloté par les événements. Cela signifie que le provisionnement et le traitement sont déclenchés par un événement, comme l’arrivée d’une requête API ou le passage de l’horloge à 14 h 07. Il peut s’agir d’un événement généré automatiquement ou d’une action interactive, comme cliquer sur un bouton d’un formulaire dans une application web. Dans un modèle serverless, l’événement déclenche l’exécution de quelque chose qui se trouve dans un « conteneur ».
REMARQUE à l’attention des équipes NETOPS : F5 iRule Les lecteurs qui connaissent bien les iRules peuvent faire le rapprochement entre les événements serverless et les événements iRule, par exemple « HTTP_REQUEST » et « HTTP_RESPONSE ». Le modèle est sensiblement le même : lorsqu’un ÉVÉNEMENT se produit, du code est exécuté. Malheureusement, la plupart des frameworks serverless ne prennent pas en charge TCL, mais ils prennent souvent en charge node.js et Python.
Le « conteneur » est souvent chargé depuis un dépôt au moment où il est sollicité (démarrage à froid), mais il peut aussi être déjà en attente (démarrage à chaud). Tout ce qui se trouve dans ce « conteneur » s’exécute et renvoie une réponse au système qui a déclenché son exécution.
Le modèle économique du serverless repose généralement sur le paiement des seules ressources consommées pendant l’exécution du « conteneur ». Le modèle opérationnel consiste à faire abstraction de tout ce qui concerne l’exploitation de l’environnement, afin que chacun puisse se concentrer sur la création de « quelque chose ».
C’est cela, le serverless. La fonction en tant que service est un usage spécifique du serverless qui définit « quelque chose » comme « une fonction ».
Le FaaS nous permet de pousser la décomposition des applications, amorcée avec les microservices, jusqu’à son aboutissement ultime : les fonctions.
Il est important de savoir qu’il existe une différence entre le serverless et la fonction en tant que service pour déconstruire notre prochain mythe.
Mythe : refactorisation nécessaire
En raison de la confusion entre le FaaS et le Serverless, de nombreux acteurs du marché pensent à tort que, pour tirer parti du Serverless, ils devront remanier leur application afin de la décomposer en fonctions.
Le Serverless ne vous oblige pas à remanier votre application ni à concevoir de nouvelles applications au niveau fonctionnel. Il peut tout aussi bien exécuter un « conteneur » comprenant n’importe quel type d’application, de processus, de démon ou de fonction. Dès lors que l’élément est empaqueté dans un « conteneur » et peut être invoqué, il peut s’exécuter dans un contexte Serverless.
J’ai également vu des mises en œuvre réussies tirer parti du Serverless pour étendre (moderniser) des architectures applicatives existantes. Le traitement par lots et asynchrone des inscriptions, de l’exécution des commandes et d’autres processus ne faisant pas partie du chemin critique peut être mis en œuvre selon un modèle Serverless sans refondre entièrement les applications traditionnelles. Les applications qui utilisent déjà des intégrations externes basées sur des API à ces fins s’adapteront plus facilement au Serverless. Les applications client-serveur établies nécessiteront presque certainement quelques modifications pour tirer parti du Serverless, mais cela ne représente pas le chantier considérable qu’exigerait une refonte complète.
Les processus qui ne s’exécutent qu’occasionnellement — en fonction d’événements spécifiques qui surviennent de manière sporadique ou imprévisible — peuvent également être bien adaptés au Serverless. Il est bien plus économique de démarrer périodiquement un « conteneur » pour exécuter une tâche que de le laisser fonctionner en permanence. Cela vaut aussi bien pour le Serverless public que sur site.
Ce qui nous amène au troisième de nos mythes, qui porte sur l’emplacement.
Mythe : le serverless ne peut pas être déployé sur site
J’ai entendu des professionnels de l’informatique de tous horizons, ainsi que des experts, avancer cette affirmation. Elle est tout aussi manifestement fausse que l’idée selon laquelle il serait impossible d’exécuter le « cloud » sur site. C’est tout à fait possible et, selon le rapport Developer Economics State of the Developer Nation, une proportion non négligeable d’organisations le font.
Les applications plus importantes et davantage sollicitées peuvent également bénéficier d’une mise à l’échelle très efficace : il suffit de payer les ressources supplémentaires nécessaires aux parties spécifiques de l’application soumises à une forte charge, qui sont par ailleurs plus faciles à identifier et à optimiser. Cet avantage pour les applications de grande envergure explique probablement en grande partie pourquoi 17 % des utilisateurs actuels de l’informatique sans serveur exécutent une solution dans leur propre centre de données.
Les gains de rentabilité d’une mise en œuvre serverless sur site vont au-delà de l’évolutivité. La possibilité de réutiliser les mêmes ressources et de les partager entre des applications utilisées de manière sporadique est loin d’être négligeable. Le serverless permet également d’ajouter des fonctionnalités à valeur ajoutée aux applications et aux fonctions opérationnelles en tirant parti de sa nature intrinsèquement événementielle. Son utilisation sur site ne doit pas être écartée à la légère sans comprendre que les avantages du serverless vont bien au-delà de la suppression des contraintes opérationnelles dans le quotidien des développeurs. C’est certes un atout, mais ce n’est ni le seul avantage ni, à l’évidence, la seule raison pour laquelle les organisations expérimentent le serverless sur site.
En réalité, le Serverless peut être déployé sur site, et c’est déjà le cas. L’enquête de la CNCF mentionnée précédemment examine les plateformes Serverless « installables » les plus populaires :
- Kubeless (42 %, contre 2 %)
- Apache OpenWhisk (25 %, contre 12 % auparavant)
- OpenFaas (20 %, contre 10 % auparavant)
Il y en a d’autres, et il y en aura certainement davantage à mesure que cette technologie gagnera du terrain.
Le serverless comme la fonction en tant que service connaissent des taux d’adoption exceptionnels, tandis que les organisations expérimentent, testent et évaluent cette technologie en vue de l’utiliser aussi bien dans de nouvelles applications cloud natives que dans le cadre de projets de modernisation. Identifier et écarter les idées reçues les plus courantes constitue une première étape importante pour déterminer si cette technologie est adaptée aux applications de votre organisation.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Pourquoi devriez-vous vous intéresser à WebAssembly ?
WebAssembly (Wasm) est un jeu d’instructions binaires portable, rapide et sécurisé, qui permet d’exécuter des applications hautes performances sur n’importe quelle plateforme.
Trois choses à savoir sur les applications d’IA
Les applications d’IA sont des applications modernes, mais elles présentent certaines particularités. Découvrez les points essentiels à connaître sur les applications basées sur l’IA.
État des lieux de la stratégie applicative 2022 : il est temps de moderniser les opérations
Il est devenu évident que, pour maintenir la dynamique de leur transformation numérique, les organisations doivent recentrer leurs efforts sur les fonctions métier. Si les expériences destinées aux clients restent prioritaires, il est également indispensable de permettre la numérisation de fonctions telles que les services juridiques, les ressources humaines et la finance. Les DSI prennent donc les commandes, tandis que la transformation numérique passe de la modernisation des applications à celle des opérations.
Clouds multiples ou multicloud : faciliter la transition
La gestion et la sécurisation des charges de travail deviennent complexes à mesure que les entreprises adoptent une stratégie de cloud connecté. Découvrez comment F5 répond au besoin d’une nouvelle approche de la mise en réseau multicloud.
L’expérience client dépend de la visibilité
Une enquête menée par Dimensional Research auprès de plus de 3 000 utilisateurs d’applications mobiles a confirmé ce que beaucoup d’entre nous pensent des attentes actuelles des clients.
Transformation numérique et explosion du portefeuille d’applications
La transformation numérique stimule la croissance des portefeuilles d’applications et modifie la manière dont celles-ci sont développées, déployées, intégrées et, en définitive, utilisées.