Le serverless ou informatique sans serveur, qu'est-ce que c'est ?

L'informatique serverless est un modèle de développement cloud-native qui permet aux développeurs de créer et d'exécuter des applications sans avoir à gérer des serveurs.

Ce modèle nécessite quand même des serveurs, mais leur gestion est dissociée du développement des applications. Un fournisseur de cloud se charge du travail de routine : il approvisionne l'infrastructure de serveurs, assure son bon fonctionnement et la met à l'échelle. Les développeurs n'ont alors plus qu'à mettre en paquet leur code dans des conteneurs pour déployer les applications.

Une fois que les applications sans serveur sont déployées, elles répondent à la demande et se mettent à l'échelle automatiquement en cas de besoin. En général, les offres sans serveur des fournisseurs de cloud public sont facturées à la demande, sur la base d'un modèle d'exécution orienté événements. Par conséquent, lorsqu'une fonction sans serveur est inactive, elle ne coûte rien.

L'informatique sans serveur se distingue des autres modèles de cloud computing, car le fournisseur de cloud est non seulement responsable de la gestion de l'infrastructure cloud, mais aussi de la mise à l'échelle des applications. Les applications sans serveur sont déployées dans des conteneurs qui démarrent automatiquement sur simple demande.

Dans un modèle standard de cloud computing IaaS (Infrastructure-as-a-Service), les utilisateurs achètent à l'avance des unités de capacité. Ainsi, ils paient un fournisseur de cloud public pour des composants de serveur actifs en permanence pour l'exécution de leurs applications. Il incombe à l'utilisateur d'augmenter la capacité du serveur pendant les périodes de forte demande et de la réduire lorsque cette capacité n'est plus nécessaire. L'infrastructure cloud reste active même lorsque l'application n'est pas utilisée.

Avec une architecture sans serveur, en revanche, les applications ne sont lancées qu'en cas de besoin. Lorsqu'un événement déclenche l'exécution d'un code d'application, le fournisseur de cloud public alloue des ressources pour ce code de manière dynamique. L'utilisateur cesse de payer une fois le code exécuté. En plus des avantages qu'il offre en matière de coûts et d'efficacité, le modèle sans serveur libère les développeurs des tâches courantes et subalternes associées à la mise à l'échelle des applications et à l'approvisionnement des serveurs.

L'informatique sans serveur permet de sous-traiter à un fournisseur de services cloud les tâches courantes telles que la gestion du système d'exploitation et du système de fichiers, l'application des correctifs de sécurité, l'équilibrage de la charge, la gestion de la capacité, la mise à l'échelle, la journalisation et la surveillance.

Il est également possible de créer une application entièrement serverless ou une application qui intègre des composants de type microservices partiellement sans serveur et partiellement traditionnels.

Dans un modèle serverless, un fournisseur de cloud exploite des serveurs physiques et alloue leurs ressources de manière dynamique pour le compte d'utilisateurs qui peuvent déployer le code directement en production.

Il existe deux types d'offres sans serveur : BaaS (Backend-as-a-Service) et FaaS (Function-as-a-Service).  

Avec une offre BaaS, les développeurs ont accès à une multitude de services et d'applications tiers. Par exemple, un fournisseur de cloud peut proposer des services d'authentification, une option de chiffrement renforcé, des bases de données accessibles dans le cloud et des données d'utilisation hautement fidèles. Avec le modèle BaaS, les fonctions sans serveur sont généralement appelées par des interfaces de programmation d'application (API).

Toutefois, lorsque les développeurs parlent d'informatique sans serveur, ils se réfèrent en général au modèle FaaS. Avec une offre FaaS, les développeurs écrivent une logique personnalisée côté serveur, mais celle-ci est exécutée dans des conteneurs entièrement gérés par un fournisseur de services cloud. 

