11-01-2024 14:00:28
La colonne vertébrale digitale est le système nerveux de l'entreprise. C'est physique ! Un ensemble de câbles et de machines qui relient tous les pans de l'organisation à tous les autres pans de l'organisation et aux acteurs de l'écosystème de l'organisation. C'est un système de tuyauterie capable d'acheminer des messages d'un point à l'autre.
En d'autres termes, il s'agit d'avoir des voies de communication entre la comptabilité, les ventes, le marketing, … mais également avec les clients, les fournisseurs, les distributeurs, les autorités, …
Sans colonne vertébrale digitale il n'est point de transformation digitale !
Rappel
2 contraintes, 2 objectifs, 5 piliers, 1 système nerveux
Pour rappel, 2 contraintes[1] , fortes agissent sur l'entreprise :
- L'élimination des frictions (tendance à la simplification, à la flexibilité, à l'adaptabilité, …)
- Le AAA (Anything — Anywhere — Anytime) : pouvoir tout faire, n'importe où, n'importe quand
Pour pouvoir rencontrer et s'adapter à ces contraintes, on positionne 2 objectifs majeurs :
- Une orientation client véritable et sincère qui dépasse les discours convenus
- Une force de travail engagée parce qu'heureuse qui peut exercer et développer son expertise, qui bénéficie d'autonomie et qui puisse donner du sens à son travail (MAP — Mastery, Autonomy, Purpose).
Les zones de contact (là où le combat va s'engager) sont dénommées les piliers qui sont au nombre de 5 :
- Les produits et services
- Les canaux de distribution
- Les canaux de communication
- Les méthodes de travail, l'organisation interne, les processus, …
- L'accélération des cycles
La colonne vertébrale est cette étoile qui apparaît et qui relie les organes internes de l'entreprise ainsi qu'elle la connecte à son monde extérieur selon les 5 zones de contact présentées ci-dessus. C'est un système nerveux, parcouru d'impulsions. Que vous voyiez cette colonne vertébrale digitale comme un ESB ― Enterprise Service Bus n'est qu'une forme de matérialisation.
L'épine dorsale
Pour que le digital puisse se développer il est INDISPENSABLE de disposer d'un système nerveux digital dont l'objectif est (1) de relier les organes entre eux – entendez départements – mais aussi (2) de connecter l'organisation aux autres organismes qui composent le système dont elle fait partie, le monde donc dans une économie globalisée.
C'est au travers de ce système nerveux digital qu'ont lieu les échanges digitaux. L'organisation continue à entretenir d'autres types d'échanges, physiques ceux-là , mais le processus de digitalisation et de dématérialisation exerce une pression pour migrer les échanges de la sphère physique à la sphère digitale au fur et à mesure de son propre développement. Il s'agit d'échanges bidirectionnels, entrants et sortants, qu'il est facile de se représenter au travers de l'exemple d'une imprimerie digitale : le client peut envoyer ses documents à imprimer au travers d'une connexion électronique et recevoir toutes informations utiles qui concernent sa requête, la progression de son traitement, et sa livraison; l'impression papier restant, elle, physique bien entendu.
On est donc bien en présence d'un système nerveux qui relie l'ensemble des départements (les organes) de l'organisation mais également l'organisation à ses acteurs extérieurs (l'organisation est un des organismes d'un système plus large).
Un système d'impulsions
Par le système nerveux digital transitent 3 formes d'impulsions : exécutoires, sensitives (ou sensorielles), ministérielles.
Les impulsions exécutoires sont des requêtes d'exécution. Les sensitives (ou sensorielles) sont des impulsions de statut (senseurs). Les impulsions ministérielles, quant à elles, sont des requêtes de service qui peuvent s'apparenter à des impulsions exécutoires mais qui néanmoins s'en distinguent et on verra ici plus bas en quoi.
Nature d'une impulsion
L'impulsion qui parcourt le système nerveux digital a une forme. C'est un message ! Ce message est une forme de contenu disposé dans une enveloppe. L'enveloppe elle-même comporte des métadonnées concernant le contenu qu'elle contient : type de message (email par exemple), origine (département marketing par exemple), destination (département vente, par exemple), poids et/ou dimension (200 kbytes, par exemple), type de contenu (texte, image, vidéo, …), urgence (prioritaire ou non, …), version, etc.
L'enveloppe est toujours la même (même structure);
le contenu, lui, varie. Le transport des impulsions
par le système nerveux ne verifie pas le contenu (sauf cas de routage
intelligent basé sur le contenu); seule l'enveloppe est examinée,
du moins dans la grande majorité des cas. Il en découle qu'on cherche Ã
standardiser le couple enveloppe + contenu (on doit pouvoir
clairement distinguer ce qui, dans l'impulsion, appartient à l'enveloppe et
ce qui appartient au contenu, régulièrement appelé payload). Il
n'est pas rare d'adjoindre un troisième membre : cargo, une
sorte de cargaison passthrough.
Système réflexif
Le système nerveux digital met en place son propre monitoring et … sa propre comptabilité analytique [2] . Par monitoring, il faut entendre sa capacité à se rendre compte de son propre état. Par comptabilité analytique, il faut entendre une capacité comptable générale capable d'attribuer son coût d'utilisation : qui a envoyé quoi à qui, comment, en consommant quelles ressources … Cette capacité purement comptable et statistique est indispensable pour dimensionner correctement le système, pour le faire évoluer avant rupture de capacité, pour, le cas échéant, refacturer en interne (ou en externe d'ailleurs) les services qu'il procure, voire même fournir une certaine gratuité des services sous des seuils convenus ou par gestion d'exceptions (accords entre parties, définitifs ou temporaires, selon des plages de temps discutées).
Plus loin, on parlera encore de la notion de capteur.
Catalogue d'impulsions
Le système nerveux digital possède un catalogue d'impulsions possibles qui sert de cartographie générale de cette moelle épinière d'organisation.
Il est intéressant de s'en remettre à la définition que fournissent Google, Microsoft, Yahoo et Yandex de ce qu'est un catalogue pour arriver à concevoir son catalogue d'impulsions : https://schema.org/DataCatalog. On complétera cette description utilement en scrutant ce qu'en dit Wikidata (https://m.wikidata.org/wiki/Q2352616).
L'architecte informatique se régalera également de son expérience à consommer les services offerts par les plus grands fournisseurs de services généraux que sont Amazon, Google, et Microsoft, un formidable réservoir d'apprentissage pratique [3] .
On notera cette expression de la maturité digitale qui consiste à juger du développement du système nerveux par la quantité et la variété des impulsions ― ou messages, rappelons-le ― qu'il supporte. C'est une mesure juste et objective.
Cependant, cette mesure doit s'accompagner d'une réflexion intense sur la complexité du système. Il s'agit moins ici de la nature de ce qui est compliqué que de la nature de ce qui est varié et qui forme de multiples combinaisons, imbrications et relations (voir à ce titre l'étymologie du mot «complexe» — qui embrasse des éléments divers et entremêlés). La complexité croissante d'un système est une mesure de sa sophistication mais également de son entropie (2ème principe de la thermodynamique).
Pour que le système nerveux digital reste flexible et adaptatif il doit faire l'objet d'une attention particulière et il ne peut être immunisé face à son propre refactoring. Sans ce refactoring le système se sclérose. L'imbrication intime d'impulsions (une impulsion qui a besoin d'une autre impulsion, un service utilisant un autre service) est un risque important de sclérose [4] . C'est la raison essentielle et primordiale de la promotion du principe de découplage qu'il n'est pourtant pas possible d'appliquer dans tous les cas (principe d'autonomie ou d'indépendance : un (micro-)service doit rester complètement indépendant)
Quand on parle de catalogue d'impulsions ou de services il est indispensable de le faire dans son aspect dynamique. Un catalogue vit. Il se consulte. On y fait des recherches. Il permet l'échange. On y rend possible des simulations et essais. Il possède sa propre documentation (par exemple sa manière d'y souscrire, ses conditions d'utilisation, …) et celle de toutes les impulsions (paramètres d'utilisation, mais aussi coût si applicable parmi bien d'autres choses). Ceux qui se sont déjà servis de la console Amazon, ou Google, ou Microsoft, ou Deezer, ou Spotify, … ont une idée assez pragmatique de ce qui est décrit ici.
Cycle de vie des impulsions
Par l'intégration de ce qui est appelé le système réflexif, et singulièrement son principe de comptabilité analytique (ce que j'appelle le principe du caissier), on détectera objectivement les impulsions utilisées et les impulsions qui ne le sont pas, plus ou peu. Les systèmes ayant une tendance naturelle à se complexifier (voir ci-dessus) il en découle une forme d'inflation économique : le système devient économiquement lourd ! Cette forme d'inflation est naturelle. Il est inutile de vouloir y échapper. Vous ne pourrez pas y échapper.
Dans les faits, on note une tendance spontanée à la multiplication des impulsions différentes, un emphysème qu'il faut garder sous contrôle. Sans cette maîtrise du système nerveux digital il s'écroule tôt ou tard sous le poids de sa propre économie (art de gérer le domus, la maison — économie) : le système commence à coûter plus qu'il ne rapporte; sa flexibilité est mise en cause.
Éliminer les impulsions, les nettoyer est une tâche parfaitement cruciale. On utilisera avec bonheur le principe des 5S de Lean, adapté à la situation à laquelle on fait face, en l'occurrence la maintenance du système d'information digital. Voici une vidéo d'introduction très générale du principe des 5S. Comme évoqué ci-avant, le fait de disposer de son propre système de monitoring et de sa propre comptabilité analytique garantit de pouvoir générer automatiquement … des impulsions sensitives (ou sensorielles) concernant celles qui sont de toute évidence sous-utilisées de telle sorte qu'elles puissent être détectées et proposées comme candidates à grooming. Tout ce qui peut être automatisé sans sacrifice de fonctionnalité ou de qualité doit l'être.
UAD — User Account Database
Un système d'information digital, une moelle épinière digitale, s'accompagne d'une gestion d'identités stricte et rigoureuse mais également centrale et unique. Une gestion impitoyable est impérative. L'absence de gestion ordonnée des droits d'accès, en ce y compris tous les processus d'entreprise qui l'accompagnent, est la première cause de déstabilisation de la moelle épinière qu'on vient de mettre en place, une source de l'augmentation des coûts qui se soustraient de la sorte à toute maîtrise.
Capteurs
Pour que l'entreprise puisse connaître son état général il est indispensable qu'elle place des capteurs d'état de ses organes (départements) et aussi sur sa capacité à entrer en communication avec l'extérieur. Les senseurs doivent être placés en priorité aux organes les plus sensibles pour l'organisation : un hôpital n'est pas une maison de repos et une maison de repos n'est pas une banque qui, elle-même, n'est pas une compagnie de streaming.
Les impulsions sensitives doivent non seulement vous permettre de vous faire une idée précise de votre propre état mais également de l'état des autres organismes qui font partie de votre écosystème, vos fournisseurs en particulier mais encore vos concurrents ou tous autres organismes auxquels vous êtes sensibles. C'est particulièrement le cas où vous auriez entamé une transformation digitale où vous intégrez les chaînes de valeur upstream et/ou downstream (voir chaîne de valeur).
Mission Critical
Une colonne vertébrale digitale est un élément de la chaîne Mission Critical. C'est en cela qu'il est nécessaire d'en faire un système réflexif, robuste et redondant quelles que soient les solutions techniques que vous mettrez en oeuvre (failover, load balancing, sondes nagios, …).
Scalability (évolutivité)
Scalability (évolutivité) est la propriété d'un système permettant de gérer une quantité croissante de travail en ajoutant des ressources (machines, puissance CPU, mémoire, …) ou en multipliant le parallélisme non-bloquant (multiplication des instances capables d'effectuer un travail parallèle)
Reliability (Fiabilité)
La fiabilité est un attribut de tout composant informatique (logiciel, matériel, réseau, … ) qui fonctionne constamment selon ses spécifications.
Robustesse / Redondance
La robustesse est la capacité d'un système à faire face aux erreurs et de pouvoir continuer à fonctionner, soit en isolant les erreurs dans les traiter, soit en les corrigeant.
On pourrait penser que la correction d'erreurs est la stratégie le plus intelligente et donc celle qui est recommandable. Il n'en est rien. En pharmacie, par exemple, il est interdit de corriger des erreurs car une correction est assimilée à une interprétation or toute interprétation est porteuse d'un degré d'incertitude ce qui est incompatible avec la nécessité d'avoir une connaissance parfaite (100% de certitude).
La stratégie à appliquer est affaire de contexte ; elle peut être différente de worker en worker meme au sein d'un même sous-système.
Le système nerveux digital doit comporter sa propre redondance car, endommagé, il risque redondance de paralyser l'ensemble de l'organisation, et ce, de manière plus sérieuse qu'il est développé et répandu. À titre d'exemple de ce que nous pourrions appeler une forme de redondance je mets en avant la multiplication dûment contrôlée des vecteurs de Cloud : vous avez décidé de passer par un fournisseur A, mais vous pouvez passer par un fournisseur B au cas où le fournisseur A vous fait défaut (ce qui est d'ailleurs une bonne façon de vous protéger d'un risque "fournisseur").
Failover
Il n'est pas raisonnable de tester un système de failover seulement au moment d'une panne réelle. Pas plus qu'il n'est raisonnable de tester votre système de Load Balancing de la même manière. Ces mécanismes doivent être testés régulièrement, sur tous les environnements où ils sont en application ET en production. Je répète : EN PRODUCTION !
Par ailleurs, il est à noter qu'en vertu du principe de fiabilité, il va de soi que le système de switching (passer d'une instance à l'autre, pour du failover ou pour des questions de charge) doit lui-même faire l'objet de tests. Je me suis déjà trouvé en situation où nous faisions face à un problème parce que … le système de switching du composant qui était censé nous protéger d'une quelconque coupure provoquait lui-même la défaillance ! Qu'il s'agisse donc de failover ou de load balancing, ce(s) composant(s) doi(ven)t être plus fiable(s) que les éléments qu'il gère. Si ce n'était pas le cas, on ne ferait qu'augmenter la complexité du système en augmentant le nombre de points possibles de défaillance.
Mode dégradé
Le système nerveux digital doit pouvoir fonctionner en mode dégradé comme le suggère l'avionique moderne. Si l'avion est touché, il peut faire face à des pannes localisées mais il doit pouvoir continuer à voler. Une panne d'électricité ou d'Internet, pour avoir un impact sévère, ne peut néanmoins pas provoquer la faillite de l'entreprise. Le tout digital ne peut se concevoir qu'avec une roue de secours bien matérielle.
Outre ces éléments qui sont décrits ci-dessous succinctement, il est d'usage de pouvoir disposer de traces/logs utiles et d'une gestion des erreurs/exceptions limpides.
Traces / Logs / Erreurs / Exceptions
Je ne dirai que peu de choses des traces à enregistrer dans les fichiers de log. Le système de traces, quel que soit l'outil que vous utilisiez doit répondre aux exigences suivantes :
- avoir un degré de verbosité variable (plus ou moins de traces), si possible dynamique (application à chaud),
- être central, pour l'ensemble du système et pour chaque sous-système qu'il contient,
- doit permettre de déterminer le parcours complet du message de l'entrée du système à sa sortie (considérant que la Dead Letter ou une station MRS sont des zones de parkage assimilées à des sorties pour ce sujet); cette remarque vaut particulièrement en cas de load balancing,
- doit être interrogeable (queryable), visualisable et traitable de manière automatique (idéalement par API)
- doit être connecté au système cardio, quel qu'il soit (interrogeable par le cardio)
- le système de traces doit faire l'objet d'un audit trail (pas d'ajout, pas de modification, pas d'effacement sans que ces changements soient détectables)
- le système de traces doit respecter GDPR
- le système de traces doit être auto-archivable
- les traces enregistrées doivent être les plus claires et compréhensibles possible : pas de message technique incompréhensible ou alors toujours flanqué d'une explication destinée à être lue par un humain,
- chaque problème doit, dans la mesure du possible, être accompagné d'une suggestion de solution ou de contournement,
- toutes les exceptions doivent être capturées et descendues dans les
traces : un exception de type
null pointern'est pas envisageable.
Infos
Vous pouvez bien évidemment décider des informations à stocker au mieux de vos intérêts et selon les habitudes des projets (quoi, où, comment, quand). Voici néanmoins une liste d'éléments habituels :
- Datetime : date et heure de la trace (en mode UTC, surtout si vous avez affaire avec des parties se trouvant sur des réseaux différents)
- Niveau de trace : un nombre qui plus il est grand, plus il donne de détails. Je mets ce nombre en rapport avec le niveau de tracing général. À titre d'exemple : 0 = pas de trace (mais alors vous n'avez rien dans le fichier de log), 16 = niveau erreur, 32 = niveau warning, 64 = niveau info et ensuite … de plus en plus verbeux
- User ID : quelque chose qui vous permette d'identifier la personne concernée si applicable …
- Originator ID : une propriété qui identifie de manière unique le Message Worker qui a loggué la trace
- RequestedBy ID : une propriété qui identifie de manière unique la partie qui a initié la toute première demande
- Path : La route parcourue avant la trace
- Host : L'identification de l'environnement impliqué
- Error Code : le n° d'erreur concerné. Par exemple le n° d'erreur MQSeries, ou Oracle, ou … Mais attention, tous ces numéros d'erreur peuvent se chevaucher et dès lors vous devrez trouver un mécanisme qui permette de clairement distinguer l'origine de l'erreur. Pour X-Stream nous nous sommes servis des codes d'erreur utilisés par chaque vendor ; nous avons réservé des plages de n° de codes pour MQSeries, pour Oracle, pour DB2, … et on appliquait une base de démarrage (ex. tous les codes d'erreur MQSeries étaient dans la tranche 1000000 à 2000000 où 1000000 était la base de démarrage à laquelle on additionnait simplement le code d'erreur de MQSeries). Cela nous permettait de retomber sur nos pattes aisément (correspondance facile entre notre code d'erreur et le code d'erreur natif de MQSeries)
- What : type d'opération impliqué dans la trace
- Desc : une brève description de l'entrée de log
- AdditionalDetails : des éléments secondaires de l'entrée de log (valeur de certains paramètres, etc.)
Pour X-Stream nous avions l'habitude de penser de la manière suivante :
Si les informations disponibles en fichier de log ne nous permettaient pas de déterminer précisément la cause de l'erreur en moins de 5 minutes, c'est que le fichier de log était mal foutu! En plus de 30 ans de carrière, c'est en ces termes que je réfléchis à tout système de traces ! Cette mesure de 5 minutes était vraiment un seuil concret de la mesure de l'efficacité des traces générées. Si on dépassait ce seuil, cela voulait dire que la trace devait être améliorée. Toute trace qui devait être améliorée recevait la plus haute priorité dans le travail à accomplir par l'équipe. Cela a contribué de manière positive à la productivité de l'équipe. En outre, le bien-être des membres de l'équipe s'en trouvait grandemant amélioré : personne n'avait le moindre problème à accepter de prendre le beeper du support !
Chapitre Disaster Recovery
Que faire si l'ensemble du système email est down ? Quel impact sur le support ? Quel impact sur les divers services qui utilisent l'email pour envoyer des notifications ou pour recevoir des messages ? Que faire si le DNS déconne ? Quel impact si l'Active Directory est down ? Que se passe-t-il en cas de coupure d'électricité ? Que faire si des certificats sont dépassés ou révoqués ? Que faire si la connexion vers votre ISP vous lâche ? Que se passe-t-il si une licence n'a pas été renouvelée parce que quelqu'un a oublié de payer une facture ?
Vous êtres en présence d'un système critique ! Votre ESB s'arrête, c'est la colonne vertébrale qui cesse de fonctionner. C'est toute votre organisation qui s'arrête ! Pensez-y !
Les défaillances ne se planifient pas, elles s'anticipent ; elles ne suivent aucune règle sauf celle de faire le plus de dégâts possibles. Elles ont comme une volonté du malin à s'invoquer en série, que l'une cause l'autre. N'attendez aucune indulgence de leur part !
En d'autres mots, cela se passe toujours plus mal que ce à quoi vous vous attendiez et il est simplement impossible de prévoir tous les cas : le manuel serait plus imposant que le livre de Proust, À la recherche du temps perdu[5] , titre fabuleusement prémonitoire.
Il reste alors à vous entraîner à faire face à l'inconnu et d'apprendre à l'apprivoiser car vous ne pouvez pas écrire tout ce qui pourrait mal tourner et, pour chaque cas de figure, disposer de la réponse du manuel.
Ce que vous pouvez faire en revanche c'est d'exceller dans la détection et la réaction. La détection doit intervenir très tôt ; la réaction doit être la plus prompte possible. Au fond, c'est une question de rapidité. Cela, oui, ça fonctionne quel que soit le problème.
Dans X-Stream par exemple, Gregory Sovaridis et moi-même, avons été confrontés à un de ces types de problèmes. Un composant essentiel de notre système lâchait de manière aléatoire. Tous les autres composants continuaient à faire leur boulot sauf celui-là qui se mettait dans un état zombie : ce worker était toujours vivant mais il ne faisait plus rien. Vu de l'extérieur, l'ensemble du système semblait continuer de fonctionner mais Greg et moi savions que quelque chose se passait mal grâce à une détection précose et précise. Nous avons alors eu un petit conciliabule qui nous a d'ailleurs amenés à téléphoner en Belgique pour faire part du problème et à demander une autorisation. En clair, nous souhaitions obtenir l'autorisation de mettre en place une solution un peu ... spéciale : il s'agissait de "tuer" l'application fautive régulièrement (même si elle ne présentait pas de problème) et d'en redémarrer une instance aussitôt. Notre Account Manager a voulu s'assurer que nous serions capables d'effectuer cette opération directement sur l'environnement de production de la banque italienne où notre système était déployé. C'était bien normal. Mais au fond, nous n'avions pas d'autre choix, en tout cas, on n'en voyait pas d'autre.
Nous avons donc créé sur place un nouveau composant que nous avons appelé le "Revivor" dont la tâche était de tuer un processus et d'en lancer une nouvelle instance.
Revenus à Bruxelles, et forts de cette réussite de terrain, nous avons généralisé le concept pour en faire un composant standard de la suite X-Stream.
La détection des problèmes se faisait bien AVANT toute manifestation de panne grâce à notre composant Cardio lequel envoyait un message de service au Revivor dont la mission était de "tuer" un processus précis (celui où la panne était détecté cette fois-ci, et non plus de tuer un processus qui fonctionnait) et d'en redémarrer une nouvelle instance aussitôt. In fine, grâce au Revivor le système, dans sa globalité, continuait à remplir sa fonction sans défaillance.
De ceci il faut dégager une conclusion générale :
Trouver une solution ce n'est pas toujours résoudre un
problème, c'est parfois accepter le problème mais l'empêcher d'avoir un
impact.
Une autre conclusion s'impose, humaine celle-là : le Revivor avait
contribué à augmenter de manière significative notre tranquillité
d'esprit, notre apaisement, notre sérénité même. Cela n'était pas
le moindre des bénéfices.
Types d'impulsions
Impulsions exécutoires
Il s'agit d'impulsions d'exécution comme celles qui parcourent les nerfs moteur de l'anatomie humaine, le cerveau qui envoie une impulsion à la main gauche pour qu'elle saisisse un objet par exemple. Dans le cas d'un système nerveux digital il pourrait s'agir de l'envoi d'un mail, ou de la fabrication et stockage d'un document. On exécute une fonction.
Messages de service
Il s'agit d'impulsions exécutoires destinées à des applications. Cette dénomination a été proposée par Jean Bourdin dans le cadre de projets bancaires (Intesa — 2001 et 2002, UBS — 2002 et 2003, Banca di Roma — 2004, …). Quelques exemples de messages de service :
- Rechargement du fichier de configuration
- Start / Stop processing
- Spawn et kill de processus
- Heartbeat
- Rechargement de la gestion des erreurs et exceptions
- Routage des erreurs et exceptions
- Niveau de sévérité des erreurs et exceptions (errorlevel)
- Réassignation de ou des files d'entrée (queues)
- Type de lecture (destructive ou non — consommation des messages)
- Utilisation de routages alternatifs (gestion de l'encombrement, …)
- …
Impulsions sensitives (ou sensorielles)
Ce sont les impulsions qui véhiculent les informations qui proviennent des senseurs, internes pour la plupart, mais également externes.
Il est très habituel de lancer une impulsion de type heartbeat entre deux points nodaux de la colonne digitale afin de pouvoir déterminer si, sur le segment visé, la transmission des impulsions est toujours possible (coupure, engorgement, … ).
Impulsions ministérielles
J'ai choisi le terme "ministérielle" par égard à son étymologie : ministre … celui qui accomplit une tâche au service de quelqu'un.
Une impulsion ministérielle est une impulsion double se composant d'une requête et d'une réponse, l'exercice d'un service au sens générique mais aussi au sens entendu en informatique (service et microservice).
Les connexions externes (Outside World)
La colonne vertébrale digitale a pour ambition — et je le répète car ceci est vraiment d'une importance capitale — de connecter tous les organes internes de l'entreprise (achats, ventes, ressources humaines, comptabilité, IT, audit, département juridique, marketing, …) mais également de connecter l'entreprise à son écosystème et plus particulièrement, mais pas uniquement, aux chaînes de valeur en amont (les fournisseurs, …) et en aval (clients, distributeurs, prescripteurs, consommateurs, …). C'est en cela qu'on se connecte au monde extérieur.
Un défaut assez habituel de la mise en place d'une colonne vertébrale digitale, ou d'un ESB connecté sur l'extérieur, consiste à se baser sur l'hypothèse selon laquelle les autres systèmes avec lesquels l'organisation collabore sont fiables, disponibles et réactifs à tout moment. Le système doit accepter le fait que les systèmes tiers peuvent ne pas être disponibles ou réactifs à certains moments et doit établir des tolérances pour de tels événements (voir les parties robustesse et mode dégradé).
Architecture à base de files d'attente (Queue-based System Architecture)
L'architecture basée sur des files d'attente (QBSA) est un excellent moyen de construire des systèmes qui nécessitent la collaboration de plusieurs systèmes distribués connectés vers l'extérieur.
La plupart des traitements dans un système basé sur des files d'attente sont pris en charge de manière asynchrone par des processus autonomes souvent conçus comme des … services (input et output par file d'attente).
Chaque file d'attente constitue un noeud du système, un noeud qu'il est facile de monitorer et qui fournit un moyen aisé de montée en puissance (plusieurs instances d'un même processus connecté à une même file d'attente par exemple), moyen que nous avons utilisé chez Viveo pour atteindre des performances extrêmes dans le cas d'un système de Compliance Filter mis en place chez UBS (Zurich) et qui permettait ainsi de traiter des millions de messages SWIFT avant le cut-off time journalier.
Notons enfin qu'un ESB basé totalement ou partiellement sur des files d'attente permet de créer des zones de temporisation à l'envi, ce qui permet de réguler aisément le trafic de la colonne vertébrale digitale, voire de le contrôler manuellement ou automatiquement, ce que nous avions d'ailleurs réalisé chez Viveo avec X-Stream [6] , un EAI financier, labellisé Gold par SWIFT : le composant Cardio permettait ainsi le contrôle et la régulation de l'ensemble du système EAI.
On voit donc qu'un système QBSA s'intègre naturellement dans la mise en œuvre d'un bus de services d'entreprise (ESB) : l'ESB peut fonctionner entièrement ou partiellement sur ce paradigme.
Vue générale
Un système QBSA est fondamentalement un système de routage et comme tout système de routage il comporte un chemin à prendre, des décisions plus ou moins intelligentes concernant les chemins à prendre (aller vers A, aller vers B, aller vers C, … par combinaison de «et» et «ou»), et … les chemins effectivement pris (les détournements sont possibles dans des systèmes intelligents).
Message Broker
Le Message Broker (agent de messages) lit les messages envoyés à un système afin de les valider, le cas échéant de les transformer, et de les rediriger.
Il permet de découpler efficacement émission, transformation, réception et traitement.
Le système peut avoir plusieurs entrées possibles au rang desquelles, bien sûr, une file d'attente d'entrée (System Input Queue). Mais le système peut aussi proposer autant de types d'entrées qu'il lui est possible de supporter : FTP, UDP, emails, notifications, … Tout cela sera géré par ce composant particulier qui s'appelle le Message Broker et qui alimente ses Workers, ces points de traitement qui font la richesse du système mais aussi sa raison d'être.
(Message) Worker
On parle souvent d'un Worker, ce qui comme le nom l'indique est un noeud qui traite un message, c'est-à -dire qui lui applique le traitement attendu. Le Message Processor est constitué d'une file d'attente d'entrée et d'un Worker qui s'occupe du traitement proprement dit. Je fais la simplification de parler indistinctement de Message Processor et de Worker tout en favorisant la seconde formulation.
Le worker est donc un processus qui réalise le traitement qui est attendu de lui. Un Worker lit sa file d'attente d'entrée, effectue son travail, et retourne le résultat là où il est attendu, ce qui, la plupart du temps, est une destination qui ne lui est pas connue (c'est le routage qui lui dicte où le message doit être envoyé). Si une erreur survient, il délègue le message à sa propre Dead Letter ou à celle de l'ensemble du système (qui peut d'ailleurs avoir plusieurs files qui jouent ce rôle).
Quant à pouvoir juger de l'ampleur du travail qui est à faire par le worker, il s'agit là d'un équilibre entre performance et gestion du système : plus le travail à réaliser est ambitieux et lourd, plus on risque un encombrement. Plus on réduit le travail à faire par 1 worker spécifique, plus on multiplie les workers, plus la gestion devient complexe et plus le lead-time de traitement end-to-end en pâtit. En ces circonstances particulières, la multiplication des instances du worker renforce les possibilités de scale out.
Chaque Worker doit posséder une identité unique et spécifique : nom et
version, etc. On utilisera avec bonheur le schéma
SoftwareApplication totalement documenté que nous fournissent
Google, Yahoo, Yandex et Microsoft : SoftwareApplication. Ce
schéma, par héritage, dérive et complète les deux autres schémas suivants :
CreativeWork et Thing. Vous trouverez ces trois classes
documentées en PHP : SoftwareApplication, CreativeWork et
Thing. J'espère que cela vous sera utile. Au travers de ces 3 schémas
qui sont aujourd'hui des standards de l'industrie vous disposez de toutes
les propriétés qui permettent d'identifier sans doute possible tous les
Message Workers de votre colonne digitale, qu'ils soient conçus par vos
soins ou pas.
Versionnage de message
Tout comme il est recommandé de versionner des services, il est fortement recommander de versionner les messages. Comme un service, un message a une forme de signature qui est son contrat. La version du message fait partie de ce contrat.
Grâce au schéma SoftwareApplication et de ceux dont il dépend vous avez tout ce qui est nécessaire pour attribuer une version à un message [7] . Si toutefois un message n'était pas versionné, il est d'usage de lui appliquer le traitement réservé à la dernière version dudit message.
Routage
Il est particulièrement mal avisé d'implémenter la logique de routage au sein de chaque Message Worker. Celui-ci doit être agnostique, sauf exception, par rapport aux routes à emprunter. Il suffit de penser à une colonne vertébrale digitale corpulente pour se rendre compte qu'effectivement il ne semble pas idoine de laisser le routage aux soins des workers. Par l'absurde, on n'imagine pas de devoir modifier le routage auprès de chaque worker.
L'ensemble du système doit disposer de décisions centrales considérées comme étant la Business Logic de routage. Ces décisions doivent être formulées de manière suffisamment simples pour pouvoir être modifiées aisément sans nécessiter le moindre changement au sein des Message Workers, idéalement directement par le Business car il va de soi que si la Transformation Digitale invoque de nouveaux processus au sein de sa cellule d'innovation, il faudra potentiellement adapter le routage. Il faut s'y prépaper.
Aller vers A ou vers B, aller vers A et vers B
En matière de routage, aller vers A, aller vers B, aller vers C, … par combinaison de «et» et «ou» cela signifie que des messages peuvent être dirigés vers un Message Worker ou un autre mais aussi vers l'un ET l'autre. On assiste alors une forme de duplication de messages dans le système. On parle souvent de Y-copy.
Cette technique de Y-copy est excessivement puissante car elle dote les impulsions d'un don d'ubiquité qui permet un haut parallélisme de traitement.
Si les chemins parallèles sont appelés à devoir être réconciliés, il faudra prévoir un mécanisme qui le permette (les résultats obtenus sur un chemin de traitement doivent être consolidés avec les résultats obtenus sur un autre chemin). Si les chemins sont indépendants, … il n'y a rien à faire.
Systèmes logiques
Une colonne digitale doit apprendre à composer avec des éléments épars ou assemblés logiquement : des sous-systèmes.
Deux philosophies s'opposent :
- Concevoir un système avec un Message Broker central qui dispatche lui-même les messages vers les différents sous- systèmes ou …
- Concevoir un système avec autant de Message Brokers qu'il y a de sous-systèmes.
J'ai trouvé autant d'avantages à l'une ou l'autre des conceptions. J'avoue cependant avoir un faible pour la solution hybride qui utilise un Message Broker central ET autant de Message Brokers qu'il y a de sous-systèmes. Au rang des facilités qui ont emporté ma décision on trouve la facilité générale qui permet de contrôler l'ensemble du système au travers d'une seule Input Queue centrale MAIS de pouvoir contrôler chaque sous-système indépendemment également ce qui s'avère être un avantage non négligeable pour des opérations de maintenance.
Je conseille également d'avoir un outil de composition de messages (Composer dans le schéma) et un outil de lecture des messages (Reader) par sous-système. Cela permet a des équipes entièrement indépendantes de travailler simultanément sans se gêner.
Il n'est pas idiot de disposer d'un système de monitoring et de contrôle par sous-système (Cardio dans le schéma) même si ce n'est pas ce qu'illustre le diagramme ci-dessus. En tout état de cause, il vous est nécessaire de disposer d'au moins une instance de cardio pour l'ensemble du système (au moins une !)
Chaque sous-système peut avoir sa propre Dead Letter. Vous pouvez aussi décider de mettre en place une Dead Letter qui inhérente au système dans son ensemble.
Services et Messages
La colonne vertébrale digitale n'est rien de plus qu'un système d'impulsions lesquelles sont interprétées de manière différente par les organes qui les réceptionnent. Que ces impulsions soient des appels et des réponses de services ne change rien à l'affaire. Tout se passe comme si deux espèces différentes cohabitaient en coopérant ou en évoluant de manière indépendante : les services et les messages. Rien n'empêche les Message Workers de faire appel à des services et rien n'empêche les services d'envoyer des messages.
Cette absence de démarcation entre messages et services est ce qui fait la force d'un système mais c'est aussi ce qui en fait sa complexité et donc son degré d'entropie. Plus les deux s'imbriquent, plus la variation des états augmente, plus les interdépendances augmentent, plus les degrés de liberté croissent, plus la propagation des difficultés doit être tenue sous contrôle et surveillée. Ce n'est pas une mince affaire. Cela demande de la maturité.
Nommage et environnements
J'ai trouvé utile de disposer d'une forme de dictionnaire qui permette de
nommer les objets selon une logique qui m'était propre, facilement
compréhensible. Par exemple, si vous avez un sous-système comptable dans votre
ESB (ensemble applicatif comptable), vous pouvez décider d'appeler la file
d'attente de ce sous-système ACCOUNTING_INPUT_QUEUE alors que
l'ensemble du système (tous sous-systèmes inclus) pourrait avoir une file
d'attente d'entrée nommée SYSTEM_INPUT_QUEUE.
Par contre, il se pourrait que les équipes systèmes ou infra vous imposent
une sorte de nomenclature spécifique et il se peut aussi que cette nomenclature
n'évoque aucune logique pour vous. Que dire des files d'attente
TEST_NATION_S_202010_MAIN_V4_INPUT et
TEST_NATION_S_202010_ACC_V4_INPUT ? Il y a fort à parier que ces
noms seront, pour vous, beaucoup moins parlants.
Ayant travaillé pour de multiples clients aux multiples nomenclatures
différentes, avec parfois des nomenclatures spécifiques aux environnements sur
lesquels la solution était déployée, j'ai trouvé facile de disposer d'un
dictionnaire, modifiable par le client, qui transformait les noms d'objets
logiques en noms physiques (e.g. ACCOUNTING_INPUT_QUEUE en
TEST_NATION_S_202010_ACC_V4_INPUT). Au-delà , cela facilite
grandement la documentation du système !
Un simple fichier XML fait merveille. Facile à éditer, aisément transportable d'environnement à environnement, déployable à souhait …
Mesure de la performance
Lorsque Gregory Sovaridis et moi-même avons conçu X-Stream NT, nous étions face à un double problème : (1) bâtir un système qui fonctionnellement filtrait les bons messages de paiement des mauvais le plus efficacement possible et (2) être capable de traiter 1,6 millions de messages quotidiennement. Une double contrainte où lorsque le premier défi était le mieux rempli, il prenait aussi le plus de temps.
La performance était au cÅ“ur de notre développement, présente Ã
tout moment. Nous avons été obligés de revoir de fond en comble un
ensemble d'algorithmes, l'utilisation des librairies (libxml par exemple),
etc. Dans nos premiers essais, nous nous sommes rendus compte que nous ne
pouvions pas nous permettre d'encoder le payload des messages en base 64 car
le seul décodage ne permettait pas d'atteindre la performance requise pour
traiter autant de messages. Nous avons dès lors inventé notre propre
algorithme d'encodage (inspiré d'une discussion avec le collègue Koen
Hufkens), ré-écrit un un parser XML maison basé sur une implémentation
personnelle d'une forme réduite de RegEx (fonction STR_Like(),
écrite partiellement en C et partiellement en assembleur et que j'avais
publiée dans le magazine Point DBF une dizaine d'années plus tôt). Nous
avons réécrit le fonction strstr() du langage C car on ne le
trouvait pas assez rapide et lui avons substitué un autre fonction basée sur
l'algorithme Boyer-Moore à alphabet réduit, etc. Bref, la performance était
présente dans tous nos développements; il n'était pas une ligne de code que
nous écrivions qui y échappait.
Une telle attention ne peut que s'accompagner de tests systématiques. Nous lancions donc de nombreuses vérifications qui, au fur et à mesure de notre développement nous confortaient qu'on tiendrait le seuil de performance en-deça duquel notre solution eut été rejetée par le client, la très puissante UBS.
En fait, dès qu'une partie nouvelle était développée, celle-ci faisait l'objet d'un test de performance.
Un jour nous avons noté, incrédules, une forte baisse de la performance. Nous n'avons pas mis longtemps à découvrir le coupable : le passage par valeur d'une large structure au lieu d'être passée par référence … soit un oubli d'un seul byte (&).
Ce que révèle cette petite digression c'est la chose suivante : des tests de performance, cela se fait tout au long du développement, from day one. Si ces tests n'avaient pas été fréquents dans le développement de X- Stream NT, jamais nous n'aurions été capables de déterminer si rapidement la cause de la dégradation de perf. C'est parce que nous n'avions que peu de code modifié à scruter que nous avons été prompts à trouver le problème et à trouver la solution, le fameux &. Je vous invite ainsi à planifier régulièrement des tests LSP — Load, Stress and Performance — dans la mise au point de votre colonne vertébrale digitale car, oui, elle doit être la plus rapide possible.
Un processus progressif
La mise au point de la colonne vertébrale ne se fait pas en chambre. Elle se fait sur le terrain … dans le corps même de l'organisation, par petites étapes successives. C'est une forme progressive de sécrétion de tissus, une embryogenèse. À ce titre cette formation connaît plusieurs étapes, chacune avec ses points d'attention propre.
Tout commence par la fibre nerveuse par laquelle les impulsions peuvent être transmises. Sans elle, l'idée d'impulsion n'existerait pas. On parle ici de l'ESB, la moelle épinière du système qui sécrète les services comme le cerveau sécrète la pensée.
Ensuite, les services font leur apparition gentiment forcés par les besoins de programmeurs. Je ne renie absolument pas le fait indiscutable que les services servent les objectifs de l'organisation, et donc partant, des objectifs Business. Il n'en reste pas moins vrai qu'ils naissent toujours sous l'impulsion des développeurs et architectes. Tout commence par un premier service et l'enjeu qui se joue est plus un enjeu de plomberie qu'autre chose : est-ce que l'impulsion arrive à se frayer un chemin, à aller d'un point à l'autre et à demeurer compréhensible.
À ce stade, le monitoring n'a guère d'importance, la sécurité non plus, la performance, la charge, le stress pas davantage. Ce ne sont tout simplement pas les points d'attention du moment et cela restera le cas pour quelques dizaines d'autres services dont la multiplication est infatigable.
Un effet de taille
Les services se multiplient et avec eux l'utilisation qu'on en fait qui prend des tournures parfois inattendues. On passe par des étapes où l'application de standards devient nécessaire, où le monitoring devient incontournable, où la sécurité devient inévitable.
Suivre des dizaines, puis des centaines, et au final des milliers de services parfois répartis sur plusieurs fuseaux horaires devient l'enjeu premier.
À mesure que votre la colonne vertébrale se développe, à mesure que son utilisation se propage, vous devrez être en mesure de surveiller de nombreux processus, plus que probablement réalisés par des équipes disséminées dans toute l'organisation. C'est un de ces moments où le bon état des routes et l'état général du trafic vous intéresseront plus que la petite impulsion qui est bloquée au fin fond d'une file d'attente. Vous en serez à surveiller l'état de votre réseau ! Vous aurez besoin d'un composant Cardio. (Lien vers page Cardio).
Un effet boule de neige
Plus la colonne vertébrale se développe, plus elle sécrète de services, plus il y a de services et plus il est probable qu'ils se mettent à interagir les uns avec les autres, plus ils interagissent, plus ils s'imbriquent, plus ils s'imbriquent, plus ils se figent. C'est le danger de sclérose dont je parlais plus haut.
Les services se figent car leur modification entraîne des résultats inattendus même si tout est fait pour éviter les effets secondaires indésirables. Éviter les bugs devient illusoire. Modifier des services requiert un effort de synchronisation qui n'était pas nécessaire quand les services étaient peu nombreux. La question devient alors de savoir comment être résilient et faire en sorte que l'inattendu ne bloque jamais le système. C'est le moment aussi où la multiplication des services ralentit, un moment qu'il faut détecter sans s'inquiéter : sans ce phénomène, on aurait à faire face à un cancer, c'est-à -dire une multiplication anarchique dont l'horizon est l'effondrement de tout le système. C'est un moment délicat où les principes généraux doivent l'emporter sur les règles particulières, un moment de diversité qu'il serait nuisible d'empêcher ou de contraindre. C'est un point critique de tout développement ESB (Enterprise Service Bus).
Les end-points extérieurs
Ne cherchez pas ! Oui, vous allez utiliser des end-points extérieurs parce que vous allez utiliser des services extérieurs ! Vous pouvez vous en défendre mais tout cela est affaire de progression. Vous ferez peut-être appel des services exterieurs très rapidement ou peut-être lentement, mais vous n'y couperez pas car telle est la nature de notre monde connecté (et le Cloud n'y est pas étranger, bien évidemement).
Ce site est en construction ! Son contenu évolue chaque jour. ICI, JE DEVRAIS INDIQUER QUE L'APPEL D'UN SERVICE EXTERIEUR DOIT AUSSI S'ACCOMPAGNER D'UNE FORME DE PROTECTION POUR SE PERMETTRE DES ROUTES ALTERNATIVES. EXEMPLE : FAIRE APPEL À UN SERVICE DE TRADUCTION POUR LEQUEL IL FAUT POUVOIR EFFECTEUR UN DISPATCHING VERS DIVERS FOUNRISSEURS DE SERVICE. IL DOIT ÉGALEMENT S'ACCOMPAGNER DU PRINCIPE DU CASHIER POUR PERMETTRE LA REFACTURATION INTERNE; IL FAUT EGALEMENT PRESENTER UNE FAÇADE COMMUNE QUEL QUE SOIT LE SERVICE EXTERNE APPELÉ.
To be continued
Invitation au chaos — Une note finale d'hérésie
NetFlix a inauguré un logiciel dont peu de responsables informatiques sont fans : le Chaos Monkey, un logiciel qui met la pagaille dans l'infrastructure, qui génère un sacré micmac. Une série de liens existent qui expliquent la justesse et l'efficacité du concept car, in fine, le Chaos Monkey se donne pour objectif d'améliorer considérablement la résilience d'un système et c'est ici ce qui m'importe puisqu'une colonne vertébrale digitale est mission critical.
Si le Chaos Monkey teste la résilience d'un système il teste également la résistance au stress des femmes et des hommes qui tout à coup font face à des problèmes imprévus, un test grandeur nature des hommes et des processus.
Un peu comme le développement TDD commence par écrire un test visant à vérifier un code qui n'existe pas encore, je vous invite à écrire un MicMacMaker qui perturbe votre colonne digitale qui n'a pas encore de file d'attente ou de endpoint. Faites le avec discernement et mesure, tourné vers un objectif résolument positif d'amélioration de votre colonne.
Notes de bas de page
[1] … Il n'est pas inexact de penser également que le pilier Shorter Cycles puisse aussi s'envisager comme une contrainte
[2] … On ne parle pas ici de monitoring hardware; on parle de monitoring applicatif
[3] … Généralement, la consommation de ce type de services se fait sur des modèles très similaires. On trouvera aussi de quoi s'exercer avec quantité d'autres services comme ceux de Deezer, Spotify, iTunes, Tomtom, Michelin, Text Razor, geonames, la banque carrefour, les services postaux, …
[4] … Quand les services se multiplient leur imbrication devient inévitable. Ce n'est pas la peine de l'empêcher; il s'agit plutôt de l'accompagner
[5] … 9609000 caractères, près de 1,5 million de mots. Cet ouvrage détient le record du plus long roman au Guinness
[6] … X-Stream était un produit de type Enterprise Application Integration faisant partie d'une suite d'outils de type système expert / Intelligence Artificielle visant à normaliser et réparer des messages de paiement SWIFT. Le cÅ“ur d'X-Stream a été réalisé en ANSI C monté sur MQSeries, l'ancien nom de WebSphere MQ, IBM MQ, par Gregory Sovaridis et Patrick Boens. Le système, labellisé Gold par SWIFT dès 2002, a été utilisé dans de nombreux projets bancaires où la performance, la robustesse, la fiabilité et l'évolutivité étaient particulièrement exigentes. La suite X-Stream offrait un Message Broker (le SuperSwitch), un composant de contrôle d'état, de lancement de commandes et de régulation (le Cardio), un compositeur de messages (le Composer) et une station de lecture (le Reader). Les composants Composer, Reader et Cardio, couplés à une station de réparation manuelle de messages — Manual Repair Station ou MRS, permettaient d'effectuer des tests entièrement automatisés en envoyant ± 400000 messages dans le système chaque vendredi (cérémonie du dry-run) : l'arrivée desdits messages dans des files d'attente bien spécifiques garantissant le traitement correct des messages envoyés.
[7] … Vous pouvez aussi vous reposer sur la Gestion sémantique de version 2.0.0
[8] … La nature et le nombre de services augmente considearblement conforme au constat qui précède et qui annonce le foisonnement des services. Jetez un oeil sur les services cognitifs de Microsoft, sur ceux de Google ou d'Amazon, etc. et vous vous rendrez bien vite compte que la tentation de faire appel à l'intelligence exterieure est tout bonnement indomptable
