Lorsque les entreprises créent et exploitent des applications de manière native sur le cloud, elles se donnent les moyens de répondre plus rapidement aux besoins des clients. Une application ‘Cloud Native’ est une application conçue et pensée pour le Cloud. Architecturée éventuellement sous forme de Microservices, elle peut alors être intégrée et déployée par de petites équipes de développement dédiées à un service spécifique. Cela permet de créer des applications capables d’évoluer ensuite plus rapidement. C’est aussi le moyen d’opérer une transition itérative des anciens services vers des plateformes plus modulaires orientées services.

Cependant, le développement d’applications Cloud Native suppose quelques prérequis et notamment :

• L’utilisation d’APIs pour améliorer le découplage des applications et donc leur évolutivité
• La mise en place éventuelle de conteneurs pour faciliter la portabilité vers différents environnements dans le cas d’un besoin ‘Multi-Cloud’.

Le développement cloud natif permet également de réduire considérablement le délai de transition d’une technologie à une autre dans le cadre d’une modernisation future en l’abordant service par service.

Cette approche implique néanmoins la mise en place de méthodes agiles alignées sur les principes de DevOps.

La démarche DevOps permet de rapprocher les opérations de développement et de production en entreprise tout en alignant les équipes, les outils et les processus. L’objectif à la clé : améliorer le délai de mise en production, réduire les coûts informatiques et mieux répondre aux besoins métiers par une boucle de rétraction plus rapide.

Au-delà des outils et des méthodes certes importants, DevOps c’est un changement de culture professionnelle profond et un état d’esprit. La livraison et le déploiement continus (chaine CICD) permettent aux développeurs d’être plus autonomes, moins dépendants de délais de déploiement tiers et davantage responsabilisés.

En outre, ces étapes de génération et de publication automatisées du logiciel lui-même permettent de garantir un code cohérent et stable. Mais comment approvisionner les environnements Cloud sur lesquels ces systèmes s’exécutent ? En effet, si l’adoption de l’automatisation et des outils associés pour limiter les processus manuels est essentiel pour mener à bien une démarche DevOps au niveau du logiciel, l’infrastructure n’échappe pas à cette règle.

IaC : appliquer les bonnes pratiques DevOps à l’Infrastructure

L’Infrastructure as Code (IaC) est la gestion de l’ensemble de l’infrastructure (réseaux, machines virtuelles ou physiques, ressources réseaux…) via des scripts qui utilisent le même contrôle de version que celui utilisé par l’équipe Dev pour le code source. L’objectif de l’IaC est d’optimiser le déploiement de ressources informatiques quelle que soit, dans la mesure du possible, la nature de cette ressource.

IaC est donc le fait d’appliquer les bonnes pratiques DevOps à l’infrastructure de sorte qu’elle soit automatisée, cohérente et reproductible.

En appliquant les mêmes tests et le même contrôle des versions au code de l’infrastructure, celle-ci peut passer par le même pipeline CI/CD que l’application lors de son développement, comme le précise Luc Fournier, Consultant Architecte Cloud chez SoftFluent

C’est à mon sens lors de la mise en place d’une démarche DevOps une source importante d’optimisation (matérielle, financière, temporel) dans la gestion des infrastructures informatiques (machines physiques ou virtuelles, gestion des conteneurs, ressources réseaux, …) et des configurations

Infrastructure as Code : les avantages sont nombreux

Qualité : en réduisant le nombre d’erreurs et d’incohérences liées aux déploiements manuels

Gain de temps :

• La possibilité d’appliquer le même processus de déploiement à l’ensemble des environnements, y compris à l’environnement de production. L’IaC génère le même environnement chaque fois qu’il est utilisé
• Les développeurs sont délestés de la plupart des tâches d’approvisionnement. Ils n’ont plus qu’à exécuter un script pour que leur infrastructure soit opérationnelle.
• Les administrateurs système n’ont pas à gérer les processus manuels chronophages
• Les déploiements applicatifs ne sont pas retardés pour cause d’infrastructure pas prête

Encore plus de rapprochement entre les équipes, ce qui va dans le sens d’une approche DevOps :

• Les équipes de développement et l’équipe d’exploitation sont obligés de se mettre d’accord sur la manière de déployer les applications ou de configurer les environnements
• Elles peuvent utiliser la même description du déploiement des applications
• La frontière entre le code qui exécute des applications et le code qui configure l’infrastructure étant de plus en plus ténue, les équipes de développement et systèmes d’exploitation se partagent progressivement les responsabilités

Comme le précise Luc Fournier Consultant Architecte Cloud

C’est surtout un point central de convergence entre les besoins des Ops et des Devs et une véritable occasion de créer une collaboration :

• Ils peuvent partager un besoin et le décrire au travers d’un langage commun (exemple YAML) -> Amélioration de la communication entre les membres de l’équipe et également source de documentation (doc = source).
• Stocker dans un référentiel (repository) en versionnant et ainsi suivre les évolutions de leur infrastructure (cartographie, lien CMDB).
• Centraliser l’automatisation (Mise en place d’indicateurs partagés pour suivre la vie des ressources et leurs performances)

D’autres bénéfices, peut-être moins perceptibles sont néanmoins tangibles

Réduire le shadow IT : lorsque les départements IT ne sont pas en mesure proposer des solutions innovantes et utiles concernant l’infrastructure, les collaborateurs se mettent à utiliser des applications informatiques sans approbation explicite pour répondre à leur besoin avec les risques encourus : pas ou peu d’aval de la DSI, pas de cohérence entre les outils et donc pas de passerelles, aucun support, sans parler de la sécurité

Assurer la conformité aux standards IT de l’entreprise et renforcer la sécurité comme le souligne Luc Fournier, Consultant Architecte Cloud

La mise en place de pratiques d’IaC permet de réduire les risques en termes de sécurité (DevSecOps) et de mieux respecter les règles de gouvernance et de conformité (traçabilité des évolutions (historique)

Faire des économies en jours homme et limiter les risques financiers potentiels. L’IaC supprime également la nécessité d’assurer la maintenance des environnements de déploiement individuels, avec des configurations uniques qui ne peuvent pas être reproduites automatiquement, et garantit que l’environnement de production sera cohérent

Attention cependant :

Comme le DevOps, l’IaC requiert de nouvelles compétences. Une certaine expertise est nécessaire pour maîtriser les outils, et atteindre cette expertise nécessite du temps d’apprentissage et de formation.

Un risque inhérent à l’IaC est celui de la réplication d’erreur. Il est indispensable de tester scrupuleusement le code initial avant de l’appliquer aux autres environnements cibles au risque de répliquer toute erreur en même temps sur plusieurs environnements.

Quels outils d’Infrastructure as Code ?

Parmi les solutions populaires, on peut citer

• Terraform , outil Open Source de HaschiCorp. Terraform permet de provisionner des infrastructures sur différents types de Cloud ou OnPremise : Microsoft Azure, AWS, Google Cloud, VMWare, etc. grâce à des fournisseurs adaptés (provider)
• AWS CloudFormation, utilisant JSON et YAML
• Microsoft Azure ARM Templates (JSON)
• Microsoft Azure BICEP, nouvel outil proposé par Microsoft et spécifique à l’écosystème Azure

Outre ces services/outils, il existe plusieurs autres solutions plus ou moins ciblées sur un besoin particulier: Chef, Puppet, Ansible, Fantoche, Saltstack, Juju, Docker, Vagrant, Palette, CFEngine, etc. Ansible par exemple est plus un outil de configuration, mais il propose des modules permettant d’élaborer des Infrastructures sur un grand nombre de configurations Cloud et OnPremise.