Pourquoi et comment mettre en place une stratégie de cloud hybride ?
Pendant près d'une décennie, les DSI se sont engagés dans des stratégies dites "cloud-first". Objectif : migrer un maximum d'applications existantes vers le cloud public et mener tout nouveau projet dans ce nouvel environnement. L'idée était de profiter de la force du cloud public en matière d'autodimensionnement, mais aussi de ses capacités d'innovation. Dix ans plus tard, les CIO ont fait leur examen de conscience. La politique qui voulait faire du cloud public un choix systématique a laissé la place à une vision médiane.
"On ne peut raisonnablement pas mobiliser des équipes entières pour réaliser des migrations, que ces basculements soient réalisés en mode lift and shift ou via des replateformisations complètes, sans que cela soit pleinement justifié d'un point de vue business", souligne Thomas Sarrazin, global finops offer leader chez Capgemini. Et Alexandre Daudin, directeur d'agence business transformation chez Sopra Steria, d'ajouter : "Certaines organisations, notamment dans les secteurs publics ou bancaires, ne peuvent tout simplement pas se permettre ce type d'opération pour des raisons liées à la confidentialité des données."
Des applications inéligibles au cloud public
Une autre raison se cache derrière ce revirement : Beaucoup de projets de migration vers le cloud ont été réalisés en mode lift and shift, ce qui n'a pas permis de tirer pleinement parti des bénéfices du cloud en termes d'innovation. "Certaines entreprises se sont retrouvées avec des factures plus lourdes qu'auparavant", constate Thomas Sarrazin. La raison de ces hausses de tarifs : les sociétés en question avaient fait l'impasse sur le finops, cette démarche permettant d'optimiser les coûts des services cloud consommés.
Par ailleurs, certaines applications ne sont pas adaptées au cloud public. C'est le cas des progiciels de gestion intégrée (ERP). Ce type de solution fonctionne sans problème dans un environnement internalisé. Il ne fait pas face à des pics de trafic important qui justifierait la scalabilité d'un cloud public. De même, il n'a pas besoin de services particulièrement innovants pour s'exécuter.
Des arguments en faveur du cloud public demeurent évidemment sur le devant de la scène. Ainsi, à l'inverse d'un ERP, tous les systèmes critiques faisant face à des périodes de forts pics d'audience suivies de baisses importantes de trafic sont éligibles. "Si un service original et innovant est disponible sur le cloud public, la question se posera aussi de la pertinence de réinternaliser la prestation sur un cloud privé, avec tous les coûts que cela engendre", complète Thomas Sarrazin. Une perspective qui dans la plupart des cas se révèle irréalisable compte-tenu de la force de frappe des hyperscalers en termes d'innovation.
Une méthodologie de mise en œuvre
Comment mettre en place un cloud hybride ? En termes méthodologiques, la première étape est de réaliser un inventaire du parc applicatif existant en se posant un certain nombre de questions. Quels logiciels sont nécessaires à son business ? Quels sont ceux qui méritent d'être modernisés ? Quels sont ceux qui devraient se voir adjoindre de nouveaux services type PaaS ou SaaS ? Dans chaque cas, il est conseillé d'analyser les contraintes de sécurité, notamment liées à l'accès aux données sous-jacentes. "A partir de là, on va pouvoir arbitrer entre un déploiement en mode cloud public ou privé, voire en frontière de réseau car le cloud hybride inclut également cette dimension", rappelle Thomas Sarrazin.
En matière d'urbanisation, il est recommandé de prendre en compte les liens entre applications. En ligne de mire : éviter un éclatement du système d'information sur de multiples plateformes qui pourrait porter préjudice aux intégrations nécessaires entre les différentes briques applicatives, entre un ERP et un CRM par exemple. "L'idée est de les regrouper par pool métier pour éviter que les échanges de données ne deviennent trop complexes", argue Thomas Sarrazin. "Un système d'information est forcément maillé. Il faudra le prendre en compte dans la stratégie de cloud hybride. Dans la même logique, il sera nécessaire de cartographier les flux applicatifs pour identifier les dépendances existantes entre cloud(s) public(s) et applications restant en interne."
"Les containers Kubernetes vont permettre de bénéficier d'applications portables d'un cloud public à l'autre, mais aussi d'un cloud public vers un cloud privé et réciproquement"
Ensuite vient la phase d'outillage. Elle commence par le choix d'une plateforme unique entre cloud public et cloud privé. Une plateforme qui pourra typiquement s'adosser à des containers Kubernetes. Ici, l'objectif premier est d'endosser une approche technologique cohérente. Une standardisation qui simplifiera la phase de mise en œuvre en évitant l'éparpillement des compétences au sein de la direction technique. L'approche opérationnelle sera du même coup simplifiée en permettant la mise en place d'un catalogue de services applicatifs basés sur le même orchestrateur et la même plateforme.
"Les containers Kubernetes vont également permettre de bénéficier d'applications portables d'un cloud public à l'autre, mais aussi d'un cloud public vers un cloud privé et réciproquement", souligne Alexandre Daudin chez Capgemini.
Une CI/CD cohérente
En aval, il sera nécessaire de rationnaliser la chaîne de déploiement autour d'un pipeline de livraison et d'intégration continues (CI/CD) cohérent. "Tout le travail consiste à harmoniser cette approche hybride pour avoir quelque chose à la fois de consistant d'un point de vue technologie et de facile à utiliser", indique Thomas Sarrazin. Et Alexandre Daudin d'insister : "Des solutions telles l'outil de gestion des configurations Ansible ou le logiciel d'infrastructure as code de Terraform pourront être mises en œuvre dans cette optique." Dans cette logique de déploiement, les frontières entre cloud(s) public(s) et cloud privé seront très mouvantes. "Une entreprise pourra très bien tester et éprouver une application sur un cloud public avant de la déployer sur son cloud privé", estime Alexandre Daudin.
Enfin, l'entreprise devra assurer les sauvegardes sans oublier le monitoring des applications sur ses différents clouds. "Un hyperviseur ou un orchestrateur commun facilitera les choses de ce point de vue. De même que la mise en place de landing zone", note Alexandre Daudin. Last but not least, l'architecture de communication entre cloud(s) public(s) et privé devra être conçue avec soin. Ce qui passera par exemple par des bases tampon déployées côté cloud public. Des bases qui seront synchronisées régulièrement avec le cloud privé. Autre solution : la mise en place d'une plateforme d'API qui permettra de faire le pont entre les deux univers.