DSI, il est temps de passer à la programmation fonctionnelle

La révolution digitale pousse les systèmes d’information à leurs limites. Face à des flux de données toujours plus importants, il est temps de changer de manière de développer des programmes et d’adopter la programmation fonctionnelle, et d’oublier le C, le C++ et le Java.

Avec les mobiles, les tablettes et bientôt une multitude d’objets connectés, les systèmes d’information sont à bout de souffle alors même que les serveurs informatiques disposent de toujours plus de puissance de calcul. Il devient impératif d’exploiter au mieux la puissance de ces serveurs afin de délivrer la qualité de service attendue par les utilisateurs.

Stratégie disruptive

C’est ce que préconise Philippe Prados, en charge de l’équipe « Architecture Réactive » chez la société de conseil Octo Technology. « Il faut adopter de nouvelles stratégies disruptives de développement » affirme-t-il.

L’approche disruptive pour une DSI, insiste Philippe Prados, « c’est de décrire les fonctions de calcul, et de laisser le système décider de comment les exécuter. Le système d’information doit passer en mode réactif.»

Programmation fonctionnelle

Pour cela, il s’agit d’adopter la programmation fonctionnelle.  « C’est une révolution au sein des DSI, car cela implique de revoir complètement la manière dont on conçoit et on programme » les applications. D’abord, il faut construire des solutions qui ne modifient pas le passé, chaque donnée étant immutable, c’est à dire ne changeant pas dans le temps.

Ensuite, il faut former les équipes de développement à la programmation fonctionnelle.On adopte de nouveaux langages fonctionnels tels que Clojure ou Scala. Et on laisse de côté la programmation dite « impérative » avec C, C++ ou Java.

Utiliser toute la puissance 

SPARK et Akka, qui sont des moteurs logiciels au cœur de la révolution Big Data, ont été écrits en langage Scala. Le succès de NodeJS – un serveur Web codé en JavaScript avec un seul thread – et Clojure proposent également des approches en rupture.

Ces langages fonctionnels permettent de maximiser la puissance disponible sur les serveurs en utilisant chaque processeur ou chaque core, non plus à 15%, mais à 90 ou 100%. On profite ainsi des  processeurs multi-core à 64 bits qui offrent désormais à tous la possibilité de paralléliser et de déporter une grande partie des traitements et de la gestion des états en mémoire.

Il existe bien des solutions pour étendre Java et obtenir de meilleures performances  – comme les « Value Object » dans Java 9, ou comme Kafka le fait pour contourner les limites de la JVM -, mais cela ne permet pas de réellement changer de paradigme.

Un système réactif

Il est temps de passer à un système réactif. Un système réactif, comme défini dans le Manifeste Réactif (http://www.reactivemanifesto.org/fr), « doit toujours être disponible pour répondre (availability), être robuste (resilient), souple (elastique) et orienté message. Un système d’information développé selon ces directives est plus flexible, à couplage faible et extensible ».

Cette vision systémique du système d’information impose donc que chaque composant soit réactif, sinon, on risque de revenir à des goulets d’étranglement.

Erlang et Orléans

Cela remet sur le devant de la scène des « frameworks d’acteurs » pour la programmation. L’un des langages d’acteur le plus connus est Erlang. Le géant Microsoft travaille pour sa part sur un langage fonctionnel réactif nommé Orléans, destiné à être utilisé dans son Cloud Azure. Orléans devrait faciliter la formation et le basculement des équipes informatiques vers le fonctionnel, en utilisant les mêmes outils.

Dans la programmation par modèle d’acteur, on considère les acteurs comme des entités autonomes, qui sont responsable de leurs données, et permettant une forte concurrence. Les acteurs communiquent par échanges de messages. En réponse à un message, un acteur peut effectuer un traitement local, créer d’autres acteurs, ou envoyer d’autres messages.

La pression de l’omni-canal

Cet usage de la programmation fonctionnelle permettra de répondre aux nouveaux défis. La révolution digitale et l’évolution rapide des usages poussent les systèmes d’information actuels à leurs limites. Les architectures client-serveur, portée par l’écosystème Java et .Net, les langages de programmation impératifs et les bases de données relationnelles ne sont plus adaptés à la charge induite par les accès omni-canaux.

Les flux d’information reçus et émis par les smartphones, les tablettes, les PC, les TV connectées et bientôt les autres objets connectés forcent les DSI à ré-imaginer leur système d’information. Ce sont tous les maillons de la chaine qu’il faut revoir.

Les systèmes d’information submergés

De nos jours, lorsqu’on met en place une nouvelle application ou un nouveau service, on peut s’attendre à des millions de requêtes provenant d’utilisateurs connectés qui ne supportent plus d’attendre.

Pour offrir un service de qualité, il convient de revoir l’ensemble de la chaîne de traitement, des modèles de programmation, en passant par les bases de données, les stratégies de cache des informations et en assurant une disponibilité à toute épreuve.

Google pionnier

Ce sont Google, Facebook ou Amazon qui, les premiers, ont dû faire face aux limitations des solutions techniques usuelles. Ils ont alors du réinventer, parfois dans la douleur, toutes les strates du système d’information.

Les architectures client-serveur, bien maîtrisées et déployées dans toutes les grandes entreprises sont à bout de souffle. Les serveurs toujours plus puissants utilisent en moyenne à peine 15 à 20% de leur capacité, passant la plupart du temps dans des cycles d’attente et de synchronisation, dus aux temps de traitement et au formatage des données. Les bases de données n’arrivent plus à gérer à des coûts raisonnables la quantité et la variabilité des flux d’information.

Intégrer les mobiles

Les entreprises ayant dépensés des millions d’euros dans des architectures SOA, peinent à proposer des accès compatibles avec les contraintes des matériels mobiles, limités en bande passante (3G) et à la qualité variable.

Enfin, les langages de programmations utilisés gèrent généralement les entrées-sorties de manière synchrone, et s’appuient sur des machines virtuelles (JVM pour Java ou CLR pour .Net) qu’il est extrêmement difficile d’optimiser.

Le domaine de la banque a déjà connu ce problème, avec l’émergence du trading haute fréquence. Désormais, toutes les industries sont touchées, afin de servir les clients à « haute fréquence ».

Revoir les composantes technique du SI

Les types de base de données se diversifient, et le mouvement NoSQL propose des solutions pour stocker tout type d’information. Il est parfois nécessaire de relâcher l’obligation de consistance de la donnée, au profit de sa disponibilité et de tolérance aux pannes (théorème CAP).

La base de données étant utilisée pour stocker des données immutables (qui ne change pas dans le temps), et qui permettent à la fois de conserver l’historique (et de le rejouer en cas de panne), mais aussi de permettre le développement des solutions Big Data.

Les données immutables et les traitements en mémoire sont aussi extrêmement efficaces pour gérer des flux de données et non plus des transactions atomiques. Ce changement de paradigme, de la transaction au flux de données, impose désormais de reconstruire une partie du système d’information.