Qu’est-ce que l’informatique serverless ?

L’informatique serverless ou sans serveur permet aux développeurs et aux ingénieurs de ne plus avoir à se soucier du provisioning et de la gestion de l’infrastructure. Sans l’informatique serverless, voici à quoi ressemble un cycle de vie typique de développement, de déploiement et de gestion de logiciels :

1. Les développeurs écrivent le code source.

2. L’équipe Opérations évalue les exigences de performance et d’évolutivité de l’application et prépare une proposition de plan d’infrastructure.

3. Le plan est partagé avec le fournisseur de services Cloud et un nombre spécifique de serveurs est acheté.

4. L’application fonctionne sans problème pendant une semaine, avant de planter en raison d’une utilisation de mémoire intensive.

5. Les développeurs et les ingénieurs Opérations corrigent le problème et finissent par acheter quelques serveurs supplémentaires pour répartir la charge.

6. D’autres problèmes surviennent par intermittence et les développeurs passent la moitié de leurs journées de travail à déboguer l’infrastructure.

7. L’équipe Opérations est soumise à une pression constante de la part du service financier en raison de l’augmentation des coûts du Cloud, ce qui l’oblige à rechercher en permanence des pistes d’optimisation.

Avec l’informatique serverless, le travail des développeurs s’arrête à l’étape 1. Le fournisseur de Cloud alloue, gère et fait évoluer automatiquement l’infrastructure nécessaire à l’exécution de l’application. Il n’est pas nécessaire de planifier l’infrastructure, ni de surveiller les contrôles de l’intégrité des serveurs, ni même de s’inquiéter d’une surfacturation. Étant donné que le fournisseur de Cloud ajoute ou retire automatiquement des ressources en fonction de la demande des applications, vous n’êtes facturé que pour ce que vous utilisez. Rien de plus, rien de moins.

Une chose importante à retenir ici est que « serverless » ne signifie pas que les serveurs ne sont pas utilisés. Car ils le sont, mais les tâches habituelles associées aux serveurs, comme la planification, la gestion et l’évolutivité de l’infrastructure, sont cachées aux développeurs.

Dans un environnement sans serveur, une fois qu’un développeur a fini de mettre en œuvre la logique métier, il peut s’attendre à ce que le fournisseur de Cloud s’occupe du reste. Le fournisseur de Cloud peut exécuter son application dans une machine virtuelle ou un conteneur, le développeur n’a pas besoin de le savoir ou de s’en préoccuper. L’essentiel est que l’application fonctionne, en utilisant les ressources minimales et en s’adaptant si nécessaire.

La Fonction en tant que service (FaaS) est la manière sans serveur de construire des applications de microservices. Avec la FaaS, les développeurs peuvent écrire du code à la volée, qui peut être exécuté à la réception de certains événements, par exemple lorsqu’un utilisateur clique sur un bouton dans une application Web, ou lorsqu’un nouveau message est reçu dans une file d’attente de messages, ou lorsque quelqu’un envoie une requête à votre serveur HTTP.

L’architecture de microservices est une approche de mise en œuvre qui permet aux développeurs de répartir leur logique d’entreprise sur plusieurs services faiblement couplés. Cela présente plusieurs avantages :

• Les petits services sont beaucoup plus faciles à tester et à entretenir.

• La logique d’entreprise répartie entre plusieurs services permet d’éviter un point de défaillance unique.

• Déploiement plus rapide.

Vous pouvez considérer la FaaS comme un sous-ensemble du serverless. Le serverless couvre généralement toutes les catégories de services telles que le calcul, les bases de données, les passerelles API et le stockage, etc. en retirant les tâches de planification, gestion et facturation aux développeurs. La FaaS, quant à elle, se concentre uniquement sur l’informatique événementielle, où les développeurs peuvent déclencher le code de l’application en fonction d’événements. Un autre avantage important de la FaaS est qu’il n’est pas nécessaire d’utiliser un seul langage de programmation ou un seul cadre pour construire votre application. Vous pouvez écrire vos fonctions logiques dans n’importe quel nombre de langages ou de cadres différents. Prenons un exemple.

Dans votre environnement Cloud, vous avez connecté votre file d’attente de messagerie à une fonction. Chaque fois qu’un message est reçu dans la file d’attente (événement), la fonction appelle votre API REST, qui exécute alors votre logique métier. De même, vous pouvez écrire d’autres fonctions pour connecter votre service d’authentification à votre base de données, et votre fournisseur de courrier électronique à d’autres parties de votre système.

Le serverless et la Plateforme en tant que service sont similaires dans le sens où ils gardent tous deux l’infrastructure invisible pour les développeurs, qui n’ont qu’à se préoccuper de l’écriture du code. Cependant, il existe plusieurs différences entre les deux.

• Dans le cas de la PaaS, les applications doivent être configurées manuellement pour évoluer. D’autre part, le serverless fait automatiquement évoluer les applications en fonction des besoins.

• Pour les applications sans serveur, le code s’exécute de manière agile, et uniquement lorsqu’il est invoqué. Par exemple, une application/fonction serverless peut s’arrêter complètement lorsqu’il n’y a pas d’activité, puis redémarrer (en quelques millisecondes) pour répondre à un événement. Les applications PaaS ne peuvent pas évoluer à la hausse ou à la baisse à une telle vitesse.

• Avec la PaaS, vous avez davantage de contrôle sur votre infrastructure et vos déploiements. Cependant, le serverless permet de faire abstraction de presque tout.

