Par Fabien WIRIG chez SOAT
Sur les vingt dernières années, le nombre d’utilisateurs d’Internet dans le monde a crû de façon exponentielle. De quelques 147 millions en 1998, ce nombre a été multiplié par 27, pour atteindre 4,1 milliards aujourd’hui. Parallèlement, le trafic de données sur Internet connaît une croissance annuelle de l’ordre de 24 %, et devrait donc être multiplié par neuf dans les dix années à venir.
La question aujourd’hui n’est donc plus de savoir si une personne a accès à Internet, mais plutôt comment elle y accède, par quel type de matériel (ordinateur, tablette, smartphone, IoT, etc.) et par quel type de réseau (fibre, ADSL, 3G/4G/5G, etc.) les données transitent. Ces évolutions et nouvelles habitudes changent la nature de nos applications qui doivent désormais supporter une plus grande charge d’utilisateurs, devenus eux-mêmes beaucoup plus exigeants sur la qualité et la réactivité du service attendu.
Dans ce contexte, comment les applications doivent-elles se transformer pour répondre à ces nouvelles contraintes ?
Auparavant, une application se contentait de communiquer avec une seule base de données. Aujourd’hui, elle doit composer avec des sources de données de natures hétérogènes : SQL, NoSQL, APIs, Webservices, etc. Outre ces aspects techniques, l’évolution du marché accélère aussi, et les applications doivent être capables de s’adapter à ces évolutions, en proposant régulièrement de nouvelles fonctionnalités. Elles doivent aussi être résilientes, c’est-à-dire rester accessibles en permanence tout en détectant et résolvant les problèmes rapidement pour rester performantes, quitte à fournir un service légèrement dégradé.
La pertinence des architectures réactives
Pour s’adapter sereinement à ces nouvelles contraintes, les DSI peuvent opter pour une stratégie globale au niveau de leur SI en le faisant évoluer vers une architecture réactive. Ce modèle d’architecture permet d’embrasser tous ces changements, qu’ils soient techniques ou fonctionnels, et s’avère particulièrement pertinent pour les applications interagissant en temps réel avec les utilisateurs. Les applications basées sur une architecture réactive sont alors capables de fonctionner mêmes lorsqu’un problème survient. L’enjeu aujourd’hui n’est plus de gagner en performance, mais bien de pouvoir compenser les pannes rencontrées. Ces problèmes deviennent alors des « non-événements ». Une architecture réactive est donc bien une architecture « Designed For Failure ».
La mise en place d’architectures réactives est complexe, ajoute des niveaux d’abstractions et vous mettra à l’épreuve avec des challenges qui ne seront pas toujours faciles à relever. Pourquoi tous ces efforts, toute cette complexité ? Pour que l’utilisateur, même lorsqu’une plateforme aura un fonctionnement dégradé, ne se rende compte de rien. L’architecture réactive est donc un sujet-clé pour les directions des systèmes d’informations.