Les architectures massivement parallèles

Issues des grands acteurs du Web tels que : LinkeIn, Amazon, Netflix … ces technologies ont le vent en poupe. Qu’en est il de leurs bénéfices, mais aussi des écueils et risques potentiels pour une mise en œuvre effective au sein de S.I. plus « traditionnels » ?

Tout d’abord, il convient de rappeler comment ces technologies ont vu le jour. Elles ont été mises au point par les géants du web, en regard de leurs besoins de traiter d’énormes masses d’information, et face au limitations des infrastructures traditionnelles.

Elles ont été ensuite pour la plupart publiées en mode open source, en partie supportées par la fondation Apache.

Ensuite, une typologie basique peut être établie, en distinguant trois domaines essentiels:

• le traitement des flux de données, on parle le plus souvent de streaming : Kafka, ActiveMQ, RabbitMQ
• les moteurs de traitement distribués : Spark, TIBCO streambase ou encore IBM Infosphere streams
• les supports de persistance, à savoir file system: GoogleFS, Hadoop…et base de données: Cassandra, Bigtable, Hbase, MongoDB, …

… pour ne citer que les plus connus d’entre eux.

La promesse de ces offres est de pouvoir construire une nouvelle génération de systèmes, en rupture sur le plan :

• des performances, avec une scalabilité quasi infinie
• de la robustesse, avec une tolérance aux pannes « native »

Ce qu’on peut en retenir aujourd’hui est que ces technologies sont bien établies dans le monde du big data, au travers notamment de l’écosystème Hadoop, mais d’un usage encore émergeant pour la construction de systèmes transactionnels.

Dans le cadre de ce dernier type d’usage, on retiendra les points d’attention suivant :

• une courbe d’apprentissage significative, pour les développeurs mais surtout les exploitants dans la mesure ou leur mise en œuvre relève de nouveaux paradigmes
• un paramétrage complexe, qui doit être maîtrisé et éprouvé pour le fonctionnement en grandeur réelle
• une intégration délicate dès lors qu’elles sont mise en œuvre conjointement. La résilience individuelle des composants ne garantit pas nécessairement celle d’un système dans son ensemble pour couvrir tous les scénarios envisageables de panne et de repise (à chaud, à froid…) en cas d’incidents
• la maîtrise temporelle des flux
• l’intégrité transactionnelle, qui n’est pas garantie nativement

En conclusion, ces technologies dont désormais incontournables, notamment dans le contexte des métiers de plateforme ayant à traiter de grandes volumétries de flux, mais appellent à, sécuriser leurs usages, au travers :

• d’une véritable réflexion d’architecture en amont permettant de bien définir les cas d’usage et conditions de mise en oeuvre
• d’une définition et une organisation pertinente pour les tests, la qualification et leur appropriation réussie par les exploitants.