Un Cloud hybride est un modèle qui combine au moins 2 environnements de Cloud Computing fonctionnant ensemble pour fournir une combinaison flexible de services. Ce modèle assure une migration transparente des charges de travail du Cloud privé vers, ou depuis, le Cloud public en fonction des besoins de l’entreprise, et apparaît comme la solution de transition idéale pour passer d’un modèle Cloud privé au modèle Cloud public… Du moins sur le papier. S’appuyant sur son expérience, Gilles, Architecte Solution Infra/Cloud, nous montre qu’il y a un écart entre théorie et réalité.
Avant de définir le Cloud hybride, pouvez-vous nous rappeler les fondamentaux du Cloud privé et public ?
Il n’est pas facile de donner une définition simple car ces notions ne cessent d’évoluer et se mélangent aujourd’hui de plus en plus. Si originellement on distinguait le Cloud privé et le cloud public par leur localisation -le cloud privé avec un hébergement dans les datacenters d’entreprises et le cloud public avec un hébergement externe – c’est un peu plus compliqué aujourd’hui. Il suffit de prendre des offres de Cloud public d’Azure ou d’AWS, qui viennent déposer des racks dans les datacenters des clients pour y exécuter des services. De même, des entreprises montent des cloud privés dans des datacenters hors site qu’elles louent auprès de fournisseurs. La frontière devient floue. A mon sens, un Cloud privé ne doit pas se contenter d’apporter de la virtualisation, il doit également proposer des interfaces ad hoc pour un provisionnement automatisé et rendre accessible un catalogue de services par les utilisateurs via un self-service portal. Pour le Cloud public, l’idée souvent partagée est de se reposer sur un hébergeur et de ne plus se soucier de toutes les questions énergétiques, de refroidissement, de hardware… Le Cloud public représente un mode de consommation de services et de compute.
Alors qu’est-ce que recouvre la notion de Cloud hybride ?
A l’origine de la notion de Cloud hybride se trouvait l’idée de posséder un cloud privé et un cloud public. Aujourd’hui, dès lors que des Cloud sont combinés, indépendamment de leur emplacement physique, le terme Cloud hybride peut s’appliquer. Un Cloud hybride peut donc être formé avec un Cloud privé et un Cloud public, ou deux Cloud privé ou deux Cloud public. L’intérêt étant de pouvoir provisionner rapidement, dans un sens ou dans l’autre, et de switcher ou de transférer facilement des workloads. Mais les clients pensent souvent qu’il s’agit de « fonctions d’origine ». Pourtant ce n’est pas le cas. Il est d’ailleurs rare de rencontrer une entreprise qui se dit, par exemple, l’infrastructure de mon Cloud privé consomme beaucoup de CPU ou de bases de données, et c’est en faisant du monitoring que je pourrais switcher tout ou partie vers le cloud public, et donc faire du cloud hybride. C’est la même chose pour le provisionning automatique : sa mise en place requiert un effort de charge qui n’est pas anodin. Ça ne se fait pas si facilement, même avec de l’infrastructure as Code. De manière générale, l’effort à fournir pour faire du Cloud hybride est souvent mal mesuré.
Dans quel cas faut-il passer au Cloud hybride ?
C’est plus le besoin business, la stratégie de développement de l’entreprise et le contexte client qui doivent dicter le passage à l’hybridation, pas l’infrastructure existante ou la politique de la DSI. Je prends l’exemple d’une petite entreprise cliente avec très peu d’infrastructures IT, mais avec de très gros besoins CPU, qui a décidé de passer par de l’AWS Workspace plutôt que d’investir sur une infrastructure comme VMWare Horizon montée localement. Quand les besoins ont augmenté, les coûts sont devenus astronomiques. Ici un modèle hybride aurait certainement été mieux adapté à leurs besoins financièrement parlant. De manière plus générale, si une entreprise dispose déjà d’une infrastructure On Premise, il sera souvent plus intéressant de basculer vers du Cloud hybride plutôt que vers du 100% Cloud public. Car vouloir aller trop vite dans un projet de migration sera techniquement compliqué, finalement long à mettre en œuvre et difficilement rentable.
Le Cloud hybride peut donc représenter une solution de transition ?
L’hybridation peut servir une démarche « move to cloud » par étapes, au fil du temps, et un accompagnement au changement pour les utilisateurs. Cela englobe aussi la DSI, et sa stratégie de développement applicative. Car il existe de nombreux cas où les applications d’entreprises « pré Cloud » ont été codées de façon monolithique, et l’effort de développement à faire pour atteindre la cible Cloud public sera très important. Ce qui complexifie un projet de migration vers le Cloud. Il est facile lorsqu’on part d’une feuille blanche d’appliquer du DevOps Cloud native de fabriquer du code parfaitement adapté à un déploiement vers Azure ou AWS. Mais dès lors qu’il faut partir de l’existant, la démarche est soit longue, soit très coûteuse, soit porteuse de risque pour les utilisateurs si les choses ne sont pas bien faîte, ou s’il n’y a pas d’accompagnement suffisant. L’hybridation est donc parfaite pour avancer étape par étape. Elle donne le temps à la DSI de mettre en place une véritable stratégie de workloads et d’identifier ce qu’il faut migrer en priorité.
Vous souhaitez échanger avec nos experts autour de vos enjeux et du cloud hybride, c’est par ici !
L’effort à fournir pour faire du Cloud hybride est souvent mal mesuré.
