Archives du mois : février 2008
Dans un article publié sur GigaOM, Greg Olsen (fondateur de coghead.com) pose une question intéressante : les fournisseurs d’applications hébergées (comme Salesforce.com par exemple) peuvent-ils survivre en bâtissant eux-mêmes leur infrastructure ?
Photo Ronnie Garcia
Traditionnellement, quand un acteur internet important met à disposition d’un large public une application web, il s’applique à créer de toute pièces une infrastructure informatique pour accueillir cette dernière : serveurs, baies de stockage, pare-feux, routeur et switchs, etc… Tout cela pour garantir la disponibilité et la tenue en charge de son application.
Aujourd’hui, des acteurs comme Amazon, avec ses services EC2 et S3, proposent d’appliquer à l’infrastructure les mêmes recettes que celles qui fondent le modèle économique des offreurs d’applications hébergées : un concept “à la demande”.
J’avais déjà parlé de l’initiative de Gandi proposant un hébergement à puissance variable. Ce type d’hébergement est une véritable opportunité pour les nouveaux entrants dans le “Web 2.0″. Ceux-ci, à l’instar de 37signals, créent de petites applications, légères et concentrées sur un spectre fonctionnel réduit ; leurs moyens sont souvent limités, bien loin du faste des années de la bulle ; leur personnel se résume souvent à une ou deux personnes. Bref, ils n’ont peuvent pas disperser leur énergie en bâtissant de toute pièce un datacenter pour leur application !
Les fournisseurs d’infrastructures partagées ont une réponse séduisante à ces nouveaux entrepreneurs : des offres à la demande, dont les tarifs suivent la charge des applications de leurs clients (et probablement de leurs revenus - à condition d’avoir un modèle économique viable ;-), sur une infrastructure de base dont ils ne pourraient même pas rêver s’ils devaient la mettre en oeuvre par eux-même.
Bien sûr toute médaille à son revers.
Le 15 février dernier, le service S3 d’Amazon est tout simplement tombé en panne pendant 4 longues heures ; L’ensemble des services qui reposaient sur les capacités de stockage en ligne d’Amazon ont connu des déboires plus ou moins important : images ou icônes qui n’apparaissaient plus sur les pages, jusqu’à l’interruption de certains services.
Evidemment, cela fait un peu tâche dans le paysage de l’infrastructure à la demande. Mais comme s’interroge un éditorialiste, les compagnies d’électricité ont aussi leurs pannes, ce n’est pas pour ça qu’on va construire des centrales dans chaque entreprise !
22 février 2008
Je cherchais pour mes développements Rails une solution simple pour sauvegarder les différentes versions de mon code. En premier lieu, j’avais fait le choix d’installer sur ma machine Ubuntu un serveur Subversion, mais elle n’est pas en ligne en permanence, or j’ai besoin de pouvoir faire ces sauvegardes à distance quand je suis sur la route.
En explorant les diverses solutions d’hébergement disponible sur Internet, je suis tombé sur l’offre de Google, Google Code. Cette solution est presque parfaite, si vous souhaitez partager votre code avec la communauté; en effet, le code stocké doit l’être sous une licence open source.
Vous disposez alors, en anglais, d’outils qui vont vous permettre de gérer votre développement :
- Une page d’accueil pour expliquer votre projet
- Une page de téléchargement pour publier des versions téléchargeables de votre solution
- Un wiki pour fournir la documentation ou des informations sur vos développements
- Une application de gestion des bugs
- Une page pour récupérer le source de votre code, soit en le consultant en ligne, soit en l’extrayant au travers de Subversion.
Vous pouvez choisir d’ouvrir la mise à jour du code à toute la communauté ou à certains utilisateurs uniquement, voire même vous réserver ce privilège. La lecture du code, par contre, est possible à tous les internautes.
En utilisant les possibilités d’intégration de Subversion dans Netvibes, vous obtenez un confort de gestion des versions vraiment appréciable.
Note : j’ai eu le problème, je vous fait partager la solution : lorsque vous souhaitez restreindre les mises à jour du code à certains utilisateurs authentifiés, vous devez saisir votre nom d’utilisateur Google (jusque là pas de problème), mais pas votre mot de passe Google ! C’est le mot de passe Google Code (auto généré) qui est le bon. Vous le trouverez en navigant vers la page des préférences code.google.com/hosting/settings.
14 février 2008
La fin de l’hiver nous amène la nouvelle version de Mezzoteam ! Je ferai un point complet des nouveautés de cette version dans un prochain billet, mais je tiens déjà à souligner deux améliorations qui feront plaisir à tous les utilisateurs et administrateurs Mezzo :
- La recherche plein texte a été grandement améliorée, elle est maintenant pratiquement instantanée.
- Il est maintenant possible de rajouter dans les vues listant plusieurs familles de documents des attributs utilisateurs, et plus seulement les attributs système. celà va nous permettre de faciliter la recherche d’information sur le référentiel tout entier.
Pour les utilisateurs hispanophones, la bonne nouvelle est l’ajout de l’espagnol à la liste des langues utilisables dans l’interface.
14 février 2008
Lorsqu’on parle des bénéfices des services de travail collaboratif, on oublie trop souvent de rappeler que le succès (ou l’échec) d’un tel service tient souvent, sur les projets de construction, à la présence et à la qualité d’une personne physique : l’administrateur. Vous me direz, qui est cet oiseau rare, quel est son rôle, son profil ? Voici quelques éléments de réponse.
Une première précision : quand je parle de l’administrateur d’un service de travail collaboratif, il ne faut pas le prendre au sens informatique du terme. On considère que si vous faites appel à un fournisseur d’application hébergée, il gère déjà son infrastructure ; si vous avez installé un système sur vos serveurs, ceux-ci sont gérés par votre service informatique.
Non, l’administrateur dont je veux vous parler est un administrateur fonctionnel. C’est lui qui va faire vivre le paramétrage du service au quotidien, et qui sera l’interlocuteur des utilisateurs pendant toute la durée du projet. Ces deux fonctions ne suffisent pas, sur la majorité des projets, à employer une personne à temps plein.
Souvent donc, l’administrateur du service partage son temps avec des fonctions dans la cellule de synthèse, ou dans les missions de pilotage de l’opération. Dans le premier cas, il est au coeur des échanges de documents pendant une phase critique de la vie du système ; dans le second il gère la documentation du projet dans sa composante temporelle.
Le profil de l’administrateur est celui d’un professionnel qui s’intéresse à l’informatique, et non d’un informaticien qui découvrirait le monde du projet. Il doit en effet être au courant des procédures et méthodes de l’opération, afin de pouvoir les transcrire dans le paramétrage du service. Il doit être proche des préoccupations quotidiennes des utilisateurs, pour pouvoir répondre au plus près à leurs attentes.
Le coût d’un tel accompagnement sur un projet n’est certes pas négligeable, même comparé au coût des systèmes. Il contribue cependant de manière visible à faire de l’implémentation d’un système un succès. C’est donc une dépense qu’il faut voir comme un investissement qui augmentera de façon significative le retour du service de travail collaboratif, en terme d’efficacité, de qualité et de productivité des utilisateurs.
5 février 2008
