L’échec de l’élastique comme un service

L’échec de l’élastique comme un service (et son renouveau)

Le Cloud est élastique

Le Cloud n’a qu’une seule fonction intéressante : l’élasticité. Tout le reste n’est que blabla commercial ou confusion sémantique. Attention, je ne suis pas nostalgique du serveur cousu main, à l’ancienne. Les offres d’hébergement sont en constante évolution et mettent à disposition plein de belles choses, mais ce ne sera que rarement du Cloud.

La définition du Cloud est pourtant simple : Mise à disposition DYNAMIQUE de ressources via une API distante. Même Wikipedia le dit, enfin presque. Je peux commander des ressources, et les utiliser dans les minutes qui suivent, en demander plus, puis les diminuer un peu plus tard.

Ces ressources peuvent être matérielles (bien que virtualisées) comme de la puissance de calcul ou du stockage, mais aussi de plus haut niveau, des services.

Le Cloud sait mettre à disposition des ressources de bas niveaux : CPU, RAM, réseau, disque… depuis maintenant presque 10 ans, grâce à la virtualisation.

Mais la virtualisation est beaucoup plus à l’aise pour dimensionner une machine à froid. L’élasticité, ce serait pouvoir redimensionner certaines ressources à chaud, sans redémarrer. Techniquement, des choses sont faisables, mais il est très difficile de mettre à disposition un pool de ressources et de piocher dedans, l’unité de base reste la machine physique.

Il est beaucoup plus simple de travailler avec plusieurs machines (réelles ou non), et d’en ajouter ou d’en enlever, puis de demander à la partie applicative de gérer cette fluctuation en débranchant et rebranchant les différents éléments.

Le web est élastique

Le web se prête bien aux architectures distribuées dynamiques, avec son protocole sans état (en théorie).

La méthode immuable pour traiter les requêtes web est celle de l’aiguillage qui va demander le traitement de la demande a des workers. Les workers peuvent être des process ou des threads sur une même machine, eux-mêmes répartis sur plusieurs serveurs. HAproxy ou Nginx (plus faiblard), sont capable de répartir la charge entre plusieurs machines.

Le load-balancer devient une pièce maitresse des applications distribuées. Nginx évolue rapidement (principalement sur sa branche privatrice) pour reprendre sa place de proxy universelle, HAproxy va intégrer Lua, et des proxy applicatifs apparaissent, comme le maintenant historique Hipache ou le prometteur Vulcan.

Dire que le protocole HTTP est sans état est un mensonge, enfin, un raccourci. La notion de cookie puis celle de session sont apparues très vite, pour conserver l’état d’un client sur une période plus ou moins longue. Dans un environnement distribué, il faut pouvoir partager un état entre les workers, rôle traditionnel de Memcache, challengé par Redis.

De la même manière, il faut pouvoir gérer les uploads de fichiers de manière centralisée avec S3 et ses clones, ou le classique NFS.

Pour la persistance, les inébranlables bases de données relationnelles ont encore largement leur place, challengée par la vague du NoSQL, plus ou moins fiable, mais tellement plus adapté au redimensionnement.

Pour ceux qui ont encore faim, il est possible de gérer tout ça de manière dynamique.

Tout ça pour atteindre le Graal de l’élasticité.

Élastique comme un service

La complexité est quand même impressionnante pour un besoin que beaucoup de gens n’auront jamais.

Il y a eu une première vague de réponses pour simplifier l’accès à l’élastique : Google App Engine, puis Elastic Beanstalk.

Deux produits contraignants, qui, bien qu’utilisant des langages libres, enferment l’utilisateur dans une solution propriétaire.

Ces deux produits ont causé beaucoup de drames : des langages arbitrairement périmés, un environnement de dev ne ressemblant que très peu à la prod, des performances aléatoires, et surtout l’impossibilité d’utiliser des frameworks et des applications largement utilisées dans des environnements classiques. Une vraie catastrophe.

Et tout ça pour se faire siphonner sa carte bleue, si le site a la mauvaise idée de faire une belle audience. Le plafond de cout étant apparu sur le tard : “Attention, nous, on scale, mais pas ta carte bleue”.

Le conteneur est élastique

Donc l’approche bas-niveau ne suffit pas, et les approches de trop haut niveau sont encore pires. Il faut donc voir ce qui est faisable avec une approche plus modérée.

Les conteneurs, qui ne sont ni de la virtualisation, ni de l’applicatif, permettent d’embarquer une application avec tout ce dont elle a besoin, et de la lancer avec quelques paramètres dans un environnement maitrisé (accès aux ressources physiques, isolation). Le Cloud devient un simple pool de ressources dans lequel on va piocher en déployant ou déplaçant un conteneur là où il y a de la place.

Le conteneur peut être considéré comme immutable (en lecture seule), et il confiera ses besoins d’IO à des services réseau, ou à un point de montage avec un système de fichier. Le réseau est clairement plus souple, mais des systèmes de fichiers modernes permettent de faire de belles choses (comme ZFS avec le double push de Flocker).

On a donc une application tout ce qu’il y a de plus classique, en PHP, Python ou je ne sais quoi, qui va se retrouver sur un Linux en lecture seul (ou presque), et dont on va pouvoir multiplier les instances. Se passer du stockage local est intégré dans beaucoup de framework maintenant :

Pour le reste, il suffit de brancher une poignée de services (session, caches, base de données…) et avoir une première étape de scaling sans douleur.

La seconde étape arrive quand la base de données commence à crier, et il va falloir négocier pour aller au-delà du combo index/cache/tuning pour avancer. Mais bon, cette étape arrive lorsque l’on a un joli trafic, et il est toujours possible de négocier en force en ajoutant un esclave plus gros (plus de coeurs, plus de RAM, plus de SSD…), et de le promouvoir, pour faire du scaling vertical.

Scaler la couche applicative en utilisant des conteneurs est la voie dans laquelle s’engagent (à fond) les gros du Cloud, avec des solutions ouvertes ou non :

Kubernetes, qui a le bon gout d’être libre, déchaine l’enthousiasme. Red Hat se raccroche aux branches et profites de Kubernetes pour faire basculer vers les conteneurs son Open Shift pour la version3 en préparation.

Les conteneurs posent encore beaucoup de questions, et des startups proposent des réponses, comme Flocker de ClusterHQ pour avoir de la persistance qui peut migrer. CoreOS continue de taper tous azimuts. HashiCorp se contentait d’une gestion opportuniste des conteneurs, mais c’est en train de bouger. Terraform dans sa version 0.4 gère Docker, et j’ai hâte de voir comment Consul et les autres outils vont s’adapter.

La fusion du Cloud et des conteneurs est en train de se faire, là, maintenant. Il y aura des nouveautés, et des morts. Cette fusion amène de nouvelles réponses, et tout autant de questions. Rendre possible l’élasticité de la partie applicative fait partie des réponses apportées par la combinaison du Cloud et des conteneurs.

blogroll

social