Ceci est le second épisode d’une série d’articles décrivant des solutions simples que le cloud apporte à des problèmes compliqués auxquels j’ai été confronté dans ma carrière.
Combien de fois ai-je rencontré, sur le chemin critique d’un nouveau projet, la réalisation du dossier d’architecture, qui précède l’achat et la configuration des infrastructures dédiées à une nouvelle application ? Cette étape était souvent critique, parce qu’il fallait être précis dans l’évaluation des besoins d’un système pas encore développé, et c’était l’occasion de tensions entre les architectes techniques (qui voulaient le maximum de détails et cherchaient à optimiser), les équipes de dev (qui voulaient que ça aille vite), et souvent les sous-traitants (qui avaient une fâcheuse tendance à pousser au sur-dimensionnement pour éviter d’avoir à optimiser le code).
Le cloud ne supprime évidemment pas le besoin d’un travail d’architecte. Simplement, le changement essentiel vient du fait qu’il n’y pas de décision irrévocable, tout peut être modifié au fur et à mesure de l’évolution des besoins applicatifs. On a prévu de faire tourner la base de données sur un serveur 4 coeurs, et on se rend compte que ce serait mieux 8 coeurs ? Pas de problème, on change ; et changer est une opération anodine (en configuration cluster, sans même arrêter la prod !). On veut changer une machine de sous-réseau ? Trois clics ! On veut rajouter un composant pas prévu ? On l’ajoute ! On regrette ? On l’enlève !
Et ça change tout : les décisions n’étant pas irrévocables, n’ayant que des conséquences limitées, peuvent être prises beaucoup plus vite. Et être prises au plus proche de l’équipe. On peut revenir en arrière. On peut tester des idées. Bref, on acquiert une plus grande rapidité et une plus grande liberté d’innovation.
Là où l’étape du dossier d’architecture était une étape cruciale, bloquante, pleine de risque (et in fine facteur de nombreux délais), elle devient un élément du processus normal et continu de conception - développement - intégration. La diminution des risques sur la définition et l’achat des infrastructures constituerait une avancée majeure pour l’Etat dans sa recherche de sécurisation de ses grands programmes informatiques.
On peut aller encore plus loin, ensuite, en mettant en place un processus d’intégration et de déploiement continu conjoint entre le code applicatif et le code qui décrit l’infrastructure ; comme vu dans un post précédent, la description de l’infrastructure, c’est du code ! Donc on peut gérer des modifications d’infrastructure comme on gère des modifications de code, et intégrer cela dans la chaîne de développement et d’intégration continue. C’est ainsi qu’on peut définir des déploiements prêts à l’emploi embarquant conjointement le code applicatif et l’infrastructure, comme on peut en trouver plein d’exemples sur github.