La plupart des applications logicielles ont un frontend et un backend. Le frontend comprend généralement l’interface orientée vers l’utilisateur, ainsi que la logique côté client. Par exemple, le frontend d’une application Web est ce que vous voyez dans votre navigateur. Le backend comprend tout ce qui se passe en coulisses. Lorsque vous vous connectez, votre nom d’utilisateur et votre mot de passe sont reçus par le frontend, mais ils sont envoyés au serveur backend pour vérification. De même, toutes les informations sur les utilisateurs collectées lors de l’inscription sont également stockées dans une base de données, qui fait aussi partie du backend. Le serveur, sur lequel tournent toutes les entités du backend (service d’authentification, bases de données, API), fait également partie du backend.

Le Backend en tant que service (BaaS) décharge les développeurs de la responsabilité du développement et de la gestion du backend. Ils peuvent se concentrer sur le frontend ou partie frontale de l’application et la connecter au backend ou partie dorsale à l’aide d’API et de SDK (kits préconstruits pour développer des logiciels).

Le BaaS et le serverless sont similaires car ils cachent tous deux le backend aux développeurs. Cependant, avec le BaaS, vous ne bénéficiez pas de l’évolutivité à la demande que vous obtenez avec le serverless. De plus, tout comme la PaaS, les applications BaaS ne s’adaptent pas à la hausse ou à la baisse aussi rapidement que les applications serverless.

Dans l’image ci-dessous, vous pouvez voir que dans une configuration traditionnelle, nous aurons probablement deux serveurs exécutant deux applications. Il s’agit d’une approche sûre, car nous avons effectué le provisioning des serveurs individuels pour les applications. Mais c’est aussi du gaspillage, car (soi-disant) 30 % du temps, les applications ne reçoivent aucune demande. De plus, en cas d’augmentation drastique de la charge, il n’y a aucun moyen de faire évoluer les applications automatiquement.

En revanche, sur le côté gauche, l’architecture serverless ne comporte que deux serveurs exécutant quatre applications, car selon les demandes actuelles, cela s’avère suffisant. Il n’est pas nécessaire de réaliser le provisioning de serveurs supplémentaires à ce stade. Toutefois, dès que la plateforme se rendra compte qu’elle a besoin d’évoluer, elle ajoutera des serveurs si nécessaire. Elle peut également mettre un serveur hors service si elle n’en a plus besoin.

• Comme votre infrastructure est définie, maintenue et mise à l’échelle par votre fournisseur de Cloud, sa sécurité est principalement gérée par lui également. Il n’est plus nécessaire de renforcer le système d’exploitation ou de mettre en place des pare-feu.

• Un autre aspect de l’informatique serverless qui la rend si sûre et difficile à pirater est sa nature éphémère. Les applications, fonctions ou conteneurs sans serveur s’exécutent et s’arrêtent en fonction des besoins, ce qui réduit considérablement les risques d’attaques à long terme.

• Avec le serverless, vous avez la possibilité de passer à une approche microservices. Cela permet de définir des politiques par service, ce qui est beaucoup plus facile lorsque le service est de petite taille.

Cela dit, une partie de la responsabilité de la sécurité repose toujours sur vos épaules. N’oubliez pas :

• Votre fournisseur de Cloud peut appliquer des correctifs aux dépendances au niveau du système d’exploitation pour vous, mais vous devrez toujours vous assurer que les dépendances de votre application sont corrigées et à jour.

• Lorsque vous autorisez l’accès à vos serveurs ou fonctions, utilisez le principe du moindre privilège, c’est-à-dire donnez à un utilisateur les niveaux d’accès minimaux nécessaires à l’accomplissement de ses tâches.

• Si vous utilisez des fonctions événementielles, veillez à ce que vos données d’entrée soient nettoyées afin d’éviter les attaques par injection (injection SQL, etc.)

• Enfin, veillez à ce que le code de votre application soit sécurisé, en utilisant les bonnes pratiques pertinentes pour le(s) langage(s) de programmation ou le(s) cadre(s) utilisé(s).

Avantages

• Augmenter la productivité des développeurs en leur permettant de se concentrer sur ce qu’ils font le mieux : écrire du code.

• Aucune planification formelle des infrastructures n’est nécessaire.

• Diminution des coûts grâce au modèle de paiement en fonction de l’utilisation.

• Évolutivité améliorée et automatisée.

Inconvénients

• Les démarrages à froid (les serveurs redémarrent après s’être arrêtés pour cause d’inactivité) peuvent entraver les performances de certains produits serverless.

• Il est généralement très difficile de migrer votre environnement serverless d’un fournisseur vers un autre.

• Peut coûter plus cher pour les tâches de longue durée. Le serverless est idéal pour les tâches qui ne doivent pas être exécutées indéfiniment, ce qui permet de réduire les coûts lorsque la fonction ou l’application est inactive.

• Certains utilisateurs peuvent être confrontés à une courbe d’apprentissage abrupte. La création d’applications dans des environnements serverless est fondamentalement différente des approches traditionnelles.

L’une des préoccupations majeures de la plupart des gens concernant le serverless est le démarrage à froid. Comme nous l’avons évoqué plus haut, lorsqu’une application dans un environnement sans serveur n’a pas été invoquée depuis un certain temps, elle devient dormante. Dès qu’une nouvelle demande est reçue, l’application redevient active. Pour certains produits serverless, ce temps de démarrage peut ajouter une latence notable. Toutefois, les fournisseurs de Cloud tentent de résoudre ce problème en réduisant le temps nécessaire à la mise en route d’une application, d’un serveur ou d’une fonction.

Étant donné que le serverless a tant à offrir aux organisations de tous types et de toutes tailles, nous nous attendons à ce que son adoption augmente au cours des prochaines années.