Maintenant que le DevOps est devenu la référence des DSI, il convient d’évaluer comment l’infrastructure va pouvoir supporter cette nouvelle approche et c’est là que l’Infrastructure As Code entre en jeu. Qu’est-ce que l’Infrastructure As Code ? Un IaC est une façon de gérer et provisionner les ressources informatiques dans les datacenters au sens large au travers
Maintenant que le DevOps est devenu la référence des DSI, il convient d’évaluer comment l’infrastructure va pouvoir supporter cette nouvelle approche et c’est là que l’Infrastructure As Code entre en jeu.
Qu’est-ce que l’Infrastructure As Code ?
Un IaC est une façon de gérer et provisionner les ressources informatiques dans les datacenters au sens large au travers de processus automatiques.
Ceci comprend à la fois, la fourniture de ressources physiques, de ressources virtuelles et la configuration de ressources associées. Cela permet aussi de pouvoir répéter à l’infini la même procédure d’approvisionnement et d’avoir toujours exactement le même résultat.
Le IaC est le complément naturel du DevOps puisqu’il va permettre d’intégrer l’infrastructure naturellement dans le processus Ops tout en ajoutant une facilité d’utilisation (avec les APIs), une qualité de service (suppression des actions humaines) et une vitesse d’exécution.
A l’image du DevOps, le IaC a pour objectif de réduire, voire de supprimer le frein au business lié aux processus de fournitures de ressources de l’infrastructure.
On considère que le IaC est apparu avec les offres Cloud public qui par essence devaient proposer quelque chose de nouveau répondant à de nouvelles attentes des métiers vis-à-vis de l’informatique. Cette réponse a été d’offrir des services standardisés et automatisés répondant immédiatement aux demandes des utilisateurs. Tout ceci associé à des portails industriels APIsables pour intégrer les processus du IaC directement dans les développements métiers.
Le IaC pour qui ?
Comme nous l’avons vu, à l’origine le IaC répondait aux besoins de mise à disposition rapide de ressources.
Ainsi, les premiers utilisateurs du IaC ont été les sociétés du Web qui cherchaient de la variabilité, de l’adaptabilité immédiate et fiable aux aléas du marché. Ainsi, les places de marchés et les réseaux sociaux ont eu immédiatement besoin de cette réactivité pour augmenter ou réduire la puissance. Mais aussi, pour ouvrir de nouvelles plateformes sans pour autant faire varier la qualité de service perçue par l’utilisateur.
L’avantage pour ces sociétés était la facilité de mesure des gains associés aux IaC (le Web intègre nativement des compteurs d’utilisation en temps réel).
Les nouveaux utilisateurs du IaC sont maintenant les entreprises qui ont intégré le DevOps dans leur ADN et dans lesquelles l’infrastructure doit suivre le mouvement sans être un frein ou une finalité en soi.
Le seul problème dans ces nouveaux usages provient de l’unité de mesure permettant de définir les gains associés au IaC et c’est là que nous touchons au point majeur de l’entreprise : Le ratio gains vs coûts.
En effet, au-delà des avantages réels d’avoir une infrastructure « agile » capable de s’adapter aux nouveaux usages, y-a-t-il un ROI associé ?
Il n’y a pas de réponse unique et binaire comme souvent dans l’informatique. Il est évident que mettre en place une Infrastructure As Code implique un coût initial et récurrent important.
> Le coût initial, car il faut, soit repenser toute son infrastructure pour la normaliser (passer du SICOB pour les plus anciens à une infrastructure totalement virtualisée avec des réseaux étendus et des datacenter sanctuarisés) ; soit basculer tout son SI dans le Cloud Public. Dans tous les cas, il y a un travail important de replateforming applicatif et métier.
> Le coût en récurrent, car qui dit IaC dit développement et donc MCO du développement. Il faut aussi travailler sur la plateforme et sur son adaptabilité permanente pour anticiper les nouveaux besoins.
La réponse dépend alors de la nécessité de l’infrastructure selon les besoins du métier. Ainsi, suivant la variabilité et le besoin de réactivité du métier, le IaC sera plus ou moins rentable.
Un métier lié par exemple à l’industrie qui gère des entrées/sorties de stocks et le suivi de production aura un plus faible intérêt au IaC car son SI est plus statique. En effet, ce dernier est lié à des infrastructures métiers lourdes dont la variabilité est plus limitée.
A contrario, un métier de services en ligne va avoir besoin du IaC par essence pour accroître ou réduire sa puissance (donc son coût) et être très dynamique dans son évolution permanente pour rester à l’écoute de ses clients
Le IaC est-il finalement nécessaire ou est-ce un faux problème ?
Comme nous l’avons vu précédemment le IaC apporte de la flexibilité, de l’adaptabilité, de la qualité et de la rapidité d’exécution. Alors oui, le IaC est nécessaire, voire indispensable pour répondre aux nouveaux besoins métiers et pour s’intégrer dans la démarche DevOps.
Le IaC n’est pas un faux problème, il doit être pris en compte dans l’évolution de l’informatique des entreprises comme l’ont pu l’être la virtualisation, l’Internet ou encore le IaaS il y a quelques années.
Il convient juste d’intégrer le IaC sur les bons métiers et pour de bons besoins, tout en se posant les bonnes questions en amont :
1. Mon infrastructure est-elle compatible avec le IaC ?
2. Quel niveau de sécurité je souhaite avoir ?
3. Comment exploiter et maîtriser mon infrastructure aujourd’hui et quels vont être les impacts du IaC sur ma production ?
4. De quelles ressources vais-je avoir besoin pour le IaC vs les infrastructures et équipes en place ?
5. Comment vais-je gérer ce changement et comment vais-je faire communiquer le IaC avec le reste de mon SI ?
6. Quel sont les gains métiers attendus que le IaC va couvrir ?
A partir de cela, le IaC s’intègre dans l’infrastructure de l’entreprise comme une nouvelle source de moyens qui s’intégrera naturellement dans le SI, dans l’exploitation et la production.
