Donc voici la traduction de celui-ci. Faites-vous plaiz’

Hey, mon boss m’a dit de venir te voir. Il paraît que tu gères niveau web apps ?

– Ouais, je suis plus un spécialiste des systèmes distribués maintenant. Je reviens du ContainerCamp et de la Gluecon et je vais à la Dockercon la semaine prochaine. Je suis emballé par la direction que prend l’industrie – tout est plus simple et fiable. C’est le futur !

Cool. Je veux juste faire une simple Web app pour le moment – un CRUD normal avec Rails, que je vais déployer sur Heroku. C’est toujours d’actu ?

– Oh non. C’est old school. Heroku, c’est mort – plus personne ne l’utilise. Il te faut Docker maintenant. C’est le futur.

Oh, OK. Qu’est-ce que c’est ?

– Docker est la nouvelle façon de faire de la conteneurisation. Comme LXC, mais c’est aussi un format de package, une plateforme de distribution et des outils pour rendre la création de systèmes distribués très facile.

Conteneuri.. – Hein ? C’est quoi LXE ?

– LCX. C’est comme un chroot aux stéroïdes.

C’est quoi cheroot ?

– Ok, regarde. Docker. Conteneurisation. C’est le futur. C’est comme la virtualisation, mais plus rapide et moins coûteux.

Oh, comme Vagrant.

– No, Vagrant c’est mort. Tout va être conteneurisé maintenant, c’est le futur.

Ok, donc je n’ai pas besoin de savoir quoi que ce soit sur la virtualisation ?

– Non, tu as quand même besoin de la virtualisation, parce que les conteneurs ne fournissent pas toutes les couches de sécurité pour le moment. Donc ce que tu veux, c’est faire tout tourner dans un environnement multitiers de telle sorte qu’on ne puisse s’échapper de la sandbox.

Ok, je suis un peu perdu là. On rembobine. Donc il y a un truc comme la virtualisation qu’on appelle les conteneurs. Et je peux l’utiliser sur Heroku ?

– Et bien, Heroku a un support pour docker, mais je viens de le dire : Heroku c’est mort. Ce que tu veux c’est faire tourner tes conteneurs sur CoreOS.

Ok, c’est quoi ?

– C’est un OS hôte très cool qu’on peut utiliser avec Docker. Tu n’as même pas besoin de Docker, tu peux utiliser rkt.

Rocket ?

– No, rkt.

Ouais, Rocket.

– Non, ça s’appelle rkt maintenant. Rien à voir. C’est un format de conteneurisation alternatif qui n’est pas aussi intégré que Docker par défaut, et donc plus composable.

C’est une bonne chose.

– Bien entendu. La composabilité c’est le futur.

Ok, ça s’utilise comment ?

– Je ne sais pas. Je ne pense pas que qui que ce soit l’utilise.

Arf. Tu disais quoi à propos de CoreOS ?

– Ah oui, c’est un OS hôte pour Docker.

C’est quoi un OS hôte ?

– Un OS hôte fait tourner tous tes conteneurs.

Tourner mes conteneurs ?

– Ouais, tu dois avoir quelque chose pour faire tourner tes conteneurs. Donc tu te crées genre une instance EC2, tu mets CoreOS dessus, tu lances le daemon Docker, puis tu déploies tes images Docker dessus.

Quelle partie est le conteneur ?

– Tout. Écoute, tu prends ton app, écris un Dockerfile, tu en fais une image locale, puis tu la push sur n’importe quel hôte Docker.

Ah, comme Heroku ?

– Non, pas Heroku. Je te l’ai dit. Heroku c’est mort. Tu gères ton propre cloud en utilisant Docker.

Hein ?

– Ouais, c’est tout simple. Check #gifee.

Gify?

– Google’s infrastructure for everyone else. Tu prends les outils que tu veux, avec des conteneurs, et tu as la même infra que Google.

Pourquoi pas juste utiliser celles de Google ?

Tu crois que ça sera encore là dans 6 mois ?

OK, mais est-ce que quelqu’un fait du hosting pour ça ? J’ai pas la foi d’héberger mon bordel moi-même.

– Et bien, Amazon a ECS, mais il faut écrire du XML et 2, 3 merdes.

Et OpenStack ?

– Beurk.

Beurk ?

– Beurk.

Écoute, j’ai vraiment pas envie d’héberger tout ça.

– Na, c’est super simple. Tu te setup juste un cluster Kubernetes.

J’ai besoin d’un cluster ?

– Un cluster Kubernetes. Ça gère le déploiement de tous tes services.

J’ai seulement un service.

– Qu’est-ce que tu racontes. Tu as une app non? donc tu as bien au moins 8-12 services ?

Quoi ? Non. Juste une app. Service, on s’en branle. Juste un truc.

– Non, jette un coup d’oeil à la notion de microservices. C’est le futur. C’est comme ça qu’on fait tout de nos jours. Tu prends ton app monolithique et tu la divises en quelque chose comme 12 services, un pour chaque tâche.

Ça semble excessif.

– C’est le seul moyen de s’assurer que c’est fiable. Ainsi si ton service authentification tombe…

Service authentification ? J’allais juste utiliser une gem que j’avais déjà mis en place plusieurs fois avant.

– Super. Utilise la gem. Mets la dans son propre projet. Fous une API RESTful par dessus. Et fait en sorte que les autres services utilisent cette API et gèrent gracieusement les échecs. Mets ça dans un conteneur et push le bordel en déploiement continu.

