Voyage au coeur du nuage (2/3): PaaS

Voici le deuxième article de la série que je vous propose pour découvrir ce qu'est le cloud. Dans le précédent article, je vous faisais découvrir IaaS qui permet à des exploitants de disposer d'une infrastructure à la demande. Parlons aujourd'hui du PaaS qui va, lui, cibler des développeurs.

PaaS veut dire "Platform As A Service". Pour simplifier, disons que l'objectif est de proposer aux développeurs d'applications de déployer sur Internet leurs applications sans se soucier de savoir sur quel serveur et sur quel système d'exploitation elles seront hébergées. Et cela, tout en garantissant que l'hébergement sera capable de supporter de fortes sollicitations. Le PaaS propose donc aux développeurs un déploiement transparent sur Internet sans avoir à gérer la configuration et l'exploitation des serveurs nécessaires.

Ainsi, si vous avez développé une application qui peut être fortement sollicitée (le nouveau Facebook par exemple), avec les solutions PaaS, vous allez pouvoir le mettre en production sans avoir à gérer la moindre infrastructure et il pourra supporter des millions de sollicitations sans que vous vous en préoccupiez. Alors qu'évidemment si vous l'hébergez sur votre datacenter vous allez devoir investir sur de nombreux serveurs et gérer au quotidien leur configuration et leur exploitation.

Mais concrètement, comment cela se passe ? Est-il si facile de développer pour le cloud ? Est-ce la même chose qu'un développement habituel et comment se passe la facturation ? C'est que je vous propose de découvrir ici en explorant la solution de Google et de Microsoft.

Deux applications pour le Cloud

Pour étudier le PaaS, nous allons nous appuyer comme exemple sur deux applications développées pour le cloud sur lesquelles j'ai travaillé: QRDecode et Rino.

QRDecode est l'application utilisée pour le Green Challenge coorganisé par l'USI 2010 et par GreenIT.fr et dont je détaillais les résultats récemment.  QRDecode est une application web dont l'objectif est de décoder des codes barre à deux dimensions (des "QRCodes"), d'afficher les coordonnées des contacts auxquels correspondent ces codes barres et de positionner ces contacts sur une carte. L'implémentation des traitements serveur de QRDecode est réalisée en Java sur Google App Engine, la solution PaaS de Google.

Rino est un outil permettant d'accéder à ses bloc-notes Microsoft Office OneNote depuis un téléphone mobile iPhone ou Palm Pré. J'ai développé Rino il y a quelques mois pour illustrer une présentation sur Windows Azure et un article du site de développement CodeProject. L'implémentation des traitements serveur de Rino est réalisée en C# sur Windows Azure, la solution PaaS de Microsoft.

C'est quoi développer pour le Cloud ?

Lorsqu'on développe une application, on doit nécessairement se préoccuper de l'environnement cible sur lequel va s'exécuter l'application. Pour le cloud, les choses sont différentes, la cible n'est pas une véritable machine mais une "abstraction" dont on n'a pas la maîtrise. Lorsqu'on déploie l'application, on ne déploie donc pas dans un répertoire d'un serveur physique ou virtuel mais vers une entité abstraite  qui est mise à disposition par la plate-forme PaaS.

Concrètement votre application peut être déplacée d'un serveur à un autre ou dupliquée de multiple fois à des emplacements géographiques différents de manière complètement transparente pour vous.

Cela impose nécessairement quelques restrictions sur la manière de développer (nous en reparlerons ci-dessous) mais cela permet à la plate-forme PaaS de gérer la réplication et la montée en charge de votre application.

Quelles particularités du développement PaaS ?

Essayons d'appréhender les particularités du développement d'une application pour le cloud.

Choisir son fournisseur

Première particularité: développer une application pour le cloud nécessite de se lier à une fournisseur. Ainsi, le schéma du paragraphe précédent se décline en fait entre les deux plateformes que nous étudions.

On développe une application pour Windows Azure OU une application pour Google App Engine mais pas une application pour les deux plates-formes.

D'ailleurs le développement pour Google App Engine est limité à Java et Python alors que le développement Windows Azure impose au minimum un lanceur en .NET même si le reste de l'application peut être du code binaire quelconque.

Restriction d'environnement

Sur une plate-forme PaaS, l'application est isolée de son environnement pour qu'elle soit indépendante du matériel, du système d'exploitation et de l'emplacement réel du serveur. Cela n'a donc pas de sens d'accéder directement au serveur ou au système de fichier.  Sur Google App Engine, c'est tout simplement impossible, sur Windows Azure c'est possible mais il faut avoir réservé un espace au préalable dans une zone protégée du serveur.

