Quel modèle de Cloud choisir pour les applications Web ?

D’une manière générale, les entreprises qui ont engagé la mise en œuvre d’un environnement de  Cloud Computing (privé ou public), l’ont en générale effectuée en réalisant et/ou intégrant en priorité, une solution IaaS. Cette 1^ère couche leur permet essentiellement de créer des machines virtuelles, à partir d’images OS préconfigurées, mais aussi  avec des ressources IT virtuelles associées (réseau et stockage), mais pourquoi faire ?

Modèle IaaS :

Installer et configurer les composants techniques nécessaires aux applications Web (monolithique, multi-tiers, voire encore clusterisée) sans se préoccuper des contraintes sous-jacentes IT (ressources et/ou services relatifs au(x) serveur(s), au(x) stockage(s) et au(x) réseau(s)). A ce stade, on dispose à la demande  des ressources et des services IT nécessaires au prérequis technique  des applications. On s’affranchit (abstraction) alors du volet administration système (dite hardware), mais pas encore de celui de l’administration système (dite software), mais cela sera le cas pour le mode PaaS. En effet, il suffit depuis une console Web de management (IaaS), voire aussi d’API Web Services en mode CLI de disposer à la demande (sous facturation, bien videmment) de ressources (serveur, stockage, réseau) et de services IT (gestion des règles de filtrage réseau, gestion de la répartition de charge, etc.) pour constituer le socle d’accueil applicatif selon les contraintes de services associées.

Afin de faciliter la vie des administrateurs systèmes (software), il existe généralement dans l’environnement IaaS, un référentiel d’images de plusieurs OS (Linux,  Windows, voire autres) en version 32 et/ou 64 bits. Ces images sont relatives à des OS fraichement installés, mais aussi avec l’installation et la configuration de base des composants techniques nécessaires aux applications (ex : Ubuntu 10.4 Server 64bits + Oracle 11i, Ubuntu 10.4 Server 64 bits + Apache2, etc.). En conséquence, le choix des images OS par serveur selon la richesse du référentiel  sera un gain d’activité pour  l’administrateur système (software). Selon le niveau de services requis, il restera d’autres actions plus ou moins complexes à réaliser et orientées IT (ex : mise en œuvre d’une répartition de charge, de montée en charge dynamique (élasticité), etc.).  Ces services IT ne sont pas systématiquement disponibles dans tous les environnements IaaS. De plus, pour un niveau de services élevé (ex : l’environnement pour un PRA (Plan de Reprise sur Activité après sinistre)), il est nécessaire de connaître en détail l’offre IaaS sur la portée des ressources et des services entre Data Center.

Bref, mettre en place des applications de production depuis un environnement IaaS est possible, mais nécessite toutefois, une bonne maîtrise de l’aspect virtuel des ressources et des services IT. Un administrateur système (software) reste requis.

Le  transfert d’applications Web existantes vers le Cloud est possible. Il y a plusieurs solutions pour y parvenir : 

1. Constituer les ressources et les services IT dans le contexte IaaS  à l’identique de l’environnement IT d’origine. Ensuite installer et configurer les composants techniques nécessaires à l’application. Puis exporter les données de l’application d’origine pour les importer dans le Cloud. En final, après qualification préalable, ouvrir le service. Selon la complexité de l’application cela peut prendre en 1 journée à une semaine, voire plus selon le niveau de services requis, sans oublier la prise en charge des actions d’exploitation vis-à-vis des sauvegardes, de la rotation des logs applicatifs, etc.

2. Migrer les images OS des serveurs physiques ou virtuels hébergeant l’application, ainsi que les espaces de données associés vers des images compatibles avec l’environnement IaaS. Cette solution à l’avantage de ne pas réinstaller et reconfigurer les composants techniques nécessaires à l’application. Elle nécessite toutefois, la disposition d’outils type convertisseur qui ne peuvent malheureusement couvrir tous les cas de figure possible. En conséquence, cette solution de migration ne pourra être vraie dans tous les cas. De plus, le processus est moins indissociable, ce qui signifie que la durée du processus de migration a un impact sur le niveau de services requis, en comparaison uniquement de l’export / import des données dans le cas de la réinstallation et la reconfiguration des ressources et des services dans le Cloud. Logiquement, si l’application d’origine est virtualisée au format OVF, la migration sera alors fortement facilitée. En raison de la volumétrie de données relative au(x) OS, voire aux partitions (File System) associées, d'autres procédés de déport de celles-i sont possibles, comme le fait Amazon à l'aide de processus bien rodés.

 Le rêve des DSI serait que la console Web de gestion IaaS dispose d’un mécanisme (équivalent à un download de fichiers) permettant d’importer (voire d’exporter dans le cas de réversibilité) des flux de données correspondant à des partitions bootables et autres de serveurs pour les transférer en VM, voire en serveur physique dans le cadre du Cloud. Ceci semble possible, si certains standards sont respectés (ex : OVF) pour les machines virtuelles. Une standardisation de l’architecture applicative avec une extension du standard OVF permettrait de télécharger le fichier descriptif des ressources, des services, voire de SLA relatifs à l’application, ainsi que les images associées pour créer l’application dans l’univers du Cloud. Certains ont déjà étudié ces aspects, reste à savoir si le standard prendra en compte ou pas ses extensions. A cheval entre IaaS et PaaS, on trouve la solution AWS Elastic BeanStalk qui prend en compte les différents autres services AWS, comme le montre la copie d’écran ci-dessous.

Des onglets complémentaires apparaîtront probablement pour couvrir, entre autres, les besoins d'exploitation relatifs aux sauvegardes/restaurations et aux journaux techniques, voire fonctionnels.


Ceci étant, l’environnement IaaS sert dans d’autres contextes que le monde applicatif en production (développement, qualification, calcul, etc.).

Modèle PaaS :

C’est l’environnement idéal pour accueillir les applications Web de production. Depuis, une console Web de gestion, on donne le nombre d’instances par tiers, ainsi que les services requis par tiers, et le tour est  joué grâce à la richesse du framework PaaS. A ce stade, il n’y a plus besoin d’administration système (software), un responsable MOA doit être en mesure d’ouvrir le service. Toutes les contraintes IT (exploitation, scalabilité, disponibilité, élasticité, etc.) sont prises en compte dans les 2 couches (PaaS & IaaS) de l’environnement. La console de management fournit, entre autres, les indicateurs de qualité (SLA orienté fonctionnel), d’utilisation, de performance, les logs fonctionnels, etc. Le déploiement de l’application (bundle MO) avec des services (ex : persistance) du BO, voire  du FO.  Pas à se soucier de la configuration pour la répartition de charge, pour l’élasticité, etc. tout est pris en charge de façon automatisée. Les offres PaaS sont assez importantes avec pour les propriétaires (Azure de Microsoft qui tend à offrir maintenant des environnements IaaS avec des images Linux, Google App Engine, mais aussi CloudSwing). 

Côté Open Source, il y a Cloud Foundry créé par VMWare  courant 2011, en licence Apache2. A vrai dire, il semble qu’il s’agisse, en tout cas pour la partie client (package: cloudfoundry-client (release 0.3.10)sous le repository Ubuntu 11.10 Server (Oneiric)) d'un l’outillage en Ruby avec essentiellement la commande CLI "vmc" via le framework Rubygem. Les détails de l'installation et d'utilisation de la partie cliente sous un hébergement PaaS offert par VMWare sous donnés (ici). La partie la plus intéressante étant évidemment la partie serveur qui a été porté par Canonical & VMWare sur Ubuntu 11.10 (Oneiric) avec le package: cloudfoundry-server (release 0.3.10). Les détails d'installation de la partie serveur sont donnés (ici).  Sur ce point, VMWare s’appuie sur son environnement vCloud avec sa suite vSphere. J’ai utilisé l’utilitaire « vmc » en mode CLI pour poster et gérer les ressources et services associés pour une application Java, c’est très facile de mise en œuvre et de suivi. Pour terminer sur ce volet, l'installation de la partie serveur, c'est-à-dire cloudfoundry-server sur un environnement IaaS (EC2, voire plutôt OpenStack) se fait facilement avec Juju, voire une vidéo qui trace les détails (ici). Pour information, la release up-to-date de Cloud Foundry en tout début 2012 est la 0.3.15 qui offre, entre autres, la fonctionnalité de tunnel (accès) vers les services.

Modèle SaaS :

C’est du PaaS avec l’application gérée en multi-tenants (c'est-à-dire, entre autre, un contexte applicatif permettant la configuration propre de l'application pour chaque tenant) et cette fois, ce sont uniquement les fonctionnels qui interviennent pour créer les personnalisations adéquates, voire les groupes de profils applicatifs. Bien évidemment, cette couche d’abstraction s’appuie sur les 2 autres déjà cité. Elle ne nécessite pas de console de management spécifique de gestion, mais, à minima, un portail de services relatifs à la facturation. Les autres consoles de gestion PaaS et IaaS peuvent être fournies, le cas échéant.