Le serverless

Dans cet article, nous vous proposons de refaire un rapide historique du développement informatique, afin de mieux comprendre les évolutions actuelles et futures, et d’appréhender le rôle du « Software Engineer ». Le 1^er service « Serverless » – le FaaS (Function as a Service) – est détaillé, avec les avantages et inconvénients, les cas d’usage où ce service est pertinent ainsi que l’écosystème associé (propriétaires ou open-source).

La course est lancée pour que la scalabilité ne soit plus spécifiquement gérée par le développeur mais aussi par les services proposés (capacité de compute, bases de données…).

Nous terminerons cet article par un cas d’usage dans le domaine de l’énergie, au sein d’une architecture AWS.

Commençons par un peu d’histoire …

Pour bien comprendre ce qu’est le « serverless », il est important de rappeler comment une application est construite, et aussi les évolutions depuis les trente dernières années environ.

Illustration : Oracle

Avant l’arrivée des environnements virtuels (à la fin des années 90), l’application était hébergée sur un serveur physique ; cela se traduisait par :

• l’achat d’un serveur aux caractéristiques appropriées pour héberger l’application ;
• l’installation du serveur dans un datacenter ;
• la mise en réseau, l’alimentation électrique, le refroidissement etc. ;
• l’application des mises à jour du système d’exploitation, des correctifs de sécurité, la supervision de la machine pour la redémarrer en cas de soucis etc.

Il fallait alors plusieurs semaines pour avoir un environnement de travail opérationnel.

Les environnements virtuels ont permis d’accélérer la mise en place d’une application ; la partie « physique » d’un serveur étant alors « masquée ».

Le développement rapide de cette technologie coïncide avec l’émergence du Cloud, dont la création d’AWS en 2006. Les « couches basses » (l’infrastructure et les serveurs physiques) sont gérées par le Cloud Provider et le Client n’y a pas accès.

En grande majorité, les développements informatiques se font désormais sur des environnements virtuels ; la mise à disposition d’un environnement de travail ne prend plus que quelques minutes, avec la possibilité d’adapter la puissance de la machine (mémoire, CPU…), voire la faire évoluer selon ses besoins.

En 2013, Docker publie son logiciel de conteneurisation : une nouvelle « couche d’abstraction » est créée : le container ne contient plus que l’application, binaires et librairies nécessaires. Le développeur n’a plus à se soucier du système d’exploitation.

Le développement de « micro-services » se développe afin de rendre plus modulaires les applications, davantage scalables et maintenables.

Des solutions d’orchestration de containers émergent, dont la plus connue est Kubernetes (voir notre article de Blog), permettant de gérer le déploiement, la mise à l’échelle et la gestion automatisée des conteneurs.

En 2015, AWS sort la 1^ère version de son service, Lambda, dit « Serverless », où le développeur se concentre uniquement sur le code de la « fonction » à réaliser. Le concept de « Serverless » ne cesse alors de prendre de l’ampleur :

Evolution du nombre de recherches sur Google de “serverless”

La succession de couches applicatives permet désormais au Software Engineer de s’extraire des « couches basses », très techniques, pour ne se concentrer que sur le développement de la solution.

Intéressons-nous au Function as a Service

Le Function as a Service (FaaS) est un moyen d’exécuter des morceaux de code modulaires (écrits dans son langage de prédilection, comme Python, Java, C#…). Ce code forme une « fonction » et un ensemble de « fonctions » un micro-service.

La fonction est généralement exécutée :

• en réponse à un événement, tel qu’un utilisateur qui clique sur un élément d’une application web ;
• de manière ordonnancée, pour exécuter une tâche ponctuelle (un calcul d’indicateur journalier par exemple) ;
• en lien avec d’autres services, comme le dépôt d’un fichier, en sortie d’une file d’attente etc.

Quels sont les avantages du FaaS ?

• Le développeur est plus productif car il se focalise sur la logique applicative, sans se soucier du déploiement de son code sur les serveurs. En effet, la configuration et le provisionnement sont délégués au Cloud Provider : le développeur choisit son langage de programmation (Python, C#, Java…) et la mémoire nécessaire pour son exécution ; plus besoin d’installer le « runtime » d’exécution du programme sur le serveur ni de demander à l’IT une extension de mémoire au serveur pour faire tourner l’algorithme !
• Il est facile de mettre à l’échelle le code. Plusieurs instances du même code peuvent s’exécuter de manière simultanée (chez AWS : 1000 exécutions en parallèle sont possibles par défaut) en réponse à des événements, avec un temps de réaction inférieur à 100 ms (voir article de Blog AWS).

Quels sont les inconvénients du FaaS ?

• Du fait de la limitation en mémoire et en temps d’exécution (sur AWS, une Lambda est limitée à 3 Go de mémoire et 15 minutes d’exécution), tous les cas d’usage ne conviennent pas au FaaS car :
  • pour traiter de gros volumes de données, il faut pouvoir les segmenter afin de pouvoir les traiter de manière simultanée (via l’exécution de plusieurs instances de FaaS), ce qui nécessite de limiter le flux de données en entrée de la FaaS et d’organiser les données de manière cohérente pour les traiter simultanément.
• le coût peut devenir important. Par exemple, une AWS Lambda qui serait exécutée l’équivalent de 720h avec 3 Go de mémoire revient à 1200 USD/mois, alors qu’une simple machine virtuelle EC2 avec 4Go de mémoire revient à 40 USD/mois et un container de type Fargate de ressources équivalentes (2 vCPUs et 3 Go de mémoire) revient à 70 USD/mois. Il convient donc de réserver le FaaS à l’exécution de services qui doivent s’exécuter en réponse à des événements et non pour traiter un flux continu de données dont le débit est fixe.
• Chaque Cloud Provider propose sa propre solution FaaS : AWS Lambda, Google Cloud Function, Azure Function. Chaque solution est propriétaire et le risque est grand d’être pris dans le « vendor-locking », chaque Cloud Provider ayant ses spécificités (comme la durée maximale d’une fonction, les langages supportés, le nombre de fonctions pouvant être lancés simultanément etc.).

Principaux cas d’usage du FaaS :

Site Web dynamique

La partie dynamique est traitée par plusieurs FaaS en réponse à une action de l’utilisateur, à travers l’appel d’APIs. Exemple  https://aws.amazon.com/fr/serverless/build-a-web-app/

Traitement sur des fichiers

Lors du dépôt d’un fichier, un FaaS s’exécute automatiquement afin de réaliser un traitement (insertion de méta-données dans une base de données, vérification du format, enrichissement par exemple).

IoT

Afin d’interagir avec les données reçues, un FaaS est déclenché (pour chaque événement ou par lot d’événements)

Ecosystème FaaS open-source

Outre les 3 services propriétaires proposés par AWS, Google et Azure (OVHcloud ne propose pas de service propriétaire mais une offre FaaS à travers OVH Managed Kubernetes et OpenFaaS), de nombreux frameworks open-source existent comme OpenWhisk, OpenFaas, Cloudstate, serverless framework. Tous font la promesse d’une meilleure portabilité, d’une plus grande transparence dans le paramétrage et dans l’utilisation d’outils 100% open-source.

Apache OpenWhisk reposant sur des containers

Les autres fonctionnalités

Après le FaaS, de nouveaux services « serverless » ont été développés afin que le développeur se concentre sur la logique métier et laisse au Cloud Provider la responsabilité de la disponibilité, la scalabilité et la sécurité du service.</