Suite de l'article précédent (ça ne s'invente pas :-)), nous nous baserons sur les web services Amazon - AWS - pour aborder trois thèmes liés au Cloud Hybride IaaS : la liaison entre le SI interne et l’infrastructure de cloud public, la politique pour la gestion des images de VM et les licences.

Quelle liaison entre le SI interne et l'infrastructure de cloud public ?

2 philosophies complémentaires s'offrent à nous pour lier des applications ou des composants réparties sur des infrastructures distinctes (au sens géographique) :

• Intégration applicative : créer des wrappers (web-services) pour assurer les communications entre les différentes briques logicielles. Ces web-services pourront être sécurisés par SSL pour assurer la confidentialité des données échangées entre le SI interne et des VMs publiques.

• Intégration et sécurisation réseau : voir les différentes infrastructures comme un ensemble unique du point de vue réseau. En utilisant un mécanisme de tunneling sécurisé, chaque plateforme cloud est alors un prolongement du réseau interne. Amazon, à la différence des autres acteurs, propose le service Virtual Private Cloud qui permet de créer un tunnel IPsec (authentification des deux extrémités et cryptage des informations véhiculées) entre un data center Amazon et votre SI interne. Selon Amazon, le surcoût de bande passante lié à ces besoins de cryptage et encapsulation est d'environ 7%.

source : http://aws.amazon.com/

Ce service nécessite un routeur supportant des fonctionnalités avancées. Par exemple, on peut citer :  le support du protocole IKE (Internet Key Exchange) pour l'échange d'attributs de sécurité liés à la mise en place du VPN, ou encore le BGP (Border Gateway Protocol) Peering pour la définition des routes entre le data center Amazon et votre infrastructure - des notions bien éloignées des fonctions routeur offertes par une Freebox par exemple !

Le gros avantage de l'utilisation de tunnels IPsec, outre la transparence pour les applications, est que coté Amazon, les VMs ne sont pas accessibles de manière publique mais uniquement par le pont VPN. Coté inconvénient, la mise en place d'un VPN peut demander une réorganisation certaine de l'architecture réseau (règles de filtrage, création de sous-réseaux, nouvelle répartition des bande passantes...).

Actuellement, le service VPC est en béta, ce qui génère les limitations suivantes:

• les services Amazon comme auto-scaling, Elastic Load Balancing ne sont pas supportés par les VM qui appartiennent à un VPC. Ce sera à vous des déployer des machines configurées par vos soins pour remplir ces rôles.
• IPV6 n'est pas supporté.
• Le routeur vituel (coté Amazon) ne gère pas la notion de groupes de sécurité - concept Amazon pour déterminer les utilisateurs qui peuvent administrer des ressources AWS (VM, espace de stockage ...).
• Un seul cloud privé contenant au maximum 20 sous-réseaux peut être créé.

Quelle politique pour la gestion des Amazon Machine Images ?

A la base de chaque VM, il y a une image - Amazon Machine Image (AMI). Alors la question se pose : si une entreprise est amenée à déployer une centaine ou plus de VM, comment doit elle gérer les AMI à la base des VMs ?

Amazon avance 3 options : l'inventaire d'AMIs, l'AMI faible couplage et la "Just-Enough OS AMI".

L'inventaire d'AMIs est la première approche. A un "type" de VM est associé une AMI : OS, stack technique et code sont figés. Plusieurs VM peuvent être lancées à partir de la même image, mais supposez que vous ayez une VM "serveur d'applications" et une seconde VM "serveur de bases de données" : vous aurez deux AMI distinctes. Au fur et à mesure de ses expériences avec le cloud Amazon, une entreprise va accroitre la diversité des VM qu'elle instancie et par conséquent le nombre d'AMI qu'elle a à gérer.  Les problèmes se manifesteront lors de mises à jour : si vous devez appliquer un patch sur l'OS qui est utilisé par une dizaine d'AMI, vous devrez recréer la dizaine d'AMI une fois les mises à jour faites. Il en va de même de la stack technique voire du code source !

