Comment mettre en place une gouvernance multicloud ?
A l'heure de la montée en flèche du télétravail dans le sillage du Covid-19, les entreprises boostent leur migration vers le cloud. "La pandémie a joué un rôle de catalyseur mi-2020", observe Forrester. Le cabinet d'études anticipe dès lors une hausse de 35% du marché du IaaS en 2021, à 120 milliards de dollars. "La tendance sera tirée par la demande en développements containérisés dans une optique multicloud", indique Dave Bartoletti, vice-président et analyste principal du groupe américain. Et Karine Picard, country manager France d'Oracle, de constater : "Désormais, la question ne se pose plus. Les grandes entreprises s'orientent toutes vers plusieurs acteurs." L'objectif ? Eviter le vendor lock-in tout en se donnant la liberté d'opter au fil des projets pour des fournisseurs différents en fonction de leurs points forts. Reste à savoir quelle gouvernance adopter pour maîtriser les choix, les coûts, et leur alignement sur la stratégie de l'entreprise.
Choisir un cloud prépondérant
Même si l'entreprise se déploie déjà sur plusieurs clouds compte tenu de géographies et de problématiques numériques multiples (data, IA, IoT...), elle gagnera à faire le choix au départ d'un cloud public prépondérant. "Les équipes IT se familiariseront ainsi avec une première offre, ses concepts, son fonctionnement, ses modes de plateformisation, avant de s'étendre à une deuxième, puis éventuellement une troisième. La courbe d'apprentissage sera plus simple", souligne Romain Charles, business development manager au sein de Devoteam Revolve, branche de l'ESN du même nom spécialisée dans le cloud.
De la cybersécurité au pilotage opérationnel en passant par la gestion financière (ou FinOps), un cadre de gouvernance sera d'emblée défini dès le premier cloud choisi, puis élargi aux clouds venant ensuite. "Globalement, il s'agit de s'assurer que les services managés retenus, leur dimensionnement et leur configuration sont en cohérence avec les applications et traitements métier qu'ils sont amenés à prendre en charge, et notamment avec leur niveau de criticité", résume Guillem Pelissier, directeur de la practice Cloud Enterprise Solutions d'Atos en France.
Structurer les droits d'accès
Première étape du chantier : la mise en place d'un IAM (pour identity access management) structuré. L'enjeu ? Aboutir à un mode d'authentification unique de l'utilisateur quelle que soit la plateforme cloud. Dans cette optique, l'annuaire d'entreprise est évidemment mis à contribution pour gérer les politiques de connexion en fonction des rôles et profils métier. Ensuite, des landing zones permettront de définir des bulles réseaux dédiées à tel ou tel organisation / environnement. Elles s'adosseront à des VPC sur le cloud d'Amazon et des VNet sur celui de Microsoft. Ces bulles pourront héberger elles-mêmes des sous-réseaux. La finalité étant d'isoler les différents types d'environnement (développement, test, recette, production) pour des organisations métiers spécifiques (marketing, manufacturing...) en vue de segmenter les droits d'accès à ces derniers. A chacun sera associé une unité d'organisation attitrée. "On ne raisonne pas technologie mais fonctionnel", synthétise Romain Charles.
A chaque cas d'usage sa configuration
A chaque environnement correspondra des configurations cloud différentes. "Les instances seront par exemple plus musclées pour la production et la pré-production, qui doit pouvoir supporter les tests de charge de trafic en amont du déploiement", souligne Didier Pavy, consultant cloud au sein de Devoteam Revolve.
Les données et briques logicielles soumises à des réglementations ou critiques d'un point de vue business pourront faire l'objet de landing zones et d'unités d'organisation particulières. Mais aussi se voir appliquer des dispositifs de sécurité renforcés : un chiffrement de bout en bout par exemple, avec au besoin une gestion des clés de cryptage directement prise en charge par l'entreprise utilisatrice, et pas déléguée au provider, pour s'assurer que même ce dernier n'accède pas aux data.
Des tags pour le FinOps et l'automatisation
Autre bonne pratique, le tagging. Il s'agit d'un moyen de regrouper les ressources cloud par catégories pour en automatiser la gestion. Cet étiquetage permet aussi d'affecter chaque ressource à un centre de coûts, en les rattachant à un projet ou une organisation métier. Dans le cadre d'une gouvernance multicloud, il est recommandé d'adopter une stratégie de gestion du tagging commune pour l'ensemble des clouds.
Sur le terrain du FinOps, mieux vaut dans un premier temps se familiariser avec les outils proposés par les clouds sélectionnés. Passer d'une logique de dépenses d'investissement à une gouvernance financière basée sur des dépenses d'exploitation implique une courbe d'apprentissage, la facturation à l'usage offrant l'opportunité d'optimiser les coûts de manière plus réactive. "Ce qui passe par une analyse fine de sa consommation sur les différentes plateformes au regard des évolutions permanentes des providers en matière de pricing", argue Didier Pavy. Un tel pilotage implique en outre de décentraliser le contrôle des paiements au plus proche des responsables métiers des projets et applications, ces derniers étant les mieux placés pour réaliser ce pilotage financier.
S'équiper d'une tour de contrôle multicloud
Aux côtés de la gestion financière, les ténors du cloud sont également tous équipés d'outils de monitoring des ressources, de leur performance, de leur sécurité... "A l'instar du FinOps, mieux vaudra commencer à maîtriser les données d'observability relatives à chaque plateforme compte tenu de leurs spécificités. Ce qui permettra ensuite de mieux appréhender le gestion globale", poursuit Didier Pavy.
Guillem Pelissier chez Atos conseille de retenir un produit du marché pour chaque problématique de supervision. Pour mesure la disponibilité et la performance des services, on pourra s'orienter vers AppDynamics, Datadog ou Dynatrace, pour la gestion de logs vers Splunk. "Quant à CloudHealth (édité par VMware, ndlr), il offrira une transparence globale en matière de FinOps quel que soit le cloud", complète Guillem Pelissier. "Les responsables métiers, du marketing à la logistique, auront ainsi la possibilité de visualiser les bénéfices tirés de leurs coûts au fur et à mesure."
"L'infrastructure as code décrit de manière standard l'ensemble des processus de mise en œuvre"
Didier Pavy chez Devoteam pondère : "Les produits de FinOps multicloud masquent certes la complexité des environnements, mais ils n'intègrent pas les dernières fonctionnalités ou mode de pricing proposés par les providers, qui évoluent constamment. Du coup, ils n'offrent pas le même niveau de finesse que les solutions natives des fournisseurs." Même logique pour les brokers de cloud ou les cloud management platform (CMP). "Ces systèmes qui masquent la complexité des offres ne peuvent pas suivre le rythme d'innovation des PaaS. Du coup, ils se traduisent par un niveau de granularité nettement moins fin", constate Didier Pavy.
Guillem Pelissier le reconnait : "Les CMP ne sont pas la solution." Mieux vaut, selon lui, définir soi-même un catalogue de services et de configurations cloud évolutif et modulable.
Partant de là, les consultants de Devoteam recommandent également de bâtir une couche d'analyse de données plus flexible. Dans cette logique, les flux financiers gagneront par exemple à être intégrés à un outil de business intelligence en self-service. Une application qui permettra aux chefs de projet et contrôleurs de gestion de suivre les dépenses les concernant en bâtissant eux-mêmes leur tableau de bord à partir des data souhaitées. Avec à la clés la possibilité de faire des croisements avec des données métiers de l'entreprise, en vue par exemple de comparer coûts additionnels cloud et revenus générés. Aux côtés de la BI, la pile open source ELK (associant Elasticsearch, Logstash et Kibana) sera idéale pour traiter et visualiser les logs, et le couple Grafana /Prometheus pour récupérer des métriques, avec des seuils d'alerte, et les exposer sous forme de tableaux de bord.
Standardiser le delivery
En matière opérationnelle, un pipeline d'intégration et de livraison continues (CI/CD), avec une logique d'l'infrastructure as code (IaC) basée sur Terraform, présentera pour avantage de standardiser les déploiements quel que soit le cloud. Mise en production, gestion de dépôts de code source, gestion de versions...
"L'IaC décrit de manière standard l'ensemble des processus de mise en œuvre, jusqu'aux typologies de services cloud à utiliser en fonction des catégories de données et d'applications, de leur criticité, de leur degré de confidentialité", explique Didier Pavy. "Les process opérationnels, financiers, de sécurité seront ainsi intégralement documentés de manière codée, ce qui assure une traçabilité et un contrôle de leur conformité a postériori." De la gouvernance à l'audit, il n'y a qu'un pas.
Retrouvez toute les articles de notre semaine spéciale cloud.