Le Cloud privé peut être interne ou externe. Dans le dernier cas, on retrouve ce que l’on connaît déjà en infogérance, outsourcing. Les hébergeurs et infogéreurs proposent du Cloud dans leurs offres. C’est notamment le cas des opérateurs comme Orange, SFR, ATT ou encore Colt. Et des éditeurs comme IBM, HP proposent aussi des datacenters pour héberger vos environnements et applications. En réalité, le Cloud privé offre, comme dans tout Cloud, une autre manière de consommer les services applicatifs, notamment pour des questions de montée en charge, de déploiement, de gestion de l’infrastructure et de sa rationalisation. Surtout, le Cloud privé se veut flexible, et capable de s’adapter à vos besoins stricts.
En réalité, le Cloud privé révèle là aussi différents niveaux. Car il est possible de se contenter du niveau infrastructure actuel, ce que l’on appelle le IaaS (I pour Infrastructure) alors que la partie application et exécution concerne plus le PaaS (P pour plateforme). “Il faut une démarche globale”, prévient M. Siou (directeur technique VMware France). Mais cela nécessite avant tout projet de cartographier aussi bien l’infrastructure matérielle que le parc applicatif. À partir de là, vous pourrez démarcher les logiciels à “cloudiser”, les logiciels à externaliser via des services Saas par exemple, et bien entendu, les différentes couches d’infrastructure : stockage, serveurs. Cela permet aussi de définir ce que l’on pourra appeler un plan de marche des machines. Car finalement, pourquoi un serveur fonctionne ? Quelle est son utilité, son objectif dans le SI ? Attention tout de même, le Cloud privé ne modifie pas le cycle d’amortissement des machines. Et ce cycle peut être un frein à court terme.
Ensuite il s’agit d’étudier la faisabilité du Cloud privé, notamment sur la partie applicative qui peut demander des modifications, voire soulever des problèmes de fonctionnement. Mais attention, tout n’est pas migrable sur le Cloud. Par exemple, tout ce qui est mainframe, paraît difficile à migrer.
VMware travaille sur un projet particulièrement intéressant. Grâce aux briques techniques de SpringSource et de CloudFoundry, tous deux propriétés de VMware, il s’agira de déployer dans un Cloud une application Java. C’est le projet Napa.
Sur la partie sécurité, le Cloud privé interne étant comme son nom l’indique, purement interne, les règles de sécurité ne changent pas et les outils de sécurité sont aujourd’hui matures sur ce type de Cloud. Les données restent situées dans l’entreprise. Par contre, le problème viendra dès l’instant où des connexions avec l’extérieur se réalisent, par exemple avec des services en ligne externes accédant aux données. Le Cloud hybride par exemple nécessitera des ouvertures de “portes” tout comme l’agrégation de différents services. Une grande prudence s’impose et un audit de sécurité s’avérera utile.
Dans le cas d’un Cloud privé externe (classiquement en infogérance), la réflexion sécurité doit être menée, en sachant ce qui restera en interne et ce qui sera mis en externe. Par contre, dès aujourd’hui, nous possédons les protocoles, les outils de sécurité nécessaires (VPN, SSL, cryptographie, etc.).
Les fonctions à exclure du cloud
- applications spécialisées et applications métiers autonomes par exemple les outils d’analyse temps réel
- applications et données ayant des obligations légales et réglementaires fortes ou critiques. Exemple : les données privées des utilisateurs
- applications tournant sur des architectures spécifiques comme sur mainframe
- enfin tout ce qui nécessite de très longs processus de traitement ou d’exécution.
- Application à forte nécessité de performance. Là vous aurez des problèmes de latence entre les clouds et les couches applicatives et de données.
