Bienvenue à Google Cloud, Microsoft Azure, Fly.io et compagnie

Début juillet, juste avant les vacances d’été, Docker tenait sa campagne annuelle de lancements. Évidemment, l’IA est sur toutes les lèvres, et l’éditeur entendait bien y trouver sa place en consolidant la fonction d’orchestration de composants que joue déjà Docker Compose. Et c’est ainsi que derrière un titre consacré aux Agents IA, on a découvert que Google Cloud Run sera désormais compatible avec les spécifications Docker Compose, tout comme Azure ou Fly.io.

Pour avoir lancé EcoCompose il y a deux ans maintenant, disons que nous avons la satisfaction d’avoir fait le bon choix et d’avoir seulement attendu d’être rejoint par le marché. Derrière cette anticipation, il y avait une analyse qui reste toujours aussi d’actualité : dans le patrimoine applicatif des organisations comme le ministère qui compte plusieurs centaines de SI, les applications qui nécessitent de distribuer la charge sur plusieurs machines se comptent sur les doigts d’une main. D’ailleurs elles ont toutes le même profil : ce sont des applications bureautiques (messagerie, partage de fichiers SMB, Bnum…), utilisées en continu par des milliers d’utilisateurs. Elles n’ont pas attendu le « cloud » pour construire des techniques de clustering (DFS pour SMB par exemple) et n’ont pas nécessairement besoin de couches d’abstraction supplémentaire. Les autres tourneraient sans difficultés majeures sur votre PC portable. Maintenant on perçoit que la bonne question est « does it scale (down) » et non « does it scale (up), comme certaines ESN essayent encore de nous le faire croire.

Le véritable sujet quand on veut mettre en place une politique de livraison continue dans un but d’efficacité globale, consiste encore et toujours à aligner les environnements de développement de ceux de production. Et force était de constater dès 2015 (même si la technologie a maturé depuis) que Docker Compose était le standard de fait des développeurs, quand bien même certaines barbes grises affirmaient « Docker, c’est pas pour la Prod » (grâce à BSD, on sait aussi qu’il n’y a pas que Docker dans la sphère Unix 😀).

La preuve est que le manuel parodique du saboteur de DSI liste spécifiquement dans son plan d’actions :

• Make sure production environment differs from developer environments in as many ways as possible.
• Encourage a complex dev setup : running a service mesh with a dozen services at a minimum.
• Insist on adding abstraction layers on top of everything. Use vendors that are themselves abstractions and then add extra layers of abstractions.
• Encourage technical decisions based on wildly optimistic expectations of scale. Plan for at least 3 orders of magnitude more load than you have.

Aussi c’est déjà un petit plaisir de voir les premiers promoteurs du « Cloud Native » et de Kubernetes jusqu’au poste des développeurs commencer à mettre de l’eau dans leur vin. Cette version du fameux « shift left » du « DevSecOps » consiste à créer des contraintes chez les voisins, les développeurs. Sauf qu’en plus les benchmarks montrent que c’est un gâchis de ressources : chaque nœud « kubernetisé » a besoin au strict minimum de 1 Go juste pour ses fonctions de gestion. Un giga prête à sourire sur une machine mais quand cela s’impose sur tout un parc d’instances qui se comptent en millier, on connaît les conséquences pour avoir déjà donné dans le déploiement d’ElasticSearch il y a 10 ans ou constaté les effets de certains anti-virus sur nos PC : il n’y a pas de quoi être fier du bilan écologique et avoir envie de reproduire les mêmes causes.

Dans un autre contexte mais selon une dynamique analogue, il y a quelques semaines un distributeur majeur de services Microsoft s’efforçait de nous convaincre d’acheter et après avoir longuement choisi ses mots, a explicitement comparé leurs SaaS à une Rolls et nos services existants à une 2CV. Au delà de l’espérance d’un certain tact, on aurait préféré une référence à la R4L car celle-ci a su se moderniser et passer à l’électrique, tout en gardant la simplicité qui a fait son succès. Et nous savons moderniser nos pratiques dans nos salles serveurs. Par exemple, sans utilisation d’autre chose que des paquets Open Source associés à Debian, nous avons fait le 7 février dernier en webinaire DNUM la démonstration de notre capacité à démarrer à froid une instance Linux (Ubuntu, Alpine…) en moins d’1s grâce à un usage considéré de conteneurs systèmes, de btrfs et de disques SSD. Visiblement, tous les IaaS « clouds » ne peuvent en dire autant. Cela peut paraître un détail mais quand il s’agit d’optimiser sa chaîne de compilation et intégration, ses détails comptent et souvent c’est dans les vieux pots qu’on fait les meilleures confitures.

Bienvenue à tous dans le monde des Pros du numérique, les mécanos des R4L du 21e siècle.

_{L’illustration a été générée à l’aide d’une intelligence artificielle}