La machine virtuelle Erlang
Initiée par Ericsson dans la fin des années 80 et rendue open-source en 1998, la machine virtuelle Erlang (aussi appelée la BEAM pour « Bogdan’s Erlang Abstract Machine ») avait pour but initial de répondre aux problématiques du monde des télécommunications. Utilisée aujourd’hui par des services tels que WhatsApp, Discord ou encore Pinterest, la BEAM semble pourtant être une technologie méconnue. Cet article essaie de présenter de manière concise les intérêts de cette machine virtuelle.
Les concepts derrière la BEAM
Dans les années 80, Ericsson souhaitait répondre aux problématiques rencontrées lors du développement de solutions dans le domaine des télécommunications (notamment pour les switchs téléphoniques). Le but de leurs recherches était de produire des systèmes moins complexes à maintenir que leur solution de l’époque à base de C et de Prolog.
Dans le cadre du domaine de télécommunication, Ericsson visait un outil permettant de créer des programmes :
– fortement distribués
– tolérants à la faute
– temps-réels (soft)
– à forte disponibilité
– où le code peut être mis à jour à chaud (sans downtime)
La firme suédoise déduira que le modèle d’acteur semble être une solution appropriée à leurs problèmes.
Dans le modèle d’acteurs, un acteur est une entité qui, en réponse à un message, peut :
– envoyer des messages à des acteurs
– créer de nouveaux acteurs
– changer son état
Ce modèle a plusieurs intérêts :
– l’isolation : si un acteur « crash », cela n’affecte que l’acteur en question
– la distribution : les acteurs peuvent communiquer ensemble, qu’ils soient sur la même machine ou bien répartis sur un réseau, tout ceci de manière transparente
– l’équité : un acteur ne peut affamer d’autres acteurs, c’est-à-dire consommer à lui seul toutes les ressources disponibles
Une implémentation du modèle d’acteur
La BEAM implémente le modèle d’acteurs. Chaque acteur est un processus gérant sa propre mémoire. Ces processus sont dits « légers », c’est-à-dire qu’ils sont peu consommateurs lors de leur création contrairement à un processus système. La seule manière de partager de la donnée est l’envoi de message d’un processus A à un processus B. Un processus est exécuté sur un ordonnanceur. Par défaut, la BEAM crée un ordonnanceur par cœur disponible sur la machine et distribue les processus de manière équitable.
De ce fait, un programme tournant sur la BEAM utilise tous les cœurs des processeurs actuels. De plus, le garbage collecting n’est pas global à tout un programme, mais local à chaque processus. À noter que, si un processus se termine, la mémoire utilisée est tout simplement libérée.
Plusieurs BEAM sont capables de s’interconnecter pour travailler ensemble. Ainsi, les messages transitent via le réseau de manière transparente pour le code ; c’est-à-dire qu’il n’est pas nécessaire d’adapter vos programmes pour adopter ce comportement. Si cela nous donne la possibilité de « scaling » en rajoutant une machine dans notre cluster, il est aussi important de noter que les pannes d’une machine physique ne rendent pas indisponible notre application si une autre machine est opérationnelle pour prendre le relai.
Une alternative à l’approche « microservices »
Le découpage en processus permet donc de mieux utiliser les ressources à votre disposition. De plus, il n’est pas nécessaire d’aborder la complexité de l’approche microservices pour commencer à développer votre première application sur la BEAM. L’approche monolithique est suffisante pour profiter du « scaling ». Encore aujourd’hui, il est risqué de lancer une nouvelle application avec une approche microservices, son développement étant plus coûteux, sans avoir confirmation de son intérêt et/ou de sa rentabilité. C’est ce qu’explique Martin Folwer dans son article « Monolith First ».
De plus, différentes applications exécutées sur la BEAM (ou un cluster de BEAM) sont capables de communiquer entre elles via le passage de message. Ceci permet un découpage fonctionnel si nécessaire.
Ceci dit, le désavantage évident de l’approche de la BEAM, si on la compare à l’approche microservices, est qu’elle ne permet pas de développer des services dans le langage de votre choix. Si aujourd’hui on compte deux langages (Erlang et Elixir) ayant pour cible de compilation du bytecode BEAM, la communication avec des services externes doit se faire à l’aide de systèmes tiers (par exemple avec un message broker).
En résumé
La BEAM implémente le modèle acteurs qui permet une forte concurrence et une tolérance à la faute logique et à la panne physique. Découper la logique en plusieurs processus est un pli à prendre avec la BEAM, mais cela permet d’éviter beaucoup de complexité technique. En effet, nous ne sommes pas obligés de prendre en compte les découpages nécessaires pour monter à l’échelle dans une architecture de microservices plus traditionnelle. L’approche proposée par la BEAM permet de développer une solution qui est un juste milieu entre une architecture monolithique et une architecture « microservices ».
Vous ayant introduit la BEAM, nous continuerons dans un prochain article sur le langage Elixir qui tire parti des qualités de cette curieuse machine virtuelle.