Sur une plate-forme PaaS, les APIs utilisables sont également limitées. Pour Google App Engine, de nombreuses APIs du JDK ne sont pas utilisables: Thread, Sockets, File, java.lang.System, Reflection, JNI, EJB, … Pour Windows Azure il n'y a pas de limitation (on peut même exécuter du code natif et avoir accès à la base de registres !) mais votre code s'exécute sur la machine hôte avec un profil utilisateur ayant des droits restreints.

Une nouvelle manière de stocker les données

La plus grosse particularité du développement PaaS concerne le stockage des données. De manière à ce que votre application soit facilement réplicable, Windows Azure et Google App Engine proposent en effet un mécanisme de stockage de données spécifique. Votre application PaaS va donc devoir embarquer un mécanisme de stockage de données "pour le cloud".

Concrètement il s'agit d'un stockage hiérarchique (non relationnel ou NoSQL) des données, ce type de stockage étant plus facilement déplaçable, réplicable et supportera donc plus facilement la montée en charge.

Dans le détail, ce stockage "pour le cloud" offre la possibilité de stocker soit:

• - des "entités": un enregistrement consiste en une suite de propriétés "nom = valeur",
• - des objets de grandes tailles ou "blobs": un enregistrement consistant généralement en un fichier potentiellement volumineux.

Pour Windows Azure, le stockage d'entités passe par ce que l'on appelle des "Tables". Ces Tables n'ont rien à voir avec des tables SQL, elles permettent simplement d'avoir un regroupement logiques des entités, sans imposer que les entités d'une même table aient une structure commune. Les opérations sur ces tables se pilotent via une API REST dont une encapsulation .NET est proposée.

L'API propose des opérations standards de création, mise à jour et suppression. Le requétage sur ces tables est possible par interrogation de la valeur d'une ou plusieurs propriétés.

Pour le stockage des blobs, Windows Azure propose également une API REST et une encapsulation .NET. Un blob correspondant à une grande quantité de données auquel on peut associer des méta-données afin de le qualifier.

Pour Google App Engine, le mode de stockage des entités s'appelle le "Datastore". Le stockage est réalisé par persistance des objets Java soit via JDO soit via JPA. Dans les deux cas, on va devoir "décorer" les propriétés de la classe avec des attributs indiquant les champs à faire persister.

A noter qu'il existe également une API bas niveau pour accéder au Datastore.

Le requêtage du Datastore se fait via l'API ou via un pseudo SQL, JDOQL ou GQL qui permet de filtrer les valeurs des propriétés. Une interface d'administration web permet  de visualiser directement le contenu du Datastore et de l'interroger en GQL via la ligne de commande.

Pour les blobs, Google App Engine propose là-aussi une API spécifique. Comme pour Windows Azure, on peut associer aux blobs des méta-données pour les qualifier.

Evidemment ces particularités dans le stockage des données signifient que vos applications actuelles, qu'elles soient .NET ou Java, ne sont pas directement "portables" sur le Cloud. C'est en effet une des grosses restrictions des plates-formes de PaaS aujourd'hui.

Néanmoins, il faut préciser que Microsoft propose (à un tarif différent / plus élevé) une offre SQL Azure qui permet depuis  votre application Windows Azure d'accéder à une "vraie" base de données SQL Server sur le cloud.

Google ne propose pas encore de base de données sur le cloud mais l'annonce récente d'une offre "entreprise" laisse supposer que cela devrait être possible prochainement dans Google App Engine.

Développer en environnement connu

Intéressons-nous au maintenant aux plates-formes de développements. Pour attirer les développeurs sur leur plateforme, Google et Microsoft  ont utilisés les mêmes armes: leur permettre de retrouver un environnement familier.

