Repenser le serverless : la technologie FLAME

Le modèle FLAME : une nouvelle approche pour l’extension élastique des applications

• Le serverless/FaaS (Function as a Service) offre les avantages d’une extension élastique et d’une facturation à l’usage, mais entraîne en pratique davantage de complexité.
• S’il était possible d’envelopper le code d’une application existante dans des fonctions pour l’exécuter dans des copies temporaires de l’application, la mise à l’échelle automatique deviendrait possible.
• Le modèle FLAME (Fleeting Lambda Application for Modular Execution) traite l’application entière comme une lambda et exécute des parties modulaires sur une infrastructure éphémère.

Le modèle FLAME

• Le modèle FLAME vise une extension élastique fine, basée sur la demande, pour des parties spécifiques du code applicatif, sans gestion de serveurs.
• Il n’est pas nécessaire de réécrire une application existante ni d’en réimplémenter certaines parties dans un runtime propriétaire.
• La bibliothèque flame d’Elixir implémente le modèle FLAME et inclut un adaptateur backend Fly.io, mais elle peut être utilisée sur n’importe quel cloud fournissant une API capable d’exécuter du code applicatif.

Le backend FLAME

• Sur l’infrastructure Fly.io, FLAME.FlyBackend peut démarrer une nouvelle Machine et la connecter à la tâche parente en environ 3 secondes.
• FLAME fournit par défaut LocalBackend et FlyBackend, mais tout hébergeur offrant une API pour provisionner des serveurs et exécuter du code applicatif peut fonctionner comme backend FLAME.
• Fly.io exécute les applications empaquetées sous forme d’images Docker ; il suffit donc de démarrer une nouvelle Machine à partir de la même image.

Elixir au-delà de FLAME

• Elixir convient particulièrement bien au modèle FLAME, car il fournit nativement des fonctionnalités comme la supervision de processus et la messagerie distribuée.
• Si un langage dispose de primitives de concurrence raisonnables, il peut tirer parti de ce modèle.
• Il existe aussi des exemples montrant comment implémenter le modèle FLAME dans des applications JavaScript, en déplaçant l’exécution modulaire dans un nouveau fichier.

À propos des processeurs de tâches en arrière-plan

• FLAME fonctionne bien au sein d’un processeur de tâches en arrière-plan, mais c’est un problème distinct de l’extension du pool de workers par une bibliothèque de jobs.
• Il est important de séparer les tâches qui garantissent la durabilité de celles qui assurent l’exécution élastique.

Pooling pour l’extension élastique

• L’implémentation Elixir de FLAME permet de définir des runners pour des pools élastiques, ce qui permet une mise à l’échelle jusqu’à zéro ainsi qu’une extension élastique de serveurs FLAME avec une limite de concurrence maximale.

Placement des processus

• En Elixir, les parties d’une application qui ont un état sont construites autour de la primitive de processus et fonctionnent bien lorsqu’elles sont encapsulées avec FLAME.call ou FLAME.cast.

Supervision à distance

• Lorsque le parent lance un runner, celui-ci doit gérer lui-même sa mise en veille lorsqu’il n’a pas de travail et s’arrêter en toute sécurité si la connexion avec le nœud parent est interrompue.

L’avis de GN⁺

Le point le plus important de cet article est que le modèle FLAME peut simplifier l’extension élastique des applications tout en réduisant la complexité des approches serverless/FaaS traditionnelles. Ce modèle permet aux développeurs d’étendre rapidement uniquement les parties nécessaires, sans modifier en profondeur le code existant, ce qui peut en faire une solution attractive pour de nombreux ingénieurs logiciels utilisant une infrastructure cloud. Le modèle FLAME pourrait être particulièrement puissant avec un langage comme Elixir, et comme sa mise en œuvre dans d’autres langages est également explorée, on peut espérer des applications dans des environnements de développement variés.

[GN⁺]

Avis Hacker News

• Après avoir géré pendant 4 ans une application composée de plus de 100 fonctions Lambda, ce billet met bien en évidence la douleur et la complexité des architectures serverless de type FaaS.

  • Au début, ces inconvénients ne se voient pas vraiment, et il y a des avantages clairs, comme la gratuité à faible usage et un besoin de maintenance quasi nul.
  • Mais avec le temps, on se retrouve dans le chaos de workflows Lambda de plus en plus rigides à cause des interdépendances, et on finit par penser qu’il aurait mieux valu choisir une approche monolithique auto-gérée et payer un léger surcoût.

• En tant qu’auteur de l’article, j’espère susciter l’intérêt de celles et ceux qui voudraient implémenter le pattern FLAME dans d’autres langages comme JavaScript ou Go, et je suis prêt à répondre aux questions.

• Le service PiCloud utilisait un modèle qui envoyait de manière transparente les tâches vers des workers, ce qui suggère qu’une approche similaire peut aussi s’appliquer dans d’autres langages qu’Elixir.

• Avec FLAME, il est possible d’envelopper le code applicatif existant dans une fonction et de l’exécuter dans une copie temporaire de l’application, ce qui ressemble à un fork de processus dans un environnement serverless.

• Windmill.dev réfléchit à l’unité d’abstraction au niveau du code source, en analysant les fonctions principales et les imports pour extraire les arguments et dépendances, puis exécuter le code dans le runtime souhaité.

• FLAME offre une bonne expérience de développement local en environnement serverless, car les runners de développement et de test s’exécutent sur un backend local.

• À chaque utilisation de Flame.call, un nouveau processus applicatif est lancé et le contexte d’exécution est copié ; c’est une solution simple pour le scaling, mais il faut tenir compte de la latence ajoutée au démarrage de l’application et de l’usage mémoire.

• Avec une critique de l’usage des majuscules dans les titres sur Hacker News, on exprime aussi l’espoir de voir reconsidérées non pas les idées du serverless, mais celles de l’entreprise serverless.com.

• Inngest.com propose une approche similaire pour permettre d’utiliser du code existant comme fonctions serverless, en gérant l’état du code depuis l’extérieur et en soulignant l’importance du monitoring et de l’observabilité.

• En créant un système appelé « Long Lambda », si les Lambdas pouvaient s’exécuter plus de 15 minutes, tout pourrait être traité dans Lambda, avec la possibilité d’exécuter et de déboguer localement.

Ce résumé transmet de façon concise l’idée principale de chaque commentaire et a été rédigé à un niveau facile à comprendre pour un ingénieur logiciel débutant. Les éléments nécessitant des connaissances préalables ont été expliqués au minimum, tout en gardant une attitude neutre et en restant dans le sujet.