It Runs on My Cluster - I -Introduction

I -🔥 Introduction

Mon parcours dans l'informatique a démarré, il y a maintenant 15 ans, les mains sur un clavier à écrire des lignes de codes, que ce soit en Java, en C, en Javascript ou dans un certains autres nombre de langages plus exitant les uns que les autres. C'était avec joie que je faisais touner mon war, jar, tar sur mon PC avec Eclipse mais lorsque je souhaitais livrer sur un environnement distant et partagé, c'était le stress ! Est-ce que ça va fonctionner ? Comment livrer sur mon Tomcat 🐱 et avec quels paramètres ? Tout cela pour avoir les mêmes discussions avec les collègues "Ça fonctionne sur ma machine 💻"...

À cette époque, je ne connaissais pas encore les conteneurs, je n'avais même pas idée de ce que c'était mais il y avait déjà eu une première révolution depuis quelques années : Les machines virtuelles (VM). C'était déjà un grand pas en avant et ça me permettait de tester et casser cette VM pour comprendre comment fonctionnait mon application dans un environnement qui ressemblait un peu plus à une production. C'était un bon début, mais ce n'était pas toujours simple d'avoir accès à une VM qui avait la même configuration que ma production et surtout je faisais encore beaucoup de choses à la main.

Quelques années passèrent où j'appris plus en profondeur le fonctionnement des applications Java ☕ sur du middleware Tomcat mais j'avais un autre problème, mon application avait besoin d'une base de données, d'un front en AngularJS (la belle époque, ou pas 😛) et parfois même d'autres applications ou modules tiers. Alors comment faire pour tester ma feature fraichement développée quand trois autres devs voulaient faire de même? C'est simple, on testait tout en même temps et sur un seul et même environnement (merci aux gestionnaire de version de code et merci Jenkins 😉). "Attention ne pas toucher aux données pendant les tests", ça c'était mon quotidien.

Le gros événement du mois, du trimestre voir de l'année, c'était la mise en production. Là attention, on a un super chronogramme de 65 étapes avec 13 équipes sur 4 heures donc tout est prêt. Eh PAF! Ca ne fonctionne pas et on doit trouver le pourquoi du comment (un espace dans une JNDI, une librairie manquante sur la machine, une version de Tomcat différentes et j'en passe).

Voilà pourquoi quelques années plus tard Docker et ensuite Kubernetes m'ont obsédés, une promesse d'automatisation, de "simplicité" dans la description des environnements, des livraisons qui s'annoncent simples, rapides et sans douleur! C'est tout cela qui m'a donné envie d'expérimenter, de tester ces technologies en entreprise. Pour avoir testé, j'ai testé, j'ai surtout eu des sueurs froides, des doutes et au fur et à mesure des convictions. C'est tout cela que je vais vous décrire dans cette série de posts intitulée It Runs on My Cluster.