Les principaux fournisseurs de cloud public proposent tous une ou plusieurs offres FaaS, notamment Amazon Web Services avec AWS Lambda, Microsoft Azure avec Azure Functions, Google Cloud avec plusieurs offres et IBM Cloud avec IBM Cloud Functions. 

Certaines entreprises choisissent d'exploiter leur propre environnement FaaS en recourant à des plateformes Open Source sans serveur, telles que le service Red Hat OpenShift® Serverless qui repose sur le projet Knative pour Kubernetes.

Le FaaS est un modèle d'exécution orienté événements. Les développeurs écrivent une logique qui est déployée dans des conteneurs entièrement gérés par une plateforme, et qui sera ensuite exécutée à la demande.

Contrairement au BaaS, le modèle FaaS offre un plus grand degré de contrôle aux développeurs qui peuvent créer des applications personnalisées plutôt que d'avoir recours à une bibliothèque de services prérédigés. 

Le code est déployé dans des conteneurs gérés par un fournisseur de cloud. Ces conteneurs sont :

• sans état, ce qui simplifie l'intégration des données ;
• éphémères, ce qui permet de les exécuter pendant une très courte période ;
• déclenchés par un événement, ce qui leur permet de s'exécuter automatiquement en cas de besoin ;
• entièrement gérés par un fournisseur de cloud, de sorte que l'utilisateur paie uniquement pour les ressources dont il a besoin, et non pour des applications et serveurs toujours disponibles.

Avec le modèle FaaS, les développeurs peuvent appeler des applications sans serveur via des API gérées par le fournisseur de FaaS par l'intermédiaire d'une passerelle d'API.

L'architecture serverless est idéale pour les applications asynchrones et stateless qui peuvent être lancées instantanément. Ce modèle est également adapté pour faire face aux pics de demande peu fréquents et imprévisibles.

Le traitement par lots de fichiers image entrants est un bon exemple. Même si cette tâche ne survient qu'occasionnellement, il faut être prêt lorsqu'un grand lot d'images arrive en une seule fois. Une autre tâche pourrait être la surveillance des modifications apportées à une base de données et l'application d'une série de fonctions, pour vérifier le respect des normes de qualité ou traduire automatiquement les données.

En outre, les applications sans serveur conviennent bien aux cas d'utilisation basés sur des flux de données entrants, des chat bots, des tâches programmées ou une logique métier.

Autres cas fréquents d'utilisation de l'informatique sans serveur : les API back-end et les applications web, l'automatisation des processus métier, les sites web sans serveur et l'intégration à plusieurs systèmes.

La plateforme d'orchestration de conteneurs Kubernetes permet d'exécuter des applications conteneurisées sur une infrastructure automatisée. Son choix est donc prisé pour l'exécution des environnements sans serveur. Toutefois, utilisée seule, cette plateforme n'est pas capable d'exécuter nativement des applications sans serveur.

Knative est un projet de la communauté Open Source qui ajoute des composants pour le déploiement, l'exécution et la gestion des applications sans serveur sur Kubernetes.

L'environnement sans serveur Knative vous permet de déployer du code sur une plateforme Kubernetes comme Red Hat OpenShift. Avec Knative, vous créez un service en mettant votre code en paquet sous la forme d'une image de conteneur pour le déposer dans le système. Knative s'occupe de démarrer et d'arrêter les instances automatiquement. Ainsi, votre code est exécuté uniquement lorsque c'est nécessaire.

Knative inclut trois composants principaux :

• Build : met en place une approche flexible du développement de code source en conteneurs.
• Serving : permet le déploiement rapide et la mise à l'échelle automatique des conteneurs à l'aide d'un modèle basé sur les requêtes pour servir les charges de travail à la demande.
• Eventing : infrastructure qui permet la consommation et la production d'événements afin de stimuler les applications. Les applications peuvent être déclenchées par différentes sources telles que des événements issus de vos propres applications, des services cloud de nombreux fournisseurs, des systèmes SaaS (Software-as-a-Service) et des flux Red Hat AMQ.

Contrairement aux anciennes structures sans serveur, Knative a été conçu pour déployer n'importe quelle charge de travail des applications modernes, des applications monolithiques aux microservices et aux fonctions minuscules.

Knative peut se substituer à une solution FaaS contrôlée par un seul fournisseur de services et fonctionner sur n'importe quelle plateforme de cloud qui exécute Kubernetes, y compris dans un datacenter sur site. Cela apporte plus de flexibilité et d'agilité pour l'exécution des charges de travail sans serveur.

Avantages

• L'informatique sans serveur permet d'améliorer la productivité des développeurs et de réduire les coûts d'exploitation. Parce qu'ils ne se chargent plus des tâches courantes d'approvisionnement et de gestion des serveurs, les développeurs ont plus de temps à consacrer à leurs applications. 
• L'informatique sans serveur encourage l'adoption des pratiques DevOps en évitant aux développeurs de décrire explicitement l'infrastructure que l'équipe d'exploitation doit leur fournir.  
• Il est possible de rationaliser davantage le développement des applications en intégrant des composants entiers qui proviennent d'offres BaaS de tiers.
• En outre, les coûts d'exploitation sont réduits dans un modèle sans serveur, car vous payez uniquement pour le temps de calcul basé dans le cloud selon vos besoins, et n'avez pas besoin d'exécuter ni de gérer en continu vos propres serveurs.

Inconvénients

• Le fait de ne pas utiliser votre propre serveur ou de ne pas contrôler votre propre logique côté serveur peut présenter des inconvénients.
• Les fournisseurs de cloud peuvent appliquer des contraintes rigoureuses aux interactions avec leurs composants, ce qui affecte la flexibilité et le niveau de personnalisation de vos propres systèmes. Dans le cas des environnements BaaS, les développeurs risquent de dépendre de services dont le code est hors de leur contrôle.
• Si vous cédez le contrôle de ces aspects de la pile, vous vous exposez également à la dépendance vis-à-vis d'un fournisseur. Et si vous décidez de changer de fournisseur, vous devrez probablement payer la mise à niveau de vos systèmes pour qu'ils soient conformes aux spécifications du nouveau fournisseur.

Les concepts d'architecture serverless et de FaaS se sont développés dans le sillage des conteneurs et des offres de cloud à la demande. Un rapport de 451 Research, rédigé en collaboration avec Red Hat, retrace l'évolution de l'informatique sans serveur en trois phases.

La phase « 1.0 » comportait des limites, ce qui rendait le modèle imparfait pour l'informatique générale. Les caractéristiques de l'informatique sans serveur 1.0 sont les suivantes :

• Sources restreintes (HTTP et quelques autres)
• Fonctions uniquement
• Temps d'exécution limité (5-10 minutes)
• Pas d'orchestration
• Expérience de développement local limitée

L'avènement de Kubernetes a inauguré l'ère de l'informatique sans serveur 1.5. De nombreuses structures sans serveur ont commencé à mettre automatiquement à l'échelle des conteneurs. Les caractéristiques de l'informatique sans serveur 1.5 sont les suivantes :

• Knative
• Mise à l'échelle automatique basée sur Kubernetes
• Microservices et fonctions
• Débogage et tests en local facilités
• Polyglotte et portable

Aujourd'hui, l'ère de l'informatique sans serveur 2.0 s'ouvre avec l'arrivée de l'intégration et des états. Les fournisseurs ont commencé à ajouter les pièces manquantes pour adapter l'informatique sans serveur aux charges de travail généralistes des entreprises. Les caractéristiques de l'informatique sans serveur 2.0 sont les suivantes :

• Traitement de base de l'état
• Modèles d'intégration d'entreprise
• Capacités de messagerie avancées
• Fusion avec le PaaS de l'entreprise
• Sources d'événements adaptées aux entreprises
• État et intégration