Stadium : une architecture conçue pour le nuage

SIMCO Technologies offre un logiciel-service (SaaS) à sa clientèle qui leur permet de calculer le vieillissement d’une structure de béton (pont, viaduc, quai, etc.) en fonction de différents paramètres environnementaux et chimiques. Suite à l’obtention d’un important contrat, il a été jugé d’adapter et moderniser l’architecture de ce logiciel pour améliorer sa performance et sa fiabilité. SIMCO a alors confié le mandat à Ovologic pour la conception et une partie de la réalisation de cette nouvelle version de leur produit.

 

Lorsqu’on offre un logiciel web sur internet, on doit impérativement répondre à des critères de base. Étant donné que l’on contrôle peu le niveau d’utilisation que nos clients peuvent en faire, il est crucial de prévoir une utilisation variable de ce dernier tout en conservant le même niveau de performance en tout temps à tous les utilisateurs. Auparavant dans les architectures traditionnelles, on planifiait en fonction du plus grand achalandage prévisible où on suivait nos limites budgétaires tout espérant que ça allait être suffisant. Toutefois, ce n’est vraiment plus la meilleure façon faire. On dépense alors parfois pour trop d’équipement qui sera la plupart du temps utilisé minimalement et sera à d’autres moments insuffisant suite à une charge d’utilisation inattendue. En autres mots, ça va finir par planter.

Une architecture réellement « cloud »

J’ai alors repensé l’architecture de leur logiciel Stadium en fonction de l’un des avantages majeurs exclusifs au « cloud computing ». Dans le nuage, il est possible d’allouer des ressources sur demande et de s’en départir aussitôt que le besoin est n’est plus là. Dans ce cadre de ce projet, le système allouera une machine virtuelle sur demande pour chacun des calculs lancés par l’utilisateur. Lorsque les calculs se terminent, les résultats du calcul seront stockés pour consultation ultérieure et la machine sera aussitôt détruite. On est alors facturé quelques dollars pour le peu d’heures de fonctionnement que cela représente.

En fonctionnant ainsi, l’application peut recevoir en théorie une quantité illimitée de demandes de calculs simultanément. On crée des machines virtuelles en parallèle pour chaque demande de calcul. On est seulement limité par l’infrastructure du fournisseur en nuage que nous avons choisi. Dans ce cas présent, nous avons choisi Amazon pour la maturité de leur offre de service, leurs prix et plus précisément la souplesse de leur API de programmation qui nous permet d’automatiser la création et la destruction des serveurs virtuels. Chez Amazon, on prétend qu’il est possible d’en lancer des milliers simultanément!

Ruby avec Sinatra

Les technologies de programmation choisies ont été sélectionnées sur des critères de temps de programmation et leur niveau de complexité pour réaliser cette architecture logicielle. Ruby avec le framework Sinatra a alors été choisi pour la portion d’orchestration de la solution. Un API REST est en cours de réalisation en utilisant cette fondation de programmation légère qui permet d’accélérer significativement le développement des fonctions prévues.

La preuve de concept a été réalisée par Marc Lacoursière de RooSoft. Il poursuit le développement en étroite collaboration avec l’équipe interne chez SIMCO qu’il a aidé à former sur les nouvelles technologies sélectionnées. Marc est un programmeur d’expérience de haut calibre qui a la curiosité nécessaire pour rester toujours à jour avec les technologies émergentes.

C’est agréable de constater l’avancement de ce projet au fil des mois et le voir naître. Ça sera de la pure magie à voir aller en production.

Amazon Silk, le nuage informatique qui carbure le navigateur web

Amazon a lancé hier sa nouvelle tablette Kindle Fire qui sera munie du nouveau fureteur Silk. Amazon a profité de son avantage et sa connaissance du cloud computing pour créer un fureteur très léger en déplaçant la majorité du traitement pour afficher des pages web dans son architecture EC2 sur le nuage.  Ceci est une excellente démonstration comment on peut revoir l’architecture d’un système avec ce nouveau changement de paradigme dans le monde des technologies de l’information. Ainsi, Amazon envoie uniquement le rendu et le nécessaire à la minuscule tablette. L’échange de données entre les serveurs d’Amazon et la Kindle Fire sera limité et optimisé pour augmenter la vitesse de navigation et améliorer l’expérience utilisateur.

Je vous invite à regarder cette vidéo qui explique très bien le concept :

Cette innovation va encore plus loin que la philosophie Chrome de Google. Google travaille d’arrache-pied à optimiser le code source du fureteur installé chez le client. Le fureteur de l’utilisateur doit donc toujours bâtir les pages web avec ses différents éléments (images, sons, feuilles de style, etc.) et ce logiciel doit être mis à jour localement lorsque de nouvelles versions sont disponibles. Toutefois, cette idée s’inspire de Google Mobilizer qui transforme une page web standard en sa version plus adaptée au mobile.

Pour en savoir plus sur Amazon Silk, veuillez visiter le blogue officiel.