Gestion multicloud

« Multicloud » est souvent employé comme terme stratégique — une raison de se diversifier au-delà d'un seul fournisseur, de négocier de meilleurs tarifs, ou de satisfaire une exigence de résidence des données. La gestion multicloud est la couche opérationnelle, plus étroite, qui se trouve sous cette stratégie : les outils et les processus qui permettent à une équipe infrastructure de réellement faire tourner des charges de travail chez plusieurs fournisseurs sans traiter chacun comme un chantier séparé. Sans elle, « multicloud » signifie en pratique une console, un jeu d'identifiants et une terminologie différents pour chaque fournisseur, et aucun endroit unique pour répondre à une question de base : quelle infrastructure existe actuellement, et qui l'a modifiée en dernier.

Chaque fournisseur propose sa propre console, son propre CLI, son propre modèle IAM et son propre vocabulaire pour les mêmes primitives sous-jacentes — une machine virtuelle, un groupe de sécurité, une zone DNS, un volume de stockage. Cette fragmentation est le véritable problème que résout la gestion multicloud. Elle commence par la découverte : connecter un compte fournisseur et voir immédiatement un inventaire de ce qui y tourne déjà, avant toute migration ou modification. À partir de là, elle applique un workflow cohérent aux actions courantes du cycle de vie — provisionnement, démarrage, arrêt, redimensionnement, destruction — quel que soit le fournisseur sur lequel se trouve la ressource. Les implémentations les plus robustes gèrent la configuration en direct et de façon synchrone chez le fournisseur lui-même, plutôt que via une copie mise en cache dans leur propre base de données, de sorte qu'une modification effectuée via l'outil est exactement celle que l'on verrait en se connectant à la console du fournisseur.

La gestion multicloud va au-delà du cycle de vie du compute et couvre les aspects opérationnels qui créent un risque réel dès qu'ils sont incohérents d'un fournisseur à l'autre. Le contrôle d'accès doit fonctionner de la même façon partout — authentification unique (SSO), permissions basées sur les rôles, et élévation soumise à approbation pour les actions sensibles, plutôt qu'un modèle d'identité différent par fournisseur. Chaque changement doit être attribuable, ce qui explique pourquoi une piste d'audit couvrant tous les fournisseurs connectés compte davantage ici que dans une configuration mono-cloud — c'est la différence entre une question à laquelle on peut répondre et une investigation. Et comme le coût de l'infrastructure est l'une des premières choses qui deviennent illisibles d'un fournisseur à l'autre, la visibilité des coûts et la détection d'anomalies doivent se trouver au même endroit que le provisionnement, et non dans un tableur séparé réconcilié une fois par mois. De nombreuses équipes exploitent aussi une infrastructure qui n'est pas du tout cloud — serveurs on-premise ou bare-metal — et attendent que la même discipline de surveillance et de correctifs s'y applique également.