Ovologic devient partenaire technologique de I²S Finance est un article provenant du blogue d'Evollia

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.

Stadium : une architecture conçue pour le nuage est un article provenant du blogue d'Evollia

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

4 ans de possibilités infinies grâce à la plateforme Facebook est un article provenant du blogue d'Evollia

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 :

• Check in for frequent traveler rewards from Starwood (Foursquare Blog)

API des réseaux sociaux : ne laissez pas des opportunités sur la table est un article provenant du blogue d'Evollia