Cloud privé Partie 4/4

le 13/01/2010 par Marc Bojoly
Tags: Software Engineering

Dans les premiers articles de cette série j'ai introduit le concept de cloud privé, puis dans les suivants un type d'offre basée sur un espace dédié chez un fournisseur puis des offres de cloud en interne. Pour terminer ce tour d'horizon, nous allons regarder ce qui existe du côté des offres de Paas.

Du côté des Platform as a Service

Jusqu'à maintenant les descriptions ont tournées autour des offres de type Iaas comme Amazon EC2. Une offre PaaS permet de déployer non pas une image de machine virtuelle mais directement une application. Choisir une telle offre décharge des tâches d'administration du système d'exploitation au prix de contraintes supplémentaires. Je rangerai deux offres dans cette catégorie : la récente initiative Cloud Foundry de VMWare/Spring Source, Microsoft Azure pour sa compatibilité avec le développement .NET et dans une moindre mesure AppScale.

Cloud Foundry

Suite rachat de Spring Source par VMWare, l'annonce de l'offre Cloud Foundry a fait apparaître un nouvel acteur important de l'offre PaaS. CloudFoundryIl s'agit de déployer des applications Java Spring sur des instances Amazon EC2. Le service propose des instances EC2 prêtes à l'emploi et une intégration du mécanisme de déploiement à l'outil Maven. Jusque là il ne s'agit pas de cloud privé. Mais une implémentation pour fonctionner sur les outils VMWare est en cours. Cette offre permettra alors de déployer au choix sur un cloud privé (des instances VMWare) et sur le cloud Amazon, les mêmes applications Java conçues pour fonctionner sur Cloud Foundry. Cette offre possède l'avantage de cibler les applications Java Spring, plateforme applicative assez classique dans nos SI. Le fait de déployer sur une plateforme applicative couplera les applications à celle-ci. Aujourd'hui, le service utilise tomcat 5.5.2.3 et un JDK 1.6. Les applications devront s'y conformer et probablement suivre des montées de version.

Microsoft Azure

Microsoft a bâti son offre de cloud public : Azure (encore en Community Technology Preview) sur la base de ses technologies .NET. Les développements pour Azure se font avec les mêmes outils et des briques de bases similaires (SQL Services, .NET Services) aux environnements locaux. Cela devrait permettre de réaliser des migrations des plateformes internes vers Azure avec peu de modifications. Cette offre ne permet pas un déploiement totalement identique sur Windows et Azure comme Cloud Foundry. Cependant, comparativement à des offres comme Google App Engine qui utilisent des technologies innovantes (base de données non relationnelles), la transition vers la plateforme Azure est facilitée. Il faudra cependant attendre les versions finales pour évaluer la charge effective d'une migration.

Google App Engine

Le projet de recherche AppScale a montré enfin qu'il était possible d'implémenter sur Eucalyptus et EC2 un Google App Engine de façon relativement scalable. Si le besoin se précise et les investissements suivent, une implémentation locale pérenne pourrait devenir possible. Pour l'heure, les dépendances envers les API de Google App Engine et surtout le stockage DataStore, pour lequel aucun outil d'import export vers une base relationnelle n'existe, constituent une barrière à la réversibilité. Notons toutefois que les deux offres précédentes (Cloud Foundry et Azure) utilisent une base de données relationnelles. Le DataStore constitue un point fondamental de la scalabilité du Google App Engine mais également une cause de non réversibilité.

En synthèse les avantages de ces différentes offres peuvent se résumer ainsi :

| | Avantages du cloud computing | | Inconvénients du cloud computing | | | | --- | --- | | --- | | | --- | --- | --- | | | Le paiement à la demande | L'optimisation de certains coûts de gestion | La nécessité de gérer différemment la sécurité | L'absence de localisation pour les données sensibles | Le risque sur les investissements | | L'abstraction sur la localisation | | Dégradé : la haute disponibilité (deux sites) doit être gérée dans le cas interne | | Amélioré : l'objectif est de pouvoir migrer les données entre interne et externe. Des initiatives sont là mais il faut attendre des retours d'expérience concrets (notamment sur les performances) | | | Le paiement à la demande | Dégradé : il n'est valable que pour les ressources externalisées | | | | | | Le self-service (accès via internet) | | Les offres PaaS sont encore très jeunes (quelques mois d'existence, voire bêta) | Pas de changement gestion applicative de la sécurité dans les deux cas pour pouvoir migrer de façon transparente | | | | L'utilisation de ressources partagées et d'architectures "multi-tenant" | | Dégradé : uniquement pour les ressources externalisées | Dégradé : seules les ressources externalisées sont partagées | | | | L'élasticité qui est la capacité à pouvoir ajouter à la demande des ressources dans le système et la scalabilité qui est la capacité à consommer autant de ressources pour la première requête et la 101ème | Dégradé : restera délicate pour les ressources internes (mêmes problématiques de dimensionnement pour que la virtualisation) | | | | Amélioré : élasticité tout en ayant une faible barrière entre interne et externe. Mais cela est mitigé par le fait que l'on est couplé à la pile applicative |

Globalement, les offres de PaaS sont donc les moins matures en terme de cloud privé.

Conclusion

Pour conclure sur cet ensemble d'articles, et au delà du terme traditionnel de cloud privé, je décrirai trois types d'offres :

  • les offres de cloud public basées sur des architectures multitenant
  • les offres de cloud hybride dans lesquelles certaines ressources restent au sein de l'entreprise et d'autres sont hébergées sur un cloud partagé mais façon personnalisée (isolation réseau, connectivité optimisée avec les ressources internes, etc.)
  • les offres de cloud interne dans lesquelles toutes les ressources restent au sein de l'entreprise mais sont gérées à la manière du cloud

Les besoins correspondants au cloud privé sont couverts par les deux dernières catégories. Mais sont-elles une réelle alternative au cloud public? Le cloud constitue aujourd'hui une innovation qui nécessite de remettre en cause certains principes établis pour en tirer pleinement profit : externalisation, nouvelle gestion des ressources, changement de responsabilités production/développement. Les offres de cloud hybride et de cloud en interne viennent tempérer ce changement en proposant un mécanisme de transition ou bien une pile technologique adressant cloud en interne et cloud public. Mais au sein de ces offres les facilités proposées par rapport au cloud public ont pour contrepartie des restrictions sur certains gains attendus. Cloud public d'une part, clouds hybride et interne d'autre part, utilisent globalement les mêmes technologies de virtualisation, même si la maturité du cloud public est plus avancée. Au delà de la technologie et du choix de l'externalisation (datacenter d'un fournisseur ou interne) c'est aussi l'organisation et les process qui devront évoluer pour être capable d'avoir des SI avec les mêmes potentialités que le SI d'un Google ou d'un Amazon. Les offres décrites offrent un moyen aux entreprises d'entrer dans le monde du cloud computing tout en facilitant la transition de certains besoins liés à l'existant des entreprises. Alors, pour ce faire, comment choisir parmi ces différentes offres? Les offres de cloud hybride et les technologies permettant un déploiement mixte (sur un cloud public et un cloud interne) constituent une bonne transition vers une externalisation au moins partielle des ressources. Les offres de cloud interne orientent plutôt vers des transformations internes pour atteindre au sein du datacenter la flexibilité et l'optimisation des coûts connus chez les fournisseurs actuels.

Références