Le développement sur le cloud n'est pas sans désavantages...mais a un bel avenir

Avec la migration de plus en plus d’activités vers le cloud, des opérations au CRMs, il est naturel que les outils de développement sautent le pas. L’idée est alléchante: rendant son environnement de développement disponible n’importe où, n’importe quand, du moment que l’on est connecté à internet.

Le cloud est l’un des sujets les plus en vogue en ce moment, et est souvent présenté comme la solution miracle qui va résoudre tous les problèmes de performance et de montée en charge des applications, le tout en réduisant les coûts d’exploitation de par son aspect élastique et à la demande.
Ceci présente une multitude d’avantages: plus besoin d’avoir à télécharger les différentes briques de l’environnement de développement, à les installer et à les configurer sur chaque poste développeur (un scénario courant consiste à installer Java, Maven et/ou Ant, Eclipse et quelques plugins). Une solution centralisée et préconfigurée est déjà installée sur le cloud.

On s’affranchirait aussi des contraintes de portabilité des outils sur les différents OS. Les machines des développeurs n’auraient plus besoin d’être très puissantes pour faire tourner toute la stack de développement: il suffirait juste qu’elles permettent de faire tourner un navigateur web, jouant ainsi plus le rôle d’un terminal, laissant au cloud le soin de fournir la puissance de calcul et la mémoire nécessaire. Il n’est même plus nécessaire d’avoir un ordinateur pour développer, une tablette comme l’iPad par exemple pourrait faire l’affaire. Et pour certains projets où la compilation est coûteuse, ceci permettrait même de gagner en productivité en parallélisant le processus de build sur le cloud.

Les outils de développement sur le cloud ne cessent de s’améliorer et se rapprochent de plus en plus des outils usuels de type application de bureau, comme Eclipse, Visual Studio et autres EDIs (Environnement de Développement Intégré). On est loin de l’époque où l’on ne disposait que d’une zone de texte. Les outils actuels gèrent la coloriation syntaxique, auto-complétion, vérification et formatage du code, structure du projet, intégration avec les outils de versionning comme Git et SVN, exécution et déploiement du code.  Et avec l’évolution rapide des technologies web, comme HTML 5 par exemple, qui ne cessent de pousser les limites de ce qu’on peut faire, on pourrait s’attendre à ce que ces outils rattrapent leur retard face aux outils classiques, voire même les dépasser en tirant profit de la nature extensible et collaborative du web.

A ce sujet, on peut citer deux familles d’IDEs sur le cloud:

* Ceux qui essaient d’imiter l’apparence et le fonctionnement des IDEs classiques. On peut citer cloud9 et exo-ide comme exemple, qui se présentent comme une application complète dans une page, et qui gèrent elles-mêmes leurs onglets entre autre et ce en s’appuyant sur de puissants frameworks de présentation Javascript comme jQuery, Sencha, etc.
* Ceux qui essaient de rester fidèle à la philosophie du web avec des liens classiques bookmarkables et partageables, qu’on peut ouvrir dans les onglets du navigateur. Eclipse Orion, qui a été présenté par Boris Bokowski à l’occasion de la première édition de la What’s Next 2011, fait partie de cette famille (vidéo de sa conférence sur http://whatsnextparis.com/agenda.html).

Développer sur le cloud ouvrirait aussi les portes du développement collaboratif, qui va bien au delà d’un système de versionning de code, à la SVN ou Git, où il faut d’abord commiter (et éventuellement pousser) pour partager du code. La collaboration en temps réel entre plusieurs participants, où l’on peut travailler simultanément et à plusieurs sur un même fichier, comme l’ont déjà démontré des outils comme Google Wave et Novell Pulse.

Par contre, les développements sur le cloud n’est pas sans désavantages: ce qu’on peut faire avec les technologies web actuelles reste moins puissant qu’une application native tournant directement sur le système du développeur, ne serait-ce que sur des petits détails comme les raccourcis clavier, qui ne sont pas tous exploitables dans le navigateur. Et avec des interfaces très chargées, et malgré les énormes progrès réalisés par les moteurs Javascript comme V8 (Google Chrome), SpiderMonkey, TraceMonkey et JaegerMonkey (Mozilla Firefox), on risque d’éprouver des lenteurs à l’exécution et une consommation accrue de la mémoire.

Il y a aussi le problème de trafic et les lenteurs que ça peut engendrer : selon le langage et les librairies qu’on utilise ainsi que des fonctionnalités proposées par l’outil de développement, ce dernier risque d’avoir des échanges fréquents de gros volumes de données avec le serveur pour des actions comme l’auto-complétion, ou encore sur de gros refactorings. Ceci est peut-être la raison pour laquelle la majorité des outils de développement sur le cloud supportent généralement des langages comme Javascript, css, python, ruby,php, où les fonctionnalités des outils de développement sont généralement considérées basiques comparées à ce que propose les EDIs des langages comme Java et C#.

Mais les outils de développement ne se limitent pas aux IDEs.
Le cloud s’apparente bien à la problématique de l’intégration continue. Ainsi, une infrastructure flexible sur laquelle on peut faire tourner un ensemble de nœuds Jenkins peut-être hébergée sur le cloud ce qui permet de faire adapter sa taille en fonction de la charge. Pour implémenter une telle infrastructure, il est possible d’utiliser une offre IaaS (EC2) où l’on installe et configure soi-même la solution d’intégration continue, où encore utiliser une solution préfabriquée, à la cloudbees, libérant ainsi des ressources des taches d’installation et de maintenance, au risque peut-être de ne pas avoir un contrôle total sur la plateforme.

Le développement sur le cloud est encore à ses débuts, et l’offre actuelle est prometteuse et laisse présager un bel avenir. Par ailleurs, il viendrait complémenter les outils de développement classiques, comme les EDIs pour des langages comme Java et C#, du moins dans un premier temps. A mon avis, les outils de développement sur le cloud ne devraient pas essayer de ré-implémenter l’EDI dans le navigateur, mais plutôt repenser la façon dont on développe en s’appuyant sur les forces du web.