Introduction
Dans notre précédent dossier, nous avons vu que la programmation parallèle permettait aux logiciels de monter en charge en exploitant l’augmentation du nombre de cœurs des architectures multicœurs. Le parallélisme adresse plus particulièrement les applications qui nécessitent de la puissance de calcul, du traitement lourd en local.
En revanche pour les applications de nature collaborative, transactionnelle et d’une manière générale pour les applications en ligne, la problématique de montée en charge se traduit par : comment gérer une augmentation du nombre d’accès simultanés, comment stocker une masse d’information de plus en plus importante ? Pour répondre à la demande, on peut bien sûr augmenter le nombre de serveurs et de disques durs du data center, élargir la bande passante du réseau avec pour corollaire tous les problèmes d’administration, de consommation énergétique, de place physique…
On peut également déporter toute cette infrastructure matérielle et logicielle chez un hébergeur et ne plus se préoccuper que des aspects applicatifs. C’est là tout l’intérêt du Cloud Computing.
Le cloud computing
En définitive qu’est-ce que le Cloud Computing ? C’est une infrastructure hébergée, scalable, sur laquelle on peut construire ses propres applications. Elle permet de louer des ressources informatiques délocalisées (machines, logiciels, bande passante…), de facturer en fonction du taux d’utilisation de ces ressources et de considérer qu’elles sont disponibles à la demande en quantité infinie (du moins suffisamment importante pour qu’on n’en voit pas les limites). Lors d’une montée en charge de l’application, c’est le Cloud qui se chargera de gérer les accès simultanés supplémentaires. Ainsi, si une transaction s’effectue en 1 seconde pour un utilisateur, elle mettra 1 seconde pour 100 000 utilisateurs !
Ces définitions étant posées, on entend parler de SaaS, de PaaS, de IaaS… Il s’agit de différents types de Cloud, correspondant à des couches d’architecture. De la même manière qu’une architecture en local, sur site (on parle de « on premises » en anglais) comprend une infrastructure (machine, OS), une plateforme et des applications, une architecture dans le Cloud comprend les mêmes couches :
- La couche infrastructure est appelée Infrastructure as a Service (IaaS). C’est une infrastructure matérielle louée à la demande : stockage, machine virtuelle, OS… Par exemple : Amazon EC2
- La couche plateforme est appelée Platform as a Service (PaaS). C’est une plateforme logicielle louée à la demande : plateforme d’exécution, services applicatifs… Par exemple : Google App Engine
- La couche applicative est appelée Software as a Service (SaaS) : applications métier. Par exemple : salesforce.com
Cloud Programming
Concernant la programmation, les approches sont également différentes. Au niveau le plus bas, IaaS, il n’y a pas de pile logicielle prédéfinie. Avec EC2 (Elastic Compute Cloud) par exemple, Amazon propose l’hébergement d’images virtuelles d’OS complets. On peut y installer un Windows Server ou un Linux avec une base Oracle ou MySQL, et développer ses applications dans le langage de son choix. Il y a tout à faire et la programmation ne diffère guère d’une programmation pour applications locales.
Au niveau le plus élevé, SaaS, il s’agit ici de solutions métier clés en main, hébergées sur le site de l’éditeur telles que les applications CRM de salesforce.com. Ici, pas de briques de base pour construire ses applications.
Le niveau intermédiaire, PaaS, est le plus intéressant pour les développeurs puisqu’il permet de créer ses propres applications en s’appuyant sur une plateforme logicielle. Le développeur n’a plus à se préoccuper de l’infrastructure matérielle et logicielle, il peut se concentrer sur les langages, les API et les fonctionnalités.
Citons également un niveau intermédiaire entre PaaS et SaaS que l’on pourrait appeler Office Cloud : il s’agit de suites bureautiques en mode SaaS telles que Google Docs ou Zoho Sheet dont certaines briques logicielles sont accessibles via des API. Elles permettent de créer des solutions bureautiques personnalisées, certes pas aussi abouties que les suites bureautiques classiques de type Microsoft Office, mais bien plus avancées que celles-ci en termes de solutions logicielles Web.
Les PaaS sont des solutions middlewares hébergées conçues pour faire tourner des applications de type transactionnel (pas de batch donc) et utilisant des bases de données de type BigTable (non relationnelles). Le PaaS arrive avec un environnement d’exécution, des services d’infrastructure et en général avec son propre langage de programmation. Le choix d’un PaaS est donc fortement dépendant du langage que l’on veut utiliser. Trois plateformes PaaS se partagent aujourd’hui le marché : Salesforce.com Force.com, Google App Engine et Microsoft Azure.
Force.com
Salesforce.com propose sa plateforme Force.com avec son langage propriétaire Apex. Celui-ci pourrait être considéré comme un Domain Specific Language (DSL), un langage dédié au domaine. C’est un langage de haut niveau (logique métier), statiquement typé, avec un code et des données multi-tenants (hébergés par une infrastructure commune). La syntaxe et les structures de contrôle sont très proches de Java. Les types d’objet sont persistants et deux langages de requête sont embarqués. Apex permet le contrôle et le verrouillage de transaction et les triggers en tant que construction (insertion/mise a jour/suppression/undelete avant et après). Les outils de test et de couverture fonctionnelle sont fournis par la plateforme.
Au niveau sécurité, les classes peuvent être déclarées avec ou sans partage. Les règles de partage peuvent être spécifiées par l’administrateur du Cloud, et les ressources peuvent être limitées par gouvernance (au moment de l’exécution, par appel de méthode pour trouver les valeurs, selon les contextes).
Au niveau parallélisme, Apex n’autorise pas le lancement de threads.
Les outils fournis sont un plugin pour Eclipse, une TextBox pour l’interface utlisateur Salesforce.com.
Google App Engine
La plateforme de Google, Google App Engine (GAE) utilise nativement le langage Python. Comme beaucoup de produits Google, GAE est encore en version beta. Il s’agit plus pour l’instant de tester le concept que de déployer des applications critiques. Google offre aux développeurs des comptes d’essai gratuits autorisant 500 Mo de stockage, 200 mégacycles de CPU par jour et 10 Go de bande passante par jour. Ce qui permet aux applications de servir jusqu’à 5 millions de pages vues par mois, autant dire qu’on a largement de quoi voir venir. En cas de dépassement de la consommation, le supplément est facturé.
Google App Engine SDK est un package complet qui fournit des API et des outils permettant de développer et d’exécuter l’application dans un environnement local offrant les mêmes API que le service en ligne. Une fois l’application au point, elle peut être transférée sur le Cloud. Les API sont : le Python Runtime, les API Datastore, Images, Mail, Memcache, URL Fetch et Users. Google App Engine vient également avec une base de données BigTable, non relationnelle, prévue pour s’étendre indéfiniment. Google App Engine possède une syntaxe proche de SQL appelée GQL. Les instructions Select en GQL ne peuvent être lancées que sur une table à la fois. GQL ne supporte pas de manière intentionnelle l’instruction Join.
Récemment, Google a annoncé le support de Java pour Google App Engine, en version préliminaire (Early Look). Cette annonce est particulièrement importante pour la communauté des développeurs Java, car elle leur ouvre enfin le développement pour le Cloud. Jusqu’alors, les applications Java d’entreprise étaient peu adaptées à l’hébergement web (rare et cher), les hébergeurs préférant proposer du PHP sur des plateformes *AMP. L’arrivée de Java sur Google App Engine change la donne. Non seulement le déploiement Java s’en trouve facilité mais l’hébergement devient quasiment gratuit et donc concurrentiel par rapport aux solutions PHP !
Google App Engine (suite), Microsoft Azure
Cependant, la programmation pour le Cloud de Google impose certaines contraintes. Il est par exemple interdit d’écrire directement dans un fichier. En effet, cela ne permettrait pas de rendre l’application distribuée : un fichier généré par une instance de l’application ne pourra pas être utilisé tel quel par une autre instance de l’application sur un autre serveur. Comme pour Apex, il n’est pas possible de créer des threads. Sur un serveur dédié le lancement de threads simultanés permet de répartir la charge de manière parallèle et donc de gagner en performance. Dans le Cloud, cela n’a pas de sens. C’est le Cloud qui se charge de répartir automatiquement la charge. Parmi les autres contraintes, on peut citer l’impossibilité d’établir des connexions de type socket directe à des serveurs externes, la programmation sans état, le temps d’exécution limité à 30 secondes ou encore l’absence d’accès à des bases de données relationnelles. Des contraintes qui peuvent sembler drastiques mais qui dans un contexte Cloud s’expliquent parfaitement.
Du fait de ces restrictions, bon nombre de bibliothèques et de frameworks Java ne sont plus compatibles avec Google App Engine. Mais la communauté Java s’est empressée d’effectuer les portages possibles et aujourd’hui un grand nombre de frameworks et de bibliothèques sont supportés, ainsi que des langages compatibles avec la JVM : Groovy, JRuby, JavaScript, Scala, Jython, Spring, Restlet, Jersey… Même PHP a été porté via Quercus, une implémentation 100% Java de PHP. Ce qui fait de PHP sur Google App Engine une solution d’hébergement PHP encore plus attractive que les offres PHP natives !
Certes, on s’éloigne du standard Java de Sun, qui voit d’un mauvais œil cette implémentation incompatible. Après tout, cela aurait dû être à Sun de proposer ce standard de Java pour le Cloud !
D’une manière générale, il n’y a pas convergence entre la nécessité de standards et les contraintes techniques du Cloud, ce qui à terme risque de poser des problèmes d’interopérabilité entre les infrastructures locales et Cloud.
Microsoft Azure
Dernier arrivé sur ce marché, Microsoft a dévoilé en octobre dernier sa stratégie dans le Cloud avec sa plateforme Azure qui s’annonce comme étant la plus riche et la plus complète du marché. Beaucoup de briques ne sont pas encore disponibles et le déploiement va s’étaler entre 2009 et 2011. Mais à terme, Microsoft disposera d’une offre couvrant tous les aspects du PaaS : stockage avec Azure Storage et SharePoint Online Libraries, workflow et intégration avec .NET Services Workflow/Service Bus, gestion des identités avec Windows Live ID et .NET Services Access Control, services applicatifs avec Live Search, Virtual Earth, CRM Online…. Azure bénéficie d’un modèle de programmation déjà bien implanté puisqu’il s’agit de .NET, d’outils familiers (Visual Studio) et d’une communauté active et enthousiaste. Pour les développeurs .NET, passer au Cloud se fera sans trop de douleur : mêmes langages de programmation (Visual Basic, C#, C++…), mêmes outils.
D’autres projets, conclusion
Autour de ces trois acteurs principaux du PaaS, on peut citer un certain nombre de projets en cours autour des langages pour le Cloud :
- Haskell, un langage fonctionnel
- Clojure, un langage dynamique
- Erlang, un langage fonctionnel concurrent temps réel
- Scala, un langage de programmation orientée objet et de programmation fonctionnelle
- F#, le langage de programmation fonctionnel de Microsoft
- MapReduce, l’outil de programmation de Google pour des calculs parallèles de données très grosses
- TupleSpace, un modèle de mémoire partagé
Conclusion
Le Cloud Computing est encore un domaine tout récent. Hormis Amazon EC2 et Force.com, les offres sont encore à l’état de beta ou de projets. Mais nul doute le Cloud offre le pendant Web de la programmation parallèle pour les applications locales, une évolution naturelle pour une demande toujours croissante de montée en puissance des applications de demain.
