Nous vivons une belle époque !
Nous allons changer de Président, la Réalité Virtuelle devient une réalité pas seulement virtuelle et les développeurs peuvent avoir une machine connectée au réseau en moins d’une semaine. Je ne m’étendrai pas sur les deux premiers sujets, mais le troisième propos revêt une importance fondamentale pour nous.
Dans un monde de DevOps
A l’instar des GAFA dont les cycles de développement sont devenus extrêmement courts et se chevauchent par centaine. Le déploiement de nouvelles builds atteignent des fréquences jamais vues auparavant. Il est aujourd’hui difficile d’imaginer abandonner nos usines numériques (AKA le Cloud) pour revenir à un système de ticketing. L’ITSM est dépassé, écrasé par la pression de la livraison de fonctionnalités auxquelles font fasses les sociétés qui ont compris l’enjeu du Digital dans leur business. L’Homo-ITILus est mort, vive l’Homo-DEVOPSus !
Dans le monde DevOps, sur lequel nous reviendrons plus largement dans un prochain article, à l’image des mondes de la robotique d’Aldous Huxley, les lois sont nombreuses, mais en bonne place figurent celles-ci :
- Avec le Configuration Management tes serveurs tu déploieras.
- Ton code via l’Intégration Continue tu pousseras.
Pour une organisation DevOps ces outils sont critiques. Ils permettent pour l’un de gérer l’Infrastructure As a Code, donc le déploiement automatisé des ressources matérielles (ou virtuelles) et la configuration des systèmes pour ensuite accueillir le code. L’outil d’intégration continue lui se charge généralement de l’intégration du code de tous les développeurs, de l’automatisation de la configuration, de la compilation et du déploiement du code sur les serveurs. Comme toute architecture, ces rôles sont bien souvent découpés sur de nombreux serveurs selon les besoins du logiciel, de l’échelle et de l’organisation concernés.
J’ai coutume de dire : « Tout Ops qui a poussé son code sur un Version Control System (VCS) fait du Dev et à l’inverse, tout Dev qui a regardé et réagi à une alerte fait de l’Ops ». C’est l’âge de pierre du DevOps. Avec l’Intégration Continue et le Configuration Management, on invente l’ère du feu. Bien utilisé nous en arrivons donc à un point ou personne ne se connecte plus sur les serveurs en fonctionnement. Qui a dit SSH ? Remote Desktop ? Nous démarrerons ces services lorsqu’il faudra diagnostiquer une panne matérielle !
Sur le terrain
Ceci prend encore un sens d’autant plus réel lorsqu’une technologie de container est utilisée. Ces containers apportent des niveaux de sécurité largement accrus de par leur immutabilité. Cela signifie également qu’il faut absolument en déporter la configuration sur d’autres médiums.
Pour exemple, nous avons créé pour nos besoins métiers un pipepline d’IT Operations Analytics. Cette architecture et ses nombreux composants prend environ une semaine à s’installer avec un ingénieur aguerri et dans compter les aspects réseau. Intégré avec le CM et le CI, le déploiement prend environ 15 minutes. Toutes les configurations sont stockées dans un repo central. Les fichiers sont édités puis soumis pour merge via un logiciel de gestion de version. Personne ne s’est jamais connecté sur les containers de production. Nous sommes ici dans un exemple d’infrastructure as code.
Et pour le legacy me direz vous ? Aucun souci, quasiment tous les logiciels peuvent être orchestrés plus ou moins facilement. Cela releve plus de la qualité de conception du logiciel que de la jeunesse de celui-ci. J’ai en tête quelques exemples de logiciels qui sont récents mais très difficiles à automatiser de par leur conception. Une chose est certaine, il n’est pas nécessaire d’avoir concu un projet avec ces préceptes en vue. En revanche il est bien souvent nécessaire de redéployer la production avec ces nouveaux moyens pour en valider le fonctionnement de bout en bout.
Un point n’a pas été abordé ici : l’automatisation de la configuration continue (CCA) qui permet de gérer les descripteurs des étages de développement ou des sites multiples entre autre (dev, test, build, recette, qualif, preprod, prod,…). Peut être l’objet d’un prochain article ?
