separateur

Le Serverless

Des services dynamiquement et instantanément évolutifs

Le Serverless, présentée comme l’une des évolutions du cloud, cette solution permet aux développeurs de ne plus être contraints par la gestion des serveurs y compris virtuels. Ils disposent ainsi d’une plateforme « scalable » et adaptée à leurs besoins particuliers.

Encore une fois, les Anglo-saxons auraient-ils de l’avance sur nous ? Alors que l’informatique Severless est largement abordée et traitée aux États-Unis depuis quelques années (l’offre d’Amazon remonte à fin 2014), elle reste méconnue dans l’hexagone.

Une forte majorité (79 %) des lecteurs du site zdnet.fr affirment tout ignorer de ce concept ! Certes, ce sondage n’est pas très « scientifique », mais il s’appuie néanmoins sur près de 440 réponses.

Commençons par répondre à cette fameuse question : qu’est-ce qu’une architecture sans serveur ? Contrairement à ce que laisse à penser le terme de « Serverless », les serveurs ne disparaissent pas par magie. Ils sont toujours présents ! La différence intervient au niveau de leur implémentation et de leur gestion.

Comme chacun sait, des serveurs traditionnels s’appuient sur des ressources fixes, s’exécutent tout le temps et ont besoin d’administrateurs. Brefs, ils sont chronophages et pas vraiment rentables.

et maintenant le… FaaS

Avec l’informatique Serverless, ils sont exécutés dans des instances de calcul pilotées par les événements et en fonction de la demande ou des besoins particuliers des entreprises.

Le Serverless peut, par exemple, répondre aux exigences de sites de e-commerce dont le trafic peut augmenter fortement lors de certains événements comme les soldes ou le Black Friday. 

Les services sont dynamiquement et instantanément évolutifs. L’idéal aussi pour le développement de modules microservices.

D’où l’apparition de l’acronyme FaaS (Functions as a Service). Votre facture dépend de vos recours à des « fonctions ». Logiquement, les services FaaS les plus connus s’appellent Amazon Web Service Lambda (mais qui a aussi une version « sans serveur » de sa base de données relationnelle éponyme appelée Aurora Serveless depuis fin 2017 et Fargate, une solution pour containers), Microsoft Azure Functions, Google Cloud Functions, IBM Bluemix OpenWhisk ou encore les microservices de hook.io.

Les avantages du Serverless

 Le premier atout pour les développeurs est évident : ils n’ont plus à se soucier de configurer et d’ajuster les serveurs virtuels sur lesquels tournent les microservices et fonctions composant leurs applications.

Ils peuvent mieux se concentrer sur les fonctionnalités et le code de leur application. Ce sont les systèmes du prestataire qui s’occupent de gérer les ressources requises par la fonction. Cela signifie donc que lorsque la demande est servie, l’état est automatiquement arrêté.

Mais certains fournisseurs présentent un autre avantage. Même si le cloud évite d’investir massivement dans l’infrastructure, il n’est pas rare que des machines virtuelles continuent à être opérationnelles sans être « productives »… Sans parler des systèmes de fichiers Amazon Elastic Block Storage (EBS) inutilisés.

Selon une étude de Cloudyn (un éditeur d’origine israélienne spécialisé dans la gestion des coûts des services cloud et racheté en juillet 2017 par Microsoft) de nombreuses instances de machines virtuelles tournent à une charge inférieure à 20 %.

Pour éviter dans arriver à cette aberration, AWS Lambda permet par exemple l’exécution du code qu’en cas de besoin. Il est déclenché par un événement qui représente une demande de calcul.

Par exemple, le tarif du service Lambda d’Amazon est basé sur 100 millisecondes, alors que les tarifs pour une VM se calculent en général en heures ou en minutes.

Enfin, dans le cas de FaaS, des fonctions peuvent être exécutées parmi d’autres fonctions dans un pool de ressources partagées. La mise à l’échelle est assurée de façon automatique.

Cela peut représenter un point déterminant lorsqu’on hésite entre le FaaS et le PaaS. Ce dernier oblige à devoir estimer la quantité de ressources nécessaires. D’où des risques de surestimer ou sous-estimer le besoin réel.

Les limites du Serverless

Tout n’est pas parfait. Le principal souci est la multiplication des fournisseurs qui ont des implémentations différentes de leurs architectures sans serveur. Porter son code d’un fournisseur à l’autre peut parfois s’avérer coûteux.

Autre zone d’ombre, la confidentialité d’informations sensibles. « Pour le Serverless, la gestion des flux transfrontières de données, donc de leur localisation est cruciale, car exclusivement sous la responsabilité du prestataire.

Dans la mesure où le prestataire Serverless est seul décisionnaire des moyens alloués au traitement, il y aurait légitimement une réflexion à mener sur la qualification de responsable conjoint du traitement », explique Éric Le Quellenec, de Lexing Alain Bensoussan Avocats.

 Trois clauses doivent être traitées dans ce type de contrat :

  • Les garanties de scalabilité et d’évolutivité, mais aussi de performance et de disponibilité ;
  • La collaboration avec le partenaire : elle doit être encadrée et explicite ;
  • La clause prix : cette métrique doit être très claire et précise (par exemple, un code qui se lance toutes les 15 minutes pour nettoyer une table de base de données en fonction d’une logique métier personnalisée). En s’appuyant sur un outil de supervision facilement accessible, le client doit pouvoir, en temps réel, vérifier ce qui est consommé.

Ces solutions sont bien adaptées aux applications web, backend mobiles (authentification, requête BD, call API) et IOT. Mais là aussi, il convient de ne pas se précipiter. Car si le code est mal fait, la facture pourrait être plus salée qu’avec une architecture traditionnelle…

Ensemble sécurisons vos données

Dans la même catégorie