Une fois identifiée une catégorie de solution (un bus de données) répondant au besoin du client, nous abordons un problème complexe, les solutions seront structurantes pour le logiciel et difficiles à remettre en cause. Nous sommes devant un choix d'architecture.
Nous savons que ce choix nécessitera des développements longs, et que nous devons quand même être capable de mettre en production des changements fonctionnels mineurs pendant ce laps de temps. Donc soit nous sommes capable de faire une implémentation progressive de la solution, soit nous faisons une branche logicielle.
Le contexte, et la volonté de limiter les risques inhérents à la décision impliquent les contraintes suivantes :
- Nous faisons ce choix le plus tard possible, afin de retarder le point de non retour, et éventuellement avoir de nouvelles informations qui pourraient guider notre choix
- Nous voulons prouver que la solutions choisie répond aux exigences du client : pas d'impact sur les performances du service, pas de perte de statistiques, pas de SPOF (single point of failure), possibilité de pouvoir suivre la croissance du site (scalabilité horizontale), QoS du temps d'insertion en base < 10s
- Nous voulons avoir des alternatives, pour comparer sur des critères objectifs : difficulté de mise en œuvre, nombre de lignes de code, comportement de la solution en charge, adhérence de la technologie, contraintes d'exploitation
- Nous avons une date limite de prise de décision fixe sans quoi le planning prévu ne sera pas tenable
Nous avons aussi des atouts :
- une équipe qui commence à se constituer et qui est solidaire
- des développeurs compétents
- des infrastructures techniques nous permettant de limiter les risques :
- des tests d'acceptance (sous fitnesse) et d'intégration (junit) sur les statistiques, nous assureront le contrôle des non régressions
- une plateforme de bench quasiment iso-production pour mesurer le comportement en charge des spikes
- une équipe système à proximité pour nous aider
Nous abandonnons assez rapidement la solution "maison", d'une part car la difficulté d'implémentation est importante, et nous ne voyons pas comment arriver à la fin de la période de spike avec une solution "fonctionnelle". D'autre part, car la problématique du bus de données, est implémentée dans plusieurs produits arrivés à maturité.
Nous choisissons d'évaluer :
- ActiveMQ, broker JMS open source reconnu et utilisé dans notre société
- RabbitMQ, broker AMQP en erlang, dont nous avions beaucoup entendu parler à la QCon
- Qpid, autre boker AMQP de la fondation apache
edit le 25/01/2011 : reformulation de la première phrase