Dans une première partie, nous présentons le cloud hybride d'une manière générale, ensuite nous tenterons de répondre aux questions posées par le cloud hybride de type IaaS, en nous basant sur l'offre Amazon Web Services.
Parmi les raisons d'une mise en place d'un cloud hybride, on distingue notamment :
A ces points, s'ajoute le besoin de l'entreprise d'être convaincue par le cloud public. Ce problème de confiance est l'un des principaux freins à l'adoption du cloud public par les entreprises. Dans ce cas, l'idée est de faire un premier jet sur une architecture hybride pour acquérir les compétences requises (appropriation de la plateforme de cloud public), se rassurer et gagner en confiance avant de se lancer dans des déploiements de plus grande envergure.
Néanmoins, toutes les applications n'ont pas vocation à être sorties du SI interne pour être portées sur une infrastructure cloud :
Ainsi, exception faite des très petits SI "non exotiques", qui peuvent être migrés en totalité, le cloud hybride fait sens pour des sociétés cherchant à tester le cloud public ou devant amortir un investissement (en infrastructure) déjà réalisé.
Dès lors, nous nous contenterons de définir le cloud hybride comme la nécessaire cohabitation entre un SI interne ("on-premise") d'une entreprise A et un service proposé par le cloud public.
Par ailleurs, nous établissons que les applications/services/infrastructures tiers doivent être administrées par l'entreprise A. Cela nous aligne d'ailleurs sur l'avis des puristes, pour lesquels l'appel à des APIs publiques comme Google Maps ou Twitter depuis un SI interne ne constitue pas un cloud hybride.
Le cloud hybride peut se décliner selon trois modèles
Parallèlement, les applications d'entreprises peuvent selon leur degré de spécificité, être segmentées en trois grandes catégories : partagées par toutes les entreprises (mail, calendrier, feuille de temps, ... ), propres à un secteur mais sans enjeu différenciant (middleware, services de stockage, progiciel, ...) ou encore stratégiques au sein d'un même secteur (librairie de calcul, algorithme, services innovants, ...). Pour plus d'informations sur ce sujet, consultez la session USI de Julien CABOT.
Nous verrons que la base de la pyramide se prete à l'externalisation d'applications, alors que le sommet est plus propice à l'externalisation d'infrastructure.
Dans ce modèle, des applications entières - pas uniquement des composants - sont externalisés sur le cloud public. Bien que le type de cloud utilisé puisse être IaaS ou PaaS si l'entreprise décide de garder "la main" sur ses applications, une offre de type SaaS est très adaptée dans le cas d'applications communes à toutes les entreprises. Pas besoin de spécifique pour assurer des fonctions standards telles que le mail, gestion des salles ou suivi des ventes.
Il ne s'agit plus d'applications entières, mais uniquement de briques techniques qui sont situées sur le cloud public. On retrouve classiquement des services de CDN (content delivery network), des middlewares de type MOM, du stockage (comme S3 par exemple) ...
Enfin, nous arrivons à l’externalisation de VMs à proprement parler. Dans ce cas le besoin est d’utiliser plus de CPU, de RAM en somme de la ressource physique brute pendant un laps de temps donné.
En tant que services de très bas niveaux, ce sont ceux qui offrent le plus haut niveau de flexibilité et donc très intéressant pour des applications très spécifiques et innovantes.
L’enjeu est alors la maitrise de l’infrastructure externalisée (bande passante, latences) et son industrialisation (format des images disques pour réinternalisation eventuelle, api de contrôle …).
La mise en oeuvre d'une externalisation de l'infrastructure impose certaines réflexions, notamment:
Prenant le cas de l'offre Amazon - Amazon Web Services - le poids lourd de l'IaaS, nous tenterons de répondre à ces questions. Certaines d'entre elles sont d'ailleurs adressées dans le document de migration édité par Amazon.
A suivre...