Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