Pour développer une application pour Windows Azure, il existe donc un template (projet prêt à l'emploi) pour Visual Studio. Il suffit de quelques clics pour créer son application pour Windows Azure. Il pourra s'agir d'une application web (appelé "Web role") ou d'un batch (appelé "Worker role").

De la même manière, pour développer une application pour Google App Engine, il existe un template pour Eclipse. Il suffit donc là aussi de quelques clics pour créer sa première application pour Google App Engine. Cela peut être une application Web ou une application GWT.

Déploiement sur une plate-forme PaaS

Le déploiement de l'application PaaS consiste à demander un nouveau "slot" à la plate-forme pour héberger son application.

Pour Windows Azure, la création d'un "slot" se réalise par l'intermédiaire de l'interface d'administration web. Un slot correspond à un "service hébergé" (l'application elle-même) ou une "zone de stockage" (pour stocker les tables et les blobs).

Le déploiement de l'application s'effectue alors directement depuis Visual Studio via un menu dans l'explorateur de serveur.

Il faut noter que, pour Windows Azure, on doit préciser dans le fichier de déploiement le nombre d'instances de l'application que l'on veut créer au départ. On pourra ensuite augmenter ce nombre en redéployant le fichier de configuration ou via l'interface web.

La création d'un "slot" pour Google App Engine passe également par l'interface web. Il n'y a pas de séparation ici entre l'application et la zone de stockage. C'est l'usage qui le déterminera.

Le déploiement se fait ensuite directement par l'intermédiaire d'Eclipse.

Contrairement à Windows Azure, on ne précise pas le nombre d'instance nécessaires,  Google App Engine va le gérer dynamiquement selon la sollicitation de l'application.

Il faut noter aussi que Google App Engine permet de conserver plusieurs versions de la même application et de revenir à une ancienne version. Très pratique dans le cas de l'application QRDecode pour comparer le fonctionnement des applications des différents candidats du concours

Combien ça coûte ?

Le mode de facturation est ce qui fait la caractéristique des solutions de Cloud. Il est basé sur: le temps d'exécution de l'application, la quantité de données transférées et l'espace de stockage permanent utilisé. Force est de constater que les prix affichés sont très proches entre Windows Azure et Google App Engine.

Voici les tarifs actuels pour Windows Azure:

Le détail des coûts est récapitulé sur une facture mensuelle.

Voici les tarifs actuels pour Google App Engine:

Le portail d'administration permet un suivi de la facturation jour par jour.

Il faut également noter qu'il permet de disposer d'un suivi de l'activité heure par heure sur les différents paramètres, et de manière très détaillée et graphique.

Si les deux plates-formes ont des tarifs comparables, cela cache néanmoins deux différences notables.

D'abord Google facture à la CPU utilisée quelque soit le nombre d'instances alors que Microsoft facture par instance ce qui fait évidemment une différence, non seulement en fonction du dimensionnement que vous choisissez dans Windows Azure mais aussi tout simplement lors des périodes d'inactivité de votre application. Sous Windows Azure, vous payez que votre application soit sollicitée ou non, sous Google App Engine, vous ne payez réellement que ce que vous utilisez.

Ensuite, Google App Engine propose des "Free Quotas" que vous pouvez utiliser sans même fournir d'information de facturation. Autrement dit, Google vous autorise à utiliser le service gratuitement en production dans la limite d'une utilisation "raisonnable".  Voici le détail de ce auquel vous avez droit:

Microsoft propose également des offres découvertes de Windows Azure, notamment  pour les abonnées MSDN (voir ci-dessous).

Néanmoins, le mode de facturation (CPU consommée par rapport à heure utilisée) avantage clairement aujourd'hui la plate-forme de Google. L'évolution du mode de facturation est d'ailleurs la demande la plus importante sur le site de suggestions d'évolution de Windows Azure.

Conclusion

Le PaaS est clairement une manière de supprimer un intermédiaire dans la chaine de déploiement d'une application informatique: l'exploitant. En mode PaaS, le développeur peut s'affranchir complétement du déploiement de son application sur une infrastructure et donc s'affranchir de son dimensionnement, de son administration et de son exploitation.  C'est à la fois un espoir de gain en agilité et en  coûts et aussi une opportunité pour tout entrepreneur d'inventer et de déployer à moindre coût une solution informatique d'envergure mondiale.

Mais toutes les applications peuvent-elles être déployées sur une plate-forme PaaS ? Au-delà des contraintes juridique et de sécurité, cet article montre que l'architecture d'une application pour le PaaS n'est pas forcément identique à celle d'une application d'entreprise: c'est le cas pour le stockage des données mais c'est le cas plus généralement pour la montée en charge qui nécessite la mise en place de designs patterns de développements spécifiques. La plate-forme ne fait pas tout, l'architecture reste l'élément central qui détermine les performances d'une application  !

Il y a en tout cas fort à parier que c'est sur le PaaS que va se jouer la principale bataille du cloud.  C'est d'ailleurs la raison de l'intérêt des fournisseurs de solutions de virtualisation pour des frameworks de développement : Spring pour VMWare, JBoss pour RedHat. A partir du moment où la notion même de serveur physique ou virtuel disparait au profit d'une notion plus abstraite de "plate-forme d'hébergement", on peut même prédire la mort des solutions IaaS au profit du PaaS.  C'est ce que semble craindre Paul Maritz, CEO de VMWare dans une récente interview.

Rendez-vous dans un prochain article pour un voyage au cœur du SaaS.