L’un des défis du cloud est d’autoriser une gestion souple, évolutive dans le temps, des charges de traitement que l’on confie à l’infrastructure délocalisée. En particulier si l’on peut pouvoir confier ces charges à plusieurs infrastructures et prestataires qui interviendront en parallèle ou successivement.

C’est cet objectif qui a justifié le lancement de ComodIT, un projet de recherche, aujourd’hui en phase de commercialisation. Son objectif: simplifier les processus de (re)déploiement d’applications et de pans d’infrastructures informatiques, quasiment “à la volée”, sur diverses infrastructures cloud. Cible de clientèle prioritaire: le “mid-market”. Autrement dit les PME.

“La plate-forme”, explique Daniel Bartz, patron de Guardis, “doit permettre de déployer aisément un serveur- ou des centaines de serveurs- quel que soit le scénario: déploiement et exploitation dans l’infrastructure “maison du client” et, si nécessaire, dans une infrastructure hébergées de type cloud, quelques minutes plus tard. Voire en mode mixte.” Les infrastructures déportées peuvent être, au choix, des clouds privés ou publics (du genre Amazon, Rackspace…)

“La plate-forme ComodIT peut supporter de multiples scénarios”, poursuit Daniel Bartz. “Ajouter ou mettre à jour une application, la déplacer vers un autre élément d’infrastructure, dupliquer des éléments pour obtenir une solution de DRP-disaster recovery planning…”

L’idée est de permettre par exemple à une société de redéployer très rapidement son environnement sur le cloud le temps de résoudre une panne serveur intervenue dans sa propre infrastructure ou pour effectuer une maintenance.

L’interface de ComodIT permettra d’ajouter ou de supprimer des machines virtuelles (VM), des applications logicielles ou d’autres éléments d’infrastructure IT par le biais de simples requêtes.

L’utilisateur devrait en tirer divers avantages: réduction de la charge de gestion, du risque d’erreurs de manipulation, amélioration de la cohérence de l’infrastructure informatique, possibilité d’adapter plus rapidement cette infrastructure aux contraintes fluctuantes des activités.

“Recettes” et “ingrédients”

Pour garantir cette souplesse de reconfiguration et d’adaptation des scénarios de déploiement, le principe sur lequel repose ComodIT est celui de la description détaillée, recueillie dans une base de données centrale, de l’architecture et de ses différents éléments constitutifs, tant matériels que logiciels. “Nous procédons par regroupement des paramètres et dépendances afin de définir comment assembler et déployer ces composants de manière optimale.”

En clair: avant d’activer par exemple un serveur déporté dans une infrastructure cloud, il faut en passer par une description du potentiel final dont on veut disposer. Pour prendre une analogie, la description repose sur des “recettes” et des “ingrédients”.

Pour telle recette (par exemple, déploiement de telle ou telle application), on énumère et définit les ressources (système, OS, applications, espace de stockage, puissance, pare-feu…) nécessaires pour obtenir le résultat voulu. Une fois la “recette” concoctée, le déploiement de l’application se fera automatiquement, d’un simple clic, quel que soit l’environnement choisi – infrastructure cloud ou serveur installé sur site. “On décrit en fait la situation finale. Par exemple, la ‘destination’ finale est l’EC2 d’Amazon, l’OS doit être du Linux Red Hat, avec, comme sous-paramètre, la version v6, l’espace RAM sera de 4 Go, l’application est SugarCRM… ComodIT “force” en fait le système destinataire dans l’état désiré.”

Ce que ne fait pas (ou pas encore) ComodIT, c’est jouer les orchestrateurs dynamiques, pour déplacer spontanément une charge ou un pan d’infrastructure lorsque les ressources disponibles deviennent insuffisantes.  ComodIT alertera certes d’une saturation prochaine mais il faut encore recourir à des scripts pour ajouter une VM, migrer vers un autre système…

“ComodIT n’a pas été conçu pour fonctionnement sur base de règles” (ce qu’on appelle du ‘policy-based management’). “Il faut donc en passer par des outils d’orchestration pour interdire par exemple que les données se retrouvent sur une infrastructure dans tel ou tel pays “sensible” ou pour que le système ne supporte pas une charge qui le sature à plus de 80%”.

Pourquoi cette restriction dans le potentiel de la plate-forme ComodIT? “La description des processus d’orchestration diffère d’un client à l’autre”, explique Daniel Bartz. “Il n’est donc pas possible de l’automatiser. Mail il existe une librairie d’API qui permet à chacun de procéder à sa propre orchestration, par exemple pour planifier son propre scénario de basculement d’infrastructure en fonction de ses propres contraintes ou préférences.”

L’un des avantages d’une description détaillée d’état, comme la pratique ComodIT, “réside dans le fait que l’on peut ainsi recréer le même environnement ailleurs sur base de tous les paramètres décrits. On peut ainsi redéployer sans problème une infrastructure d’Amazon vers RackSpace.”

L’objectif final est d’en arriver à un stade où il ne sera plus nécessaire d’effectuer la moindre modification lorsque l’on passera d’un cloud à l’autre, ou d’un quelconque site à un quelconque cloud. Pour ce faire, l’une des conditions sine qua non qui devra être remplie est que les développeurs pensent, dès le départ, à cette flexibilité de redéploiement et développent donc les logiciels en conséquence.

La description exhaustive procure en outre une documentation complète de l’environnement informatique et de son historique, des différentes étapes qui ont été franchies. Cela sert aussi de référence de traçabilité dans un contexte de règles de conformité: tel serveur est dans l’état exact dans lequel il est sensé être. Sinon, une alerte est automatiquement délivrée.

Cible: le “mid-market”

Le projet et les financements qui l’accompagnaient, ont pris fin en mars de cette année. Le projet, insiste toutefois Daniel Bartz, a dépassé un seuil critique et est viable. Les développements et le déploiement de la solution continueront donc sans aides publiques.

L’objectif final est d’en arriver à un stade où il ne sera plus nécessaire d’effectuer la moindre modification lorsque l’on passera d’un cloud à l’autre.

La plate-forme ComodIT est entrée en phase de tests beta en octobre 2012. Quelque 250 sociétés (400 utilisateurs) l’ont ainsi testées, dont un tiers de sociétés belges (les autres sont basées aux Etats-Unis, en Inde, ou dans divers pays d’Europe).

Le profil des sociétés-pilotes belges est assez varié. On y retrouve notamment des porteurs de projets et des sociétés “de taille réduite mais à fort potentiel de croissance. Souvent des start-ups Web. Elles ont besoin de ce genre d’outil afin de pouvoir effectuer développement et déploiement sur des infrastructures d’une certaine envergure”, souligne Daniel Bartz. “Les sociétés qui n’ont besoin que d’un petit nombre de serveurs peuvent, elles, se contenter de procédures de déploiement manuelles.”

Parmi les premiers utilisateurs de ComodIT: Decinex, à Liège (gestion de la diffusion de films) qui l’utilise pour automatises ses déploiements pour la gestion de ses salles de cinéma. Pour la diffusion des films, la société doit installer des matériels et logiciels dans les différents cinémas. ComodIT lui permet de gérer le déploiement des serveurs, en leur appliquant la bonne “recette”.

ComodIT, elle, se positionne comme une solution pour “mid-market” où manquent encore les outils d’automatisation et qui n’intéressent pas ou trop peu les géants de l’IT. Daniel Bartz identifie dès lors d’autres cibles potentielles pour la solution. D’une part, les prestataires d’hébergement dans le cloud. “Jusqu’à présent, ils fournissent essentiellement des services d’infrastructure, parfois avec des applications. Mais, même pour les plus matures d’entre eux, ces applications ne sont fournies que sous forme d’image virtuelle figée. Les utilisateurs les utilisent pour la plupart à des fins de tests. Leur manque de flexibilité ne permet pas une utilisation dans un scénario de production. Avec ComodIT, le client aura accès à une infrastructure “customisée”, pourra configurer ses propres applications, de manière automatisée, au fil du temps.”

Troisième marché-cible potentiel (l’étude d’opportunité est encore en cours): les prestataires de services gérés (managed service providers). Ou, du moins, ceux dont au moins une partie des activités concernent le monde Linux.

Si la cible des prestataires de services gérés se confirme, ces derniers utiliseraient alors la solution ComodIT sous forme de produit blanc. “Elle leur permettrait de réaliser des déploiements plus rapides et de garantir des SLA plus élevés. De quoi améliorer leur propre positionnement concurrentiel…”

Prochaine étape: les données

“A plus long terme, la vision qu’on développe est celle d’une IT qui serait réellement devenue une commodity: ComodIT se chargerait de garantir la disponibilité constante, optimale, de toute application, se débrouillant seule pour procurer à tout moment l’infrastructure ad hoc apte à assurer la performance et le SLA voulus. Rendre le déploiement de la “tuyauterie” automatisé et transparent pour l’utilisateur est quelque chose à quoi nous réfléchissons notamment avec le CETIC.”

Après la transparence de déploiement des applications, le défi suivant à relever sera celui du redéploiement automatique des données avec relance transparente des bases de données.