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.

4 ans de possibilités infinies grâce à la plateforme Facebook

La plateforme de développement de Facebook célèbre ses 4 ans. Elle a permis à des développeurs tiers ou externes d’utiliser les fonctionnalités du plus grand réseau social au monde dans leurs applications ou sites externes.

Malgré que ça fait 4 ans, je suis toujours un peu déçu de voir comment on s’en sert mal au Québec. Le développement informatique basé sur des API publiques comme celui de Facebook est souvent peu coûteux et peu risqué. Le programmeur s’appuie sur du solide qui est déjà déployé sur le web. La seule limite est votre imagination!

J’ai déjà fait quelques applications client pour Facebook, mais je rêve tout de même de faire de quoi très novateur et intégré avec cette plateforme. Quelqu’un d’intéressé dans la salle? :-)

Je vous invite à lire aussi : API des réseaux sociaux, ne laissez pas des opportunités sur la table

API des réseaux sociaux : ne laissez pas des opportunités sur la table

Un article intéressant sur le blogue de Foursquare nous apprend que la chaîne hôtelière Starwood Hotels a jumelé son programme de fidélité avec l’API de Foursquare. Un client peut donc gagner des points dans leur programme maison de fidélité lorsqu’il fait un « check-in » Foursquare dans plus de 1 000 établissements à travers le monde.

C’est d’ailleurs le genre de projet que j’ai à l’occasion avec des agences web qui veulent enrichir leur offre de service en ajoutant des fonctionnalités avancées aux campagnes web qu’ils conçoivent pour leurs clients. L’API de Twitter ou encore mieux celui de Facebook ont des possibilités fascinantes et souvent très intéressantes pour les clients finaux. J’ai récemment monté un projet pilote « mashup » avec l’API de Foursquare et un autre API. Avec peu d’efforts, j’ai été capable de produire une application web complète et fort utile.

Je vous invite à lire la documentation de ces API ou, si vous préférez, me contacter pour qu’on puisse regarder ensemble comment ces API publiques peuvent s’intégrer dans vos projets. Il serait dommage de laisser ces opportunités sur la table.

Pour en savoir plus :

Dossier Santé Québec : l'informatique distincte

On apprend après des mois de rumeurs que le projet de dossier de santé électronique coûtera 900 millions de plus que les 563 millions prévus au départ en 2006. Le vérificateur général a publié un rapport sur l’état de ce projet qu’il qualifie d’échec. Malgré que je n’ai pas travaillé directement sur ce projet, plusieurs confrères informaticiens qui ont oeuvré dessus m’ont confié la volonté de réinventer la roue dès le départ. C’est justement ce qui est révélé dans cet article :

Interrogé sur le DSQ en point de presse, M. Lachance a expliqué que, après quatre ans de travail, le ministère de la Santé avait carrément changé de cap. Au lieu de créer une base de données unique qui pourrait être consultée partout au Québec, on s’est rabattu sur la solution qu’avaient choisie toutes les autres provinces, l’arrimage des systèmes qui existaient déjà.

via Denis Lessard de la Presse.

Semble-t-il on a voulu mettre de côté les standards qui sont adoptés à l’échelle internationale pour faire une solution pour notre société distincte. Pourtant, c’est complètement à contre-courant cette façon de faire en TI. Ça va à l’encontre des bonnes pratiques.

Il y a quelques années, c’était les progiciels qui ont amené une vague de standardisation dans le but de réduire les coûts en développement de système neuf. Toutefois, j’avoue que ça n’a pas toujours fonctionné parfaitement. Présentement, on voit la vague des logiciels en ligne (SaaS) où on n’a pas à défrayer pour leur implantation et leur déploiement. Le gouvernement américain a déjà commencé à utiliser des solutions comme Salesforce pour les centres d’appels de certains services. J’ai appris que la solution en ligne de recrutement de Taleo sera utilisée à la nouvelle Agence du revenu du Québec. C’est un pas dans la bonne direction pour mieux contrôler les risques et les coûts.

On n’est pas si différents

Cessons de penser qu’on est différents du reste de la planète. Oui on parle le français différemment de nos cousins à l’autre côté de l’Atlantique et oui, on mange de la poutine. Mais, des systèmes de santé sont semblables à travers le monde.

Manque de direction politique en TI

Arrêtez de confier uniquement aux technocrates les orientations technologiques de l’État. Ce patrimoine numérique (superbe expression propulsée par Cyrille Béraud lors des audiences pour le projet de loi 133) est stratégique dans la réduction de coût et la modernisation de la reddition des services aux citoyens. Toutefois, un député m’avait déjà confié que les technologies c’était l’affaire des fonctionnaires. Si on continue comme ça, la classe politique devra toujours se défendre après des fiascos comme celui-ci.

Ce projet demandait une direction politique claire et ferme. De ce que j’ai compris, les administrateurs de quelques gros centres locaux de santé au Québec se sont imposés au cours du projet. Ceci aurait allongé l’échéancier et aurait du même coup personnalisé davantage la solution finale. La direction du projet aurait dû avoir autorité sur les centres de santé et les hôpitaux du réseau. Les projets importants auxquels j’ai participé et qui ont été un succès étaient dirigés avec aplomb et constance. Le promoteur du projet, en l’occurrence le ministre de la Santé, aurait dû exercer une autorité sur le réseau de la santé jusqu’à écarter les éléments troubles dans la réalisation du projet.

Je réitère ce que je martèle depuis des mois (ici et ici), les TI doivent faire leur entrée dans l’espace politique. Ils doivent y être au moment de leur planification et non seulement quand ils deviennent des scandales médiatiques. Le gouvernement du Québec devrait aller dans le sens des autres gouvernements dans le monde et nommer un responsable politique uniquement pour les technologies de l’information. À 2,5 milliards par année, j’estime que ce poste budgétaire mérite cette attention.