Les plateformes de type cloud computing (comme l'EC2 d'amazon) sont à la mode en ce moment, et d'après ezra, ça ne fait que commencer.

Je m'intéresse de plus en plus à ce type de solutions depuis que je travaille sur deescover, puisque le système a besoin de monter en charge.

Vertebra est donc un système de gestion de cloud computing (nuage de machines).
Il est vrai que le déploiement d'une application à forte charge, donc répartie entre plusieurs machines, peut vite s'avérer un casse tête, même avec des outils exceptionnels comme capistrano.

Vertebra se base sur XMPP afin de permettre aux différentes machines de communiquer entre elles.
XMPP, utilisé entre autre par jabber, est un standard qui peut être utilisé dans bien des situations.
L'idée de vertebra est de permettre à des machines (et plus seulement des personnes) de communiquer avec ce protocole.

Comme dans un système de messagerie, les machines disposent d'un statut, permettant de préciser leur état (disponible / indisponible / occupé).
Pour spécifier cet état un agent ruby tourne sur chacune des ressources du 'cloud'.
Il est important de spécifier que les agents tournent à deux niveaux :

  1. Au niveau node (noeud : groupe de machines) afin de connaître l'état des ressources du noeud.
  2. Au niveau slice (la resource ou machine) afin de lister les opérations disponibles.

Pour continuer dans les bonnes idées, le clud est Restful. Les opérations disponibles sont enregistrées au niveau de la ressource du cloud et sont accessibles au travers d'URL.
Sans ré-expliquer REST, le type d'opération dépend uniquement de l'URL et de la façon dont on y accède (GET : consultation, POST: création, PUT : modification, DELETE: suppression).

Chaque noeud dispose donc d'une API prête à l'emploi en fonction des opérations qu'il enregistre.
Ces opérations sont donc consultables à la demande par un simple message XMPP.

L'exploration des différents noeuds se fait de façon dynamique, par un système de broadcast des messages (basé sur XMPP donc).
En fonction des réponses il est possible de déterminer l'état des noeuds, mais aussi de choisir à qui adresser une opération (potentiellement le noeud qui répond le plus vite).
Ce système permet donc aussi de répartir la charge.

La présentation d'ezra montre bien que les jeux de questions - réponses ne sont pas limités.
Il est par exemple possible de déterminer l'état et la configuration des différentes machine du noeud depuis l'agent grâce à l'API.

Du côté des technologies utilisées on retrouve donc ruby, pour la partie agent, et erlang pour la partie serveur XMPP (ejabberd), mécanisme de découverte de services ...
Bref, que du bon.

Bien sûr on pourrait se poser la question de savoir comment sont gérées les autorisations entre les agents.
On n'imagine mal n'importe quel système envoyer un message XMPP à l'agent pour lui ordonner d'éxécuter une tâche.
Comme pour les systèmes de messagerie classiques, les agents sont en relation les uns avec les autres (un peu comme une liste de contact).
Pour 'se parler' chacun doit donc être dans la liste de l'autre.

La souplesse du système et de l'architecture choisie ouvre des tas de possibilités dont parle ezra : ne plus se limiter à de l'automatisation de tâches systèmes mais utiliser ce sytème en temps réel pour des applications web.

Ce principe est déjà possible grâce à fuzzed.
Écrit en Erlang, il permet de facilement créer un cluster et dispatcher les requêtes.
Ce système permet de monter en charge rapidement en ajoutant simplement des nodes au cluster.

Voilà, ça bouillonne pas mal en ce moment, et les grincheux qui crient sur tous les toits que rails ne monte pas en charge [1] et est complexe à déployer n'ont qu'à bien se tenir.

Notes

[1] Ce qui est idiot puisque ce n'est pas la technologie qui monte en charge mais l'architecture.