Quels sont les réels atouts du Serverless  ?

Frédéric Barthelet, Responsable de l’unité Serverless chez Theodo et membre de l’équipe d’organisation des Serverless Days Paris, partage son expertise sur le sujet.

Le serverless, un ensemble de services spécialisés facturés à l’utilisation

Une infrastructure classique se compose traditionnellement d’un ensemble de serveurs ou machines virtuelles louées pour une période de temps moyennant un coût récurrent fixe, quelle que soit la charge des serveurs.

L’offre serverless des cloud providers tels qu’AWS, Azure ou Google Cloud vient casser ce modèle d’infrastructure, en proposant un ensemble de services spécialisés, managés, visant à remplacer les fonctions les plus courantes d’un serveur web, et facturés à l’usage. L’infrastructure sous-jacente et sa maintenance (mise à jour et de runtime pour patcher les vulnérabilités, gestion de l’espace disque disponible, sécurisation des accès) devient ainsi l’entière responsabilité du fournisseur de serveur.

Utilisation de l’application (bleu)

Coût de l’infrastructure (rouge)

Ces services se scindent en 2 grandes catégories :

• les services FaaS, ou Fonction as a Service, responsables d’exécuter du code métier propre au business de l’application, en réponse à des évènements spécifiques (requête HTTP, fichier uploadé, utilisateur authentifié…)
• les services BaaS, ou Backend as a Service, responsables de réaliser des tâches spécifiques habituellement portées par des fonctionnalités de framework, comme le routing, l’authentification ou le stockage de fichier et qui peuvent servir d’événements déclenchant pour les FaaS.

Fonctionnant de concert pour réduire la code base

Designer une architecture serverless, c’est combiner les bons services au bon moment et les faire intéragir pour construire une application complète en écrivant seulement les lignes de code relatives à son métier, celles qui apportent le plus de valeur. Plus de code pour gérer le routing, le cache, la validation, la gestion d’erreur, l’authentification… On déporte la responsabilité du développeur d’implémenter ces fonctions supports (sans erreur) à un ensemble de services dédiés, spécialisés, maintenus et scalables.

Chez un cloud provider comme AWS, on utilisera par exemple CloudFront pour porter les certificats HTTPS d’une application web, et gérer le cache. Ce dernier sera configuré pour transférer les requêtes HTTP faites à CloudFront vers API Gateway, services de routing, de validation et d’autorisation si utilisé conjointement avec Cognito. Enfin, une Lambda contenant la logique métier propre à l’application sera invoquée par API Gateway, elle-même se reposant par exemple sur DynamoDB comme base de données.

Le Serverless pour développer une application à faible TCO, scalable automatiquement

Le TCO (pour Total Cost of Ownership) désigne l’ensemble des coûts liés, dans notre cas, au développement d’un produit tout au long de sa durée de vie. En la matière, le paradigme serverless a plusieurs avantages :

• Le coût est calculé à l’utilisation

le nombre de requêtes HTTP API Gateway, le nombre de secondes d’exécution de Lambda. Sans utilisateur, aucune dépense.

• L’architecture est scalable par essence

Aucune intervention en amont d’un pic de charge prévu n’est nécessaire. C’est la responsabilité du cloud provider de s’assurer que suffisamment de ressources physiques de calcul soient disponibles pour que chaque service puisse répondre à la demande de l’ensemble de ses clients. Cette gestion nous est complètement abstraite et ne nécessite aucune configuration.

• Les services sont sécurisés

et mettent en place les bonnes pratiques nécessaire à la réduction des surfaces d’attaque d’architecture plus classique (chiffrage au repos des données,  rotation des clés de chiffrement, gestion des accès aux API de provisionning et d’utilisation de chaque service en refus par défaut, permission granulaire pour chaque service). Cette sécurisation est mise en place par défaut et ne génère pas de coûts supplémentaires.

• Les déploiements sont rapides et ciblés

Aucune raison de mettre l’ensemble des configurations des services à jour. Le déploiement est entièrement automatisé, et laissé à la responsabilité de services dédiés, comme CloudFormation chez AWS.

• Les compétences requises pour maintenir des applications serverless ne demandent plus une équipe dédiée ops,

mais une équipe de développement sensibilisée à des sujets d’ops. Les développeurs configurent eux-mêmes les différents services, et sont garants de l’optimisation de leur utilisation pour réaliser telle ou telle fonctionnalité. Il n’y a plus de frontière entre infrastructure et applicatif : chaque fonctionnalité de l’application nécessite d’écrire du code et de la configuration pour provisionner les services nécessaires à son fonctionnement.

Un paradigme mature, évoluant rapidement, avec des challenges à relever

L’utilisation en production permet d’avoir du recul sur le chemin qu’il reste à parcourir. La technologie, bien que jeune, est déjà suffisamment mature car portée par de grands acteurs cloud. Elle est prête pour une utilisation en production, comme les exemples d’iRobot, de la BBC ou encore de Netflix le prouvent . Les points durs restants portent sur :

• l’observabilité qui est rendue plus ardue par l’utilisation d’une architecture distribuée sur plusieurs services à chaque interaction d’un utilisateur sur une application.

Certains services de monitoring comme Epsagon ou Lumigo se sont spécialisés dans la récupération des logs de chacun de ces services pour permettre de reconstruire l’enchaînement complet d’évènements et permettre ainsi de diagnostiquer plus rapidement des bugs.

• la non-coopération des différents cloud providers pour mettre en place un catalogue unifié agnostique pour réduire les problèmes de vendor lock-in.

L’intégration profonde de service spécialisée dans un paradigm serverless rend toute migration plus importante que dans des paradigm d’hébergement par machine virtuelle. Chaque migration d’un cloud à un autre, même dans un architecture plus classique représente toujours un coût important (migration de base de données, de système de gestion d’accès)

• l’outillage des équipes de développement, très différent de ce à quoi les développeurs sont accoutumés (en retirant entièrement le concept d’environnement de développement local virtualisé avec des outils comme Docker ou Vagrant).

Le serverless nécessite un travail de formation important pour permettre aux équipes d’avoir une connaissance suffisante des différents services du catalogue serverless d’un cloud provider. Le cycle de développement et la maintenance de ce genre d’architecture nécessite également un accompagnement.

L’approche serverless démontre son efficacité et permet en particulier d’améliorer la capacité de production d’une équipe de développement, de livrer un produit en production plus rapidement.

A Theodo, nous accompagnons nos clients pour les faire monter en compétence sur le serverless en intégrant nos experts directement avec leurs équipes de développement et en faisant de la formation notre priorité pour leur permettre une totale autonomie dans cet écosystème. Nous contribuons énormément à la communauté open-source pour rendre le serverless plus accessible et démocratiser son usage, et tous les avantages qui en découlent.