Dans tout développement d'application interactive, de site web, de microsite, une évaluation sommaire de l'achalandage sur le dit site doit être faîte pour estimer à l'avance le genre de déploiement serveur qui sera nécessaire pour palier à la demande. Avec la nouvelle réalité des réseaux sociaux et du caractère virale de certaines applications ou microsite, il est extrêmement difficile de prédire avec exactitude l'achalandage. Malheureusement, dans certain cas et pour certain serveur, une différence de 2 000 usagers à l'heure dans les périodes de pointe peut signifier la différence entre un serveur bien portant et un serveur avec la langue par terre.Tout dépendant du type d'application (application avec usage extrême de la base de données, application plutôt statique, application avec utilisation extrême du vidéo) il est souvent difficile de s'en sortir pour les compagnies sans débourser une bonne somme d'argent en serveur balancé ou encore en serveur de "streaming".

Alors quoi faire pour s'en sortir sans briser son cochon ? Pour être sûrs de répondre à la demande tant au niveau de la bande passante que des cycles de processeurs nécessaire pour répondre aux requêtes incessantes de tout ces utilisateurs en besoin de navigation.

Il existe plusieurs options. Tout d'abord nous pouvons toujours confier notre produit entre les mains de services d'hébergement mutualisé ou encore de serveurs dédiés (par exemple avec iweb et 1and1)  si on pense que l'achalandage ne requiert aucune infrastructure serveur faramineuse et que la demande en bande passante ne sera pas exhaustive.

Si notre application utilise la vidéo de façon intensive, ce qui souvent est problématique dans le cas d'achalandage élevé sur des serveurs mutualisé, il y a toujours l'option de placer les vidéos sur un serveur de "streaming" (par exemple avec stream the world) ce qui est en soi la meilleure option mais qui souvent implique des coûts importants. Une option intéressante pour assurer un achalandage quasi infinie pour ce genre d'application est d'utiliser un service comme le S3 D'Amazon qui utilise la force du réseau d'Amazon (effectivement c'est bel et bien celui du magasin en ligne Amazon) et qui implique un coût ridiculement bas pour la bande passante.

Dans un dernier cas de figure, si on pense que notre application ou microsite sera assaillit par les utilisateurs, peu d'option s'offrent à nous. La première est de se retourné vers les services d'hébergement personnalisé où le nombre de serveurs requis sera mis en place pour affronter la charge utilisateur avec les coûts énorme que cela implique. La deuxième est d'utiliser les services d'hébergement qu'on appelle "cloud computing", la nouvelle coqueluche en fait d'hébergement de haut niveau et de flexibilité.

Qu'est-ce que le "cloud computing" ? Et bien c'est un type d'hébergement qui permet de configurer un type particulier de serveur qui sera automatiquement cloné en fonction de la demande utilisateur sur notre application ou microsite. Ce qui veut dire que l'application répond rapidement peu importe la demande. Et combien cela coûte-t-il ? Et bien pour la plupart des services de "cloud computing" tel que Mosso et Amazon EC2 les coûts sont calculé en fonction de la bande passante utilisée ainsi que les cycles de processeurs utilisés. Plus de clone nécessaire pour faire rouler votre application, plus de coûts. Les coûts au niveau de la bande passante et des cycles processeur sont extrêmement bas ce qui rend cette option encore plus intéressante.

Bref, il y a maintenant beaucoup de moyens de répondre à la demande des utilisateurs sans investir des sommes considérable dans des services qui sont difficile ensuite a gérer et qui demande du personnel qualifié. Seul l'avenir nous le dira mais j'ai une certaine intuition que le "cloud computing" sera le type d'hébergement le plus utilisé d'ici quelques années.