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 derrière le serverless est généralement basé sur le paiement uniquement des ressources consommées pendant l'exécution du « conteneur ». Le modèle opérationnel consiste à supprimer tout ce qui concerne l'exploitation de l'environnement et à laisser les gens se soucier de construire « quelque chose ».

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 grandes et plus utilisées peuvent également bénéficier d'une mise à l'échelle très efficace, n'ayant besoin de payer que des ressources supplémentaires pour les parties spécifiques de l'application soumises à une charge importante, et étant également plus facilement capables d'identifier et d'optimiser celles-ci. Cet avantage pour les applications plus volumineuses est probablement l’une des principales raisons pour lesquelles nous constatons que 17 % des adoptants actuels de l’informatique sans serveur exécutent une solution dans leur propre centre de données.

Les gains d’efficacité des coûts dans une implémentation sans serveur sur site vont au-delà de l’évolutivité. La capacité de réutiliser les mêmes ressources et de les partager entre des applications pour lesquelles l’utilisation est sporadique n’est pas négligeable. Serverless ajoute également la possibilité d'ajouter des fonctionnalités à valeur ajoutée aux applications et aux fonctions opérationnelles en tirant parti de sa nature principale, axée sur les événements. Son utilisation sur site ne doit pas être écartée à la légère sans comprendre que les avantages du sans serveur vont bien au-delà de l'élimination des frictions opérationnelles de la vie quotidienne des développeurs. C’est certainement une aubaine, mais ce n’est pas le seul avantage et ce n’est certainement pas la seule raison pour laquelle les organisations expérimentent le 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.