Ok, donc là j’ai une douzaine de services ingérables, et maintenant ?

– Ouais, d’où Kubernetes. Il orchestre tes services.

Orchestre ?

– Ouais, donc tu as ces services, ils doivent être fiables donc il t’en faut plusieurs copies. Donc Kubernetes s’assure que tu en as assez, et qu’ils sont distribués à travers de multiples hôtes dans ta flotte de serveurs, afin qu’ils soient toujours disponibles.

Ah parce qu’il me faut une flotte maintenant ?

– Ouais, pour la fiabilité. Mais Kubernetes la gère pour toi. Et tu sais que Kubernetes ça marche vu que Google l’a fabriqué et que ça tourne sur etcd.

C’est quoi etcd ?

– Une implémentation de Raft.

OK, c’est quoi Raft.

– C’est comme Paxos.

Putain, jusqu’où ça va le terrier du lapin blanc là ? Je veux juste lancer une app. Arf. Bordel, Ok, on respire. Fiou. Ok, donc Paxos c’est quoi ?

– Paxos c’est ce très vieux protocole de consensus distribué des années 70 que personne ne comprend ou n’utilise.

Super, merci de m’en avoir parlé. Et donc Raft ?

– Comme personne ne pige Paxos, y a ce mec, Diego…

Oh, tu le connais ?

– Non, il travaille a CoreOS. Bref, Diego a créé Raft pour sa thèse de doctorat, car Paxos était trop compliqué. Futé le gars. Et il a écrit etcd comme implémentation, et Aphyr a dit que c’était pas de la merde.

C’est quoi Aphyr ?

– Aphyr est le mec qui a écrit Call Me Maybe. Tu vois, le mec spécialiste des systèmes distribués et du BDSM ?

WUT ? BDSM ?

– Ouais, BDSM. C’est San Francisco hein, tout le monde est à fond dans les systèmes distribués et le BDSM

Hum, OK. Donc il a écrit cette chanson de Katy Perry ?

– Nan, il a écrit des posts sur son blog comme quoi toutes les databases n’atteignaient jamais le CAP.

C’est quoi le CAP ?

– Le théorème CAP. Ça dit que tu peux avoir des données consistantes, disponibles et tolérantes au partitionnement, mais qu’il faut choisir 2 de ces caractéristiques sur les 3.

Ok, et donc toutes les bases de données foirent CAP. C’est à dire ?

– Ça veut dire qu’elles sont à chier. Comme Mongo.

Je pensais que Mongo scalait ?

– Ben personne d’autre ne le pensait.

Ok, et etcd.

– Ouais, etcd c’est un système de stockage de clé/valeur distribué.

Oh, comme Redis.

– Non, rien à voir. etcd est distribué. Redis perd la moitié de ce que tu écris en cas d’échec réseau.

Ok, donc c’est un système de stockage de clé/valeur distribué. Pourquoi c’est utile ?

– Kubernetes setup par défaut un cluster de 5 nodes et utilise etcd comme bus de transport de messages. En combinaison avec quelques services de Kubernetes lui-même, ça fournit un système d’orchestration assez résilient.

5 nodes ? J’ai une app. Combien de machines je vais devoir prendre pour tout ça ?

– Et bien tu vas avoir environ 12 services, et bien sûr il te faut des copies de chaque pour la redondance, quelques load balancers, le cluster etcd, ta base de données, et le cluster kubernetes. Je dirais peut-être 50 conteneurs.

WTF ?!

– Aucun problème ! Les conteneurs sont vraiment efficaces, donc tu peux les distribuer sur genre, 8 machines. C’est pas incroyable ?

C’est une manière de voir les choses. Et avec tout ça, je vais être capable de simplement déployer mon app ?

– Yep. Je veux dire, la question du stockage est toujours en suspend avec Docker et Kubernetes, et la partie réseau va demander un peu de travail, mais techniquement, tu es à 2m du bol de sangria.

Je vois. Ok, je pense que j’ai pigé.

– Super !

Merci pour l’explication.

– No problem.

Laisse-moi faire un résumé pour voir si j’ai bien tout compris.

– Bien sûr !

Donc j’ai besoin de diviser mon app CRUD toute simple, en 12 microservices, chacun avec leur propre API qui s’appellent les uns et les autres, mais qui gèrent les erreurs de manière résiliente, les mettre dans des conteneurs Docker, lancer une flotte de 8 machines qui sont des hôtes Docker tournant sous CoreOS, les orchestrer avec un petit cluster Kubernetes qui tourne avec etcd, me démerder avec la question du réseau et du stockage, et je fais tout ça en déploiement continu pour de multiples copies redondantes des microservices de ma flotte. J’ai bon ?

– Yep ! C’est pas fabuleux ?

Je retourne sous Heroku.

En relisant l’article, je réalise deux choses :

• Putain il en faut des références rien que pour comprendre la blague. Plein de devs ne savent même pas ce qu’est Heroku.
• Et franchement cette parodie est vraiment gentille, dans la réalité cette stack pose beaucoup d’autres problèmes : il y a plus de trucs que ça, ça s’emboîte mal, les versions changent, la doc est merdique, faut former les nouveaux arrivants car personne ne connaît ces technos, y a plein de roues à réinventer, il faut un temps fou pour choisir les briques technos, etc. Mais on peut aussi utiliser Docker très simplement, avec un image, à la main, sous Ubuntu. C’est presque simple et pratique.