Dotcloud vient de lâcher le morceau . Après avoir livré son fleuron, Docker , qui porte haut l'étendard de LXC, ils livrent d'autres bouts de la stack . L'enthousiasme est réel sur Github, ils ont eut plein de ★ très rapidement. Dotcloud n'a pas uniquement fait ça pour rendre le monde meilleur, mais aussi pour se débarrasser de leurs leechs. Dotcloud vends une solution d'hébergement Cloud, avec jusqu'à récemment un modèle freemium. Pour arrêter de bosser gratos, ils ont donc libéré la suite des outils nécessaires pour faire du dotcloud, dans sa maison, avec une doc pour faire la migration. Donc, le petit freemium, soit il devient client, soit il déploie son bazar un peu plus loin.
Je suis de mauvaise foi, la plupart des services gratis et populaire qui ferment, ils donnent rarement les billes pour changer de fournisseurs, et là, les billes, ce sont les sources. Certains outils peuvent faire ricaner, comme hipache , un apache pour les hipsters, un truc en node capable de router des websockets. Ricanez, mais pour l'instant, seul une bêta de haproxy sait faire ça. Leur rpc aussi est fourni, zeroRPC , du msgpack over zeromq, mot compte double. Au-delà du buzzword, c'est surtout un protocole concis, typé, gérant aussi le binaire, conçu pour l'asynchrone et gérant les patterns classiques comme le fan out ou le pubsub. Autre avantage de cette libération, on commence à avoir une idée précise de l'architecture des projets Heroku like : du routage dynamique assure le virtualhosting entre différents utilisateurs. Le routage est temps réel, avec un Redis ou quelque chose d'équivalent. Le routage peut dispatcher le travail entre différents workers, constater un décès, ou même effectuer une mise à jour ou un rollback. Le routage gère un potentiel certificat SSL, et il assure le scaling, en ajoutant et enlevant des workers, poliment, une fois la réponse reçue. Une application utilise un simple manifest pour décrire ses besoins, et une partie de la conf se fait via des variables d'environnement. La supervision, les workers et les crons font partie des services de base. Le déploiement se fait d'un bloc, avec du baking (génération des assets, compilations, voir même des tests unitaires), pour pouvoir faire un rollback (comme Capistrano le propose depuis longtemps), et les données (comme les fichiers uploadés) sont rangées à part, bien qu'une solution type S3 soit préférable.
Voilà, plus de briques légos pour faire des constructions encore plus grosses!
