Publication économique d’un projet en démarrage

L’étape logique après avoir rêvé, analysé et programmé un logiciel web, c’est sa publication. Pour maximiser le succès d’un site, il faut s’assurer que le site soit à l’écoute, performant et spacieux. À moins d’avoir les poches creuses, trouver un bon dosage de ces 3 caractéristiques peut mener à certains compromis.

Conserver les données

Dans le cas de ActivityMapper, une chose est certaine, il faut de l’espace. Voici un bref calcul pour comprendre les besoins du système. Une activité sportive de 2 ou 3 heures qui y sera affichée sur la carte, avec le temps, les pulsations cardiaques et l’altitude à chaque point coûtera en moyenne 50KB. Prenons en exemple le cas typique d’un sportif qui s’adonne 3x par semaine l’été au vélo de montagne et l’hiver au ski de fond. S’il veut garder la forme, il le fera sans arrêt pendant toute l’année, soit 52 semaines dans une année. Sa consommation d’espace annuelle sera donc estimée à 7.6MB.

À première vue, ça ne parait pas beaucoup, mais comme l’objectif est de tout conserver, aussi bien s’assurer de viser haut. Pour rappel, le site utilise une base de données de type SQL Server. Après avoir épluché bon nombre d’hébergeurs compatibles avec cette technologies, j’en suis venu à comprendre qu’ils offrent la plupart du temps des bases de données de 200MB. Tout dépendamment du montant déboursé, on peut avoir plusieurs instances de cette taille. N’empêche que ça semble géré par une question de licence alors c’est pas très discutable. Certains m’ont proposé d’utiliser plusieurs bases de données si j’ai besoin de beaucoup d’espace. On rentrera pas dans les détails ici mais c’est comme pas l’idéal pour un programmeur de fonctionner comme ça. Dans mon cas c’était carrément hors de question.

Cette contrainte m’a donc fait ressortir ma calculatrice. J’ai été stupéfait de réaliser qu’avec un tel forfait, ma base de données s’emplira en un an si je réussis à atteindre le plateau des 26 contributeurs. Une fois pleine on fait quoi? Pas question de supprimer des activités, le but premier du site est de les conserver!

Isoler la base de données du code

N’en fallait pas plus pour que l’idée de changer de technologie est revenue d’actualité. Lors de la refonte majeure du site en ASP.NET MVC, l’accès au données a aussi été refait. J’en ai beaucoup discuté avec Vincent Girard, de chez SpektrumMedia, et il m’a convaincu que NHibernate était une solution fantastique pour l’accès aux données. C’est donc ce que j’ai utilisé. Le résultat est une couche d’abstraction entre le code et la base de données.

N’en fallait pas plus pour ouvrir la possibilité de changer de moteur de bases de données. Pour différentes raisons, c’est PostgreSQL qui a hérité du contrat. Comme il s’agit d’une technologie open source, elle n’impose pas de limites liées à sa licence d’utilisation.

Autre chose, quand on apprend une nouvelle technologie et qu’on a pas de contraintes particulières, on est porté à apprendre la dernière version. Cependant, les hébergeurs qui proposent des solutions toutes faites sont rarement aussi à jour parce qu’ils préfèrent s’assurer que la technologie est mature avant de l’offrir à leur clientèle. J’ai aucun problème avec ça et je les comprends bien de vouloir offrir un maximum de stabilité, sauf que dans mon cas, ça m’impose de connaitre les différences entre la version que je viens d’apprendre et celle qu’ils offrent.

Cloud computing

Tant qu’à abattre les obstacles, aussi bien le faire proprement. Pour se débarrasser des problèmes de versions, y’a pas mieux que de prendre le contrôle du serveur. Traditionnellement, ça prenait un serveur dédié pour avoir ce type de liberté. Cependant la virtualisation ayant beaucoup progressé, pourquoi ne pas tirer avantage du cloud computing?

Une petite visite chez Rackspace Cloud m’a convaincu. J’ai opté pour le forfait 40GB d’espace pour 43.80$US par mois. On passe donc de 26 à 5389 contributeurs selon mon calcul précédent, et ce, pour un prix comparable. Ce qui est encore plus génial avec ce type d’hébergement, c’est qu’on peut augmenter ou diminuer la quantité de ressources via une petite interface web de configuration. Ça devient donc possible de changer de forfait, appuyer sur reset et en dedans de quelques minutes, le site est exactement pareil mais plus rapide et spacieux!

Émuler .NET sous Linux

Rackspace offre des serveurs qui roulent sous Windows, mais pas à l’époque où j’avais opté pour leur service. C’était donc une distribution de Linux ou rien. J’ai donc entrepris de tester ActivityMapper avec Mono/Apache plutôt que ASP.NET/IIS. Ça s’est avéré une bonne chose parce que ça a fonctionné avec un minimum d’efforts. Ça m’a aussi permis de couper encore dans les coûts d’hébergement.

Il faut savoir que pour qu’un site fonctionne sous Mono, il faut éviter d’utiliser les namespace commençant par Microsoft. Ils dépendent bien souvent des fonctionalités qu’on ne retrouve que sous Windows, ce qui est un frein à la portabilité. J’utilisais entres autres une librairie OpenID, DotNetOpenAuth si je me souviens bien, qui utilisait ces namespaces. Il parlaient d’améliorer la situation à l’avenir mais le mal était fait. Une partie de la migration a donc impliqué le changement de cette librairie pour une autre. La leçon retenue est que mieux vaut s’en tenir aux namespaces System quand on code des librairies en .NET.

C’est donc le setup actuel de ActivityMapper en production. Il est aussi stable que s’il avait été hébergé chez du Microsoft, mais pour une fraction du prix. En fait, j’ai pas souvenir qu’il ait été down une seule fois en plus d’un an d’opération 24h/24.