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.