La seconde approche consiste à introduire un découplage entre l'image d'une VM et son état final. L'applicatif est maintenant chargé au démarrage de la VM : une AMI qui contient un serveur d'applications ira télécharger ses archives JEE sur un emplacement établi à l'avance (S3, serveur de gestion de configuration ...).  Avec ce schéma, nous évitons ainsi de démultiplier les types d'AMIs. Pour des applications JAVA, ce mécanisme passe simplement par une commande maven appelée au démarrage pour récupérer des artefacts depuis un repository interne à l'entreprise. Dans le cas d'autres technologies on peut penser récupérer l'applicatif sur un serveur de configurations (par exemple un export SVN) ou encore un simple téléchargement HTTP (wget).

Pour terminer, la troisième solution consiste à créer des AMI ne contenant que l'OS et l'environnement nécessaire pour utiliser un outil de configuration automatisé du type Chef, Puppet, CFEngine.Lors du lancement de la VM, un paramètre lui indiquera quelle doit être sa configuration (listes de frameworks nécessaires, code applicatif,...) et la VM se configurera à l'aide de scripts fournis par l'outil de configuration.

Comment procéder pour les licences ?

La migration des licences peut se faire de trois manières distinctes :

• De nombreux éditeurs ont des accords avec Amazon, qui permettent à l'utilisateur final d'effectuer une transition en douceur vers une exécution sur des instances EC2. Ce modèle appelé "Bring Your Own License (BYOL)" repose sur la mise à disposition d'AMIs pré configurées, en partenariat avec les éditeurs qui y ont intégré des mécanismes de licences. La licence que vous utilisez depuis 1 an, encore valable pendant encore 2 ans vous permet de lancer une AMI sur EC2. Parmi les éditeurs partenaires, on trouve entre autres : Oracle, Sybase, Adobe, MySQL, JBOSS, IBM and Microsoft.
• En parallèle du modèle BYOL, très proche des modèles de licensing classiques, Amazon propose un modèle "Pay-As-You-Go" basé sur le service "DevPay". Il s'agit de licences élaborées avec des partenaires, qui intègrent l'aspect "à la demande" d'EC2: les coûts de licence s'appliquent en ratio du temps d'utilisation des VMs. Bien souvent, les AMI qui comprennent des licences "Pay-As-You-Go"offrent des prestations de support. Parmi les partenaires on trouve : RedHat, Novell, IBM, Wowza.
• Enfin, la troisième solution est l'usage d'une application en SaaS. Amazon met en avant les éditeurs qui proposent des offres SaaS elles-même hébergées sur AWS. D'une manière générale, des kits de migration sont proposés, ce qui facilite la transition vers ces modèles à la demande - la souscription est bien souvent mensuelle. On peut citer Mathematica, Quantivo ou Pervasive.

Conclusion

Plusieurs acteurs de cloud public peuvent intervenir au sein d'un même cloud hybride. Les raisons peuvent être diverses :

• financières : il peut être intéressant de lancer des VM chez un tiers A et de stocker des données chez un tiers B.
• historiques : le tiers A présente une offre bien maitrisée par les équipes IT. Des démonstrateurs voire un cloud hybride sont déjà en place sur l'infrastructure du tiers A. Cependant, le tiers B offre des briques techniques indisponibles ailleurs.
• autres : le tiers B garantit un SLA.
• ...

Cependant chaque plateforme a ses spécificités, ses services propres, ses APIs propriétaires et les réponses possibles présentées dans cet article, qui sont basées sur AWS ne s'appliquent pas toutes à d'autres offres IaaS, et réciproquement.

Même si certaines initiatives de partenariats (entre VMWare et Google par exemple) vont dans le sens du développement de standards, nous sommes loin d'offres et d'api communs. Par conséquent, la multiplicité des offres utilisées impliquent une multiplicité des compétences en interne et une adhérence (à relativiser tout de même) aux fournisseurs de Cloud. Idéalement, on préférera limiter le nombre d'offres utilisées, en privilégiant les partenaires susceptibles de répondre aux besoins futurs, en termes de services et de garanties.