Cloud hybride IaaS avec Amazon – 1

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.

Le cloud Hybride – Pourquoi ?

Parmi les raisons d’une mise en place d’un cloud hybride, on distingue notamment :

  • l’optimisation d’un parc existant : inutile de maintenir en permanence un parc de machines dimensionné pour supporter des pics de charge temporaires
  • le provisionnement à la demande : améliorer les délais de mise à disposition de nouvelles ressources matérielles
  • l’établissement d’une infrastructure de secours : faciliter la mise en oeuvre d’un DRP (Disaster Recovery Plan)

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 :
  • Pour des raisons matérielles : systèmes Mainframe par exemple.
  • Pour des raisons stratégiques : les données sont jugées trop importantes pour être sorties du SI interne. Ou encore, l’application est trop critique pour risquer de créer une adhérence vis à vis du fournisseur de cloud.
  • Pour des raisons financières : l’architecture de l’application requiert des « building blocks » qui ne sont pas encore disponibles chez les acteurs cloud – l’effort demandé est trop important pour être intéressant.
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é.

Les typologies du cloud hybride

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

  • l’externalisation d’applications
  • l’utilisation de services techniques
  • l’externalisation de l’infrastructure

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.

L’externalisation d’applications

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.

Les enjeux d’architecture principaux sont alors le provisionning et le déprovisionning des utilisateurs, le choix des acteurs en fonctions des SLA et du service rendu (au même titre qu’un progiciel) et surtout les stratégies d’intégration :

  • au niveau des données : doit on dupliquer les données ? quels sont les moyens de récupérer les données de l’application externalisée ?
  • par les services : quelles sont les interconnections possibles ?
  • par l’IHM – mise en place d’un portail

L’utilisation de services techniques

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) …

Ce modèle de cloud hybride où la prise en compte des latences et l’adhérence aux api sont des questions clés, se prête avant tout à des offres PaaS.

Externaliser l’infrastructure

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:

  • Quelle liaison entre le SI interne et l’infrastructure de cloud public ?
  • Quelle politique pour la gestion des images de VM ?
  • Comment procéder pour les licences ?
  • Quels moyens pour gérer les accès à la plateforme cloud ?
  • Faut il mettre en place une compression de données  ?
  • Où placer les données ?

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…