L’émergence de standards faciliterait le recours aux PaaS

"article publié dans 01 Informatique le 14 janvier 2010"

Développer ou déployer sur le Cloud ?

Avant toute chose, il convient de faire la différence entre développer pour le Cloud et déployer sur le Cloud. Pour simplifier, avec les plateformes IaaS comme celle d’Amazon, on déploie sur le Cloud des machines virtuelles qui embarquent une architecture d’entreprise classique. Il n’est donc pas nécessaire d’intégrer des pratiques de développement propres au Cloud.

Par contre, lorsqu’on adresse des plateformes PaaS, comme Google Apps Engine, Force.com ou Azure, il est nécessaire d’adapter ses développements. En effet, les PaaS proposent des architectures spécifiques et contraintes : en particulier sur les modes de persistance, les temps d’exécution. Et chaque PaaS a ses propres contraintes. Avec les PaaS, on parle véritablement de développement pour le Cloud.

Pourquoi développer sur le Cloud ?

La contrepartie des architectures contraintes est un contrat de service d’un nouveau genre, hors de portée des architectures d’entreprise. Les PaaS promettent la scalabilité des applications : « la 101ème requête ne consomme pas plus de ressource que la première ». Les PaaS proposent le « self service » : toute entreprise peut demander l’allocation de ressources en quelques minutes. Enfin, les PaaS permettent le « pay as you go » : la facturation se fait à un niveau de précision exceptionnel : celui de la consommation de CPU/réseau/stockage .

Quels cas d’usages ?

Les entreprises hésitent aujourd’hui à confier leur IT à de nouveaux acteurs, et à se lancer dans des architectures spécifiques pour lesquels les compétences sont encore rares. D’autant plus qu’il est aujourd’hui impossible de déplacer son application d’une PaaS vers une autre.

Il existe cependant des cas d’usage où les PaaS se révèlent intéressantes :

• des applications à forte charge (attrait de la scalabilité),
• des applications à charge variable (attrait du pay as you go),
• des applications expérimentales à durée de vie courte (attrait du self service),
• des applications ouvertes sur le Web (attrait de l'intégration facile avec d'autres services en ligne).

Il est parfois possible d’adresser ces cas d’usage en invoquant des données stockées dans les murs de l’entreprise depuis les PaaS, et ainsi de résoudre la problématique du stockage chez un tiers.

Vers une résolution des problématiques légal****es ?

Les entreprises candidates au Cloud Computing se heurtent aujourd’hui à des problématiques juridiques complexes : la plupart des plateformes appartiennent à des entreprises américaines et sont soumises au fameux Patriot Act.

Deux pistes pourraient nous aider à contourner cet obstacle : d’une part, la suppression du Patriot Act (la proximité entre Éric Schmidt et Barack Obama pourrait y aider) et la clarification des accords internationaux sur la confidentialité des données ; d’autre part, l’émergence d’acteurs locaux du Cloud Computing. Des hébergeurs comme Colt ou Orange Business Services pourraient proposer des offres PaaS aux entreprises françaises.

La remise en cause du SQL ?

Les PaaS utilisent des systèmes de persistance optimisés, non relationnels, qui viennent bouscule****r la suprématie de Merise et SQL. Et nos développeurs sont confrontés à un étrange mouvement intitulé « NoSQL ». Cette remise en cause est louable car on utilise un peu trop systématiquement des architectures génériques, qui ne conviennent pas à tous les cas d’usage. Elle va dans le sens d’une réflexion sur des architectures plus optimisées. Le SQL a malgré tout encore de belles années devant lui car les SGBD sont parfaitement maîtrisés par la communauté informatique.

Et les s****tandards techniques ?

Pour simplifier le recours aux PaaS, il serait souhaitable qu’émergent des standards pour l’intégration des PaaS au Système d’Information : échanges de données, fédération d’identité, tunnel sécurisé, etc. Un standard de monitoring serait aussi souhaitable pour permettre aux entreprises de mesurer la performance de leurs applications hors les murs. Enfin, un standard autour de la réversibilité des applications permettrait de relativiser le risque d’enfermement dans des plateformes propriétaires. Les membres de l’Open Cloud Manifesto travaillent sur le sujet : tant qu’ils n’auront pas convaincu les grands acteurs de Cloud de les rejoindre, leur démarche restera vide de sens.

En cible : l’équivalence des plateformes ?

A long terme, les PaaS pourraient se banaliser et devenir des commodités sans grande valeur ajoutée. On pourrait alors imaginer qu'elles proposent des API totalement identiques et que la migration d’une PaaS à une autre se fasse sans couture. Les entreprises pourraient alors déployer leurs applications chez plusieurs opérateurs de PaaS et ainsi répartir les risques techniques sur plusieurs acteurs. C’était la promesse des serveurs d’application JEE : il serait souhaitable pour nous, utilisateurs,  qu’elle se concrétise un jour dans le domaine du Cloud Computing.