Trois croyances courantes sur le Serverless que vous pouvez ignorer

Serverless est le chouchou montant du monde du cloud . Au moins une organisation sur trois (33 %) a déployé des applications sans serveur au cours de l’année dernière. (Source: Enquête auprès des développeurs du deuxième trimestre 2018 de Digital Ocean ) Parmi les personnes ayant répondu à une enquête CNCF 2018 , 38 % ont indiqué utiliser le sans serveur aujourd'hui. 26 % supplémentaires prévoient d’utiliser cette technologie au cours des douze prochains mois.

Cette option cloud naissante ne se développe pas seulement rapidement, elle est souvent mal comprise et on lui attribue des pouvoirs presque surnaturels pour réduire les coûts, accélérer le délai de rentabilisation et vous préparer le petit-déjeuner au lit. 

Et si cela ne suffisait pas à vous embrouiller, il y a la confusion entre Function as a Service (FaaS) et Serverless. Les deux ne sont pas identiques, ce qui entraîne d’autres malentendus sur la manière dont une entreprise typique pourrait tirer parti de cette nouvelle technologie fabuleuse.

Aujourd’hui, nous allons donc briser trois mythes courants que j’ai entendus à plusieurs reprises de la part de mes clients et des participants à des conférences au cours des six derniers mois. Parce qu'il est nécessaire de comprendre ce qu'est la technologie - et ce qu'elle n'est pas - avant de pouvoir déterminer si cela vaut la peine de consacrer du temps à l'explorer.

Commençons par clarifier la différence entre serverless et FaaS. 

Mythe: Sans serveur === FaaS

Serverless est un système. Une plateforme. Un cadre. Il s’agit en fait d’un environnement d’exécution élastique et juste à temps. Serverless cherche à éliminer les frais généraux et les frictions opérationnelles en exécutant quelque chose à la demande dans une sorte d'environnement isolé. Cet environnement isolé est généralement un conteneur, mais des offres utilisant des machines virtuelles et Web Assembly existent également. Par souci de concision, j'utiliserai le terme « conteneur » pour désigner les trois de manière générale.

Serverless est piloté par les événements . Cela signifie que l'approvisionnement et le traitement sont initiés par une sorte de déclencheur, comme l'arrivée d'une demande d'API ou l'horloge indiquant 14h07. Il peut s'agir d'un événement généré automatiquement ou d'un événement interactif, comme appuyer sur un bouton d'un formulaire dans une application Web. Dans un modèle sans serveur, l'événement déclenche l'exécution de quelque chose qui existe dans un « conteneur » . 

Le « conteneur » est souvent chargé à partir d'un référentiel au moment où il est demandé (démarrage à froid) ou peut déjà être en attente (démarrage à chaud). Tout ce qui existe 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 uniquement des ressources consommées pendant l’exécution du « conteneur ». Le modèle opérationnel vise à éliminer toute gestion de l’environnement pour vous permettre de vous concentrer sur la création.

C'est sans serveur. Function as a Service est une utilisation spécifique de serverless qui définit « quelque chose » comme « une fonction ». 

FaaS nous permet de mener à bien la décomposition des applications qui a commencé avec les microservices : les fonctions.

Savoir qu’il existe une différence entre Serverless et Function as a Service est important pour démystifier notre prochain mythe.

Mythe: Refactorisation requise 

En raison de la confusion entre FaaS et Serverless, de nombreux acteurs du marché ont l’impression erronée que pour profiter de Serverless, vous devrez refactoriser votre application dans ses fonctions composites.

Serverless ne nécessite pas de refactoriser votre application ni de concevoir de nouvelles applications à un niveau fonctionnel. Serverless peut tout aussi facilement exécuter un « conteneur » avec n’importe quel type d’application, de processus, de démon ou de fonction. Tant qu'il est empaqueté dans un « conteneur » et peut être invoqué, il peut s'exécuter dans un contexte sans serveur.

J'ai également vu des implémentations réussies qui tirent parti de Serverless pour étendre (moderniser) les architectures d'application existantes. Le traitement par lots et hors bande des inscriptions, de l'exécution des commandes et d'autres processus non critiques peut être implémenté dans un modèle sans serveur sans refactoriser complètement les applications traditionnelles. Les applications qui tirent déjà parti d'une intégration externe basée sur des API à de telles fins trouveront Serverless plus facile à utiliser. Les applications client-serveur établies nécessiteront presque certainement quelques modifications pour tirer parti de Serverless, mais ce n'est pas l'entreprise de grande envergure qu'exigerait une refactorisation complète. 

Les processus qui ne s'exécutent qu'occasionnellement, en fonction d'événements spécifiques qui se produisent de manière sporadique ou imprévisible, peuvent également être adaptés à Serverless. Il est bien plus rentable de lancer un « conteneur » de manière périodique pour exécuter quelque chose que de laisser ce « conteneur » fonctionner en permanence. Cela est vrai à la fois pour les serveurs publics et locaux sans serveur.

Ce qui nous amène au troisième de nos mythes, qui se concentre sur la localisation.

Mythe: Le sans serveur ne vit pas sur site

J'ai entendu des professionnels de l'informatique de partout ainsi que des experts faire cette affirmation. C’est tout aussi manifestement faux que l’idée selon laquelle il serait impossible d’exécuter un « cloud » sur site. Vous le pouvez certainement et selon Developer Economics State of the Developer Nation , un pourcentage important d'organisations le font.

Les applications plus volumineuses et plus sollicitées tirent aussi parti d'une mise à l'échelle très efficace, en ne payant des ressources supplémentaires que pour les parties spécifiques sous forte charge, ce qui permet également de mieux les identifier et optimiser. Cet avantage pour les applications importantes explique sans doute pourquoi 17 % des utilisateurs actuels du serverless exécutent une solution dans leur propre centre de données.

Les gains d’efficacité des coûts dans une mise en œuvre serverless sur site dépassent la simple évolutivité. La possibilité de réutiliser les mêmes ressources et de les partager entre des applications à usage sporadique est loin d’être négligeable. Serverless vous permet aussi d’enrichir les applications et les fonctions opérationnelles en tirant parti de sa nature intrinsèquement événementielle. N’écartez pas son usage sur site sans réaliser que ses bénéfices vont bien au-delà d’une réduction des frictions opérationnelles rencontrées par les développeurs au quotidien. C’est clairement un avantage, mais pas le seul, ni la seule raison qui pousse les organisations à expérimenter Serverless sur site.  

La réalité est donc que Serverless peut être et est mis en œuvre sur site. L'enquête CNCF susmentionnée examine les plates-formes sans serveur « installables » les plus populaires :

• Kubeless (42% contre 2%)
• Apache OpenWhisk (25 % de plus que 12 %)
• OpenFaas (20% contre 10%)

Il y en a d’autres, et il y en aura certainement d’autres à mesure que cette technologie prendra de la vitesse.

Les technologies sans serveur et Function as a Service bénéficient de taux d'adoption incroyables à mesure que les organisations bricolent, testent et évaluent la technologie pour l'utiliser à la fois dans de nouvelles applications cloud natives et dans les efforts de modernisation. Reconnaître et ignorer les idées fausses courantes constitue une première étape importante pour décider si la technologie convient aux applications de votre organisation.