Sujet légitime de préoccupation dans une stratégie de transformation cloud, la question de la réversibilité mérite d’être une étape à part entière de la réflexion que doit avoir une entreprise, détaille notre chroniqueur Benito Diz dans ce nouvel article de sa série consacrée au Move-to-Cloud.

Dans mon précédent article de cette série de chroniques consacrée au Move to Cloud, nous avons détaillé l’étape clé de la création du socle technique et notamment d’un datacenter virtuel. Il est dès lors temps de s’intéresser à un point qui est souvent discuté quand il est question de transformation cloud : la réversibilité.

En la matière, une chose est déjà certaine, il n’y aura plus jamais de réversibilité, de retour « on premise » sur des infrastructures privées traditionnelles. Cependant, les hyperscalers proposent aussi leurs infrastructures sur les sites des clients avec des offres telles qu’Azure Stack, AWS Outposts ou même VMware (en mode SDDC – avec quelques limitations-) ; avec de telles solutions, le retour en interne peut être alors envisagé. Dans tous cas, il faut dès à présent penser à la prochaine évolution.

Dès lors, la question se pose de la construction ou de la modification du système d’information pour devenir multifournisseurs de Cloud, et donc d’étudier les grands principes de reconstruction des infrastructures avec les nouveaux services proposés par le nouveau fournisseur.

Le bus de données, l’API gateway et l’interconnexion des services Cloud étant des atouts majeurs de cette évolution.

Il existe cependant des solutions permettant de repositionner les mêmes infrastructures chez des fournisseurs Cloud différents, grâce à des solutions d’abstraction qui permettent de mettre en place un cadre (framework) afin de tout automatiser.

Automatisation et contournements…

Les outils d’abstraction (il ne s’agit pas d’une abstraction qui serait portable chez tous les fournisseurs, mais d’une syntaxe de description commune) tels que Terraform (HCL – Hashicorp Configuration Language), Pulumi (multi-langages), Packer, Ansible , Puppet, Saltstack, ou encore Chef devront alors être installés dès le départ pour permettre la mise en place de ces cadres et de passer à l’aire de l’IaC (Infrastructure as Code) qui grâce à l’orchestration incluse ou non permettent de sécuriser la gestion de configuration.

Outre les services déjà cités, il existe des outils natifs chez les opérateurs de Cloud public tels que CloudFormation, Azure ARM template ou encore Openstack Heat pour OpenStack. Cependant, les ressources restent spécifiques et se limitent aux infrastructures de l’opérateur Cloud et n’offrent donc pas d’aisance de transférabilité.

A lire aussi : Move-to-cloud : quels fondamentaux pour (vraiment) réussir la transformation de l’entreprise ?

Pour conclure, en l’état actuel, l’IaC consiste à mener l’automatisation sur les couches d’infrastructures en utilisant les meilleures pratiques des méthodes de développement logiciel : tests (qualité, sécurité, conformité) et validation, versionnage, documentation by design, déploiement rapide et plus sûr, mise à disposition de catalogues de services… L’objectif de l’IaC est d’assurer une consistance des environnements, de pouvoir répéter les actions de façon identique, de limiter au maximum l’intervention humaine et donc le risque d’erreur, de réutiliser les modèles (patterns) prédéfinis et d’offrir une vision évolutive (scalable) nativement.

Pour s’assurer de la bonne qualité, d’une bonne sécurité et d’une bonne conformité, on trouve aussi des outils de policy as code pour forcer des politiques de conformité et de sécurité dans le code, forcer les bonnes pratiques, et assurer les processus d’intégration continue : Open Policy Agent, Gatekeeper, Kyverno…

Au niveau des applications, il est possible de contourner le système d’exploitation par la mise en place d’un outil d’encapsulation tel que Docker. Cela permet d’installer une sous-couche système permettant d’automatiser le déploiement d’applications et de leurs dépendances dans un environnement dédié.

Et pour finir, disons-le simplement, cette phase de réversibilité doit également prévoir :

• Une transposition des fonctions de sécurité.
• Tous les éléments concernant la protection des données personnelles des autres phases.

Dans ma prochaine chronique, nous détaillerons non pas une mais deux étapes elles aussi particulièrement importante pour une stratégie de Move-to-Cloud : la migration des applications elles-mêmes, et la question des décommissionnements.