Le jumeau numérique à l’ère du cloud, le nouveau défi des gestionnaires d’infrastructure

La digitalisation des assets est un défi majeur pour les gestionnaires d’infrastructures. Devant l’intensification de leur exploitation, les exigences des consommateurs en terme de qualité de services, la pression de la concurrence et des pouvoirs publics ou bien simplement le vieillissement des équipements, le jumeau numérique (digital twin pour les bilingues) est ce nouveau domaine rendu accessible par des technologies offrant des sources de données toujours plus précises, en quantité, variées et à moindre coût.

L’industrie 4.0 frappe à la porte et la numérisation des assets, leur intégration dans un modèle d’information dédié, dont le BIM fait partie, est un véritable défi. La remontée d’information dans un système centralisé permet d’obtenir une connaissance plus fine de l’état des différents composants de l’infrastructure, de construire des tableaux de bord (dashboard) métiers pertinents facilitant l’exploitation et la maintenance.

Caractérisation du risque végétation sur une infrastructure ferroviaire

Mais concrètement, comment cela peut s’envisager et se construire, lorsqu’il s’agit de données 3D ? Comment acquérir, traiter et proposer des informations pertinentes et en qualité ? Surtout que chaque métier étant différent, il faudra envisager une brique dédiée pour chaque usage.

Monolithe ou microservices ?

Et justement c’est bien de briques qu’ils s’agit. Et pour penser cette usine 3D on arrive à comparer deux architectures, monolithique et en microservices.

monolith vs microservices — Architecture monolithique et en microservices

Une architecture monolithique est conçue comme un grand système déployé comme une seule unité derrière un répartiteur de charge. Les architectures monolithiques sont simples à construire, à tester et à déployer. Mais l’un des principaux inconvénients des architectures monolithes est le couplage étroit. Au fil du temps, les composants deviennent étroitement liés et enchevêtrés. Ce phénomène affecte la gestion, l’évolutivité et le déploiement continu. Généralement, les monolithes sont idéaux lors du développement d’applications petites et simples.

À l’inverse, une architecture en microservices consiste en des services indépendants des uns des autres. Par essence, les composants sont « divisés » en de petits services autonomes qui peuvent être déployés et industrialisés séparément. Cela facilite le passage à l’échelle car il suffit de passer à l’échelle les composants fortement sollicités. Mais surtout les composants de microservices ne sont pas interdépendants et peuvent donc être testés individuellement. Ce faible couplage facilite les modifications à travers le temps et s’adapte très facilement à un usage très complexe.

Une architecture basée sur des microservices est bon choix lorsque vous développez des systèmes complexes.
Pourquoi une Architecture de Microservices ? | AYMAX Group

Et c’est bien notre cas. La complexité des usages, le diversité des traitements, la quantité de données à traiter nécessitent une réflexion en microservices.

Ainsi, chaque application peut être développée indépendamment par une petite équipe, encapsulée et facilement industrialisée, sans compromettre le fonctionnement de l’usine 3D dans son ensemble. Chaque petite équipe de développement (4-5 personnes maximum) sera ultra efficace, car la communication y est bien meilleure quand dans une très grande équipe en charge d’un monolithe. La distribution et l’intégration continue est simplifiée et bien plus effective, car il est plus facile de déployer un microservice que de tenter d’ériger un monolithe. Le microservice bénéficie de toute l’agilité du devops. Le périmètre du service étant relativement faible, la mise en place de tests dans une approche de « test driven development » est simplifiée.

developers vs communication channels — Canaux de communication monolithiques vs microservices à mesure que la taille totale de l’équipe augmente

Bien évidemment, comme l’échange avec les autres services de fait via des interfaces (API, souvent REST) un effort particulier doit être fait à ce niveau pour garantir la bonne interopérabilité des services.

Et cette approche prend une tout autre dimension si l’on considère la gestion des ressources nécessaire à faire tourner cette usine.

Cloud public ou privé ?

Ce qui vient en tête en premier lieu, c’est que l’applicatif de cette usine 3D sera déployé sur des serveurs et se posera rapidement la question de qui porte la responsabilité de provisionner et de manager les ressources associées et nécessaire au bon fonctionnement de l’ensemble. Même si les grandes entreprises peuvent gérer cela avec un département IT dédié, les processus induits, les logiques d’achats, d’investissement et de RH peuvent ralentir les développements. Comme il est impossible de développer des applications sans l’aide de l’équipe infrastructure cela finit par nous éloigner de notre mission initiale : construire et maintenir cette usine 3D au quotidien.

L’architecture serverless est un modèle dans lequel le fournisseur de services cloud (AWS, Azure ou Google Cloud) est responsable de l’exécution d’un bout de code en allouant de manière dynamique les ressources. Et il ne facture que la quantité de ressources utilisées pour exécuter le code. Le code est généralement exécuté dans des conteneurs sans état pouvant être déclenchés par divers événements, ce sont nos fameux microservices. Non seulement notre usine 3D est robuste de part son architecture et son mode de développement, la mise à l’échelle est simplifiée et les coût de runtime directement lié à la charge de données à traiter.

Combiner serverless et microservices permet d’optimiser les coûts d’exploitation au plus juste

Les services cloud permettent de transformer les dépenses d’investissement de capital dans les équipements informatiques en dépenses d’exploitation
[Dossier] Les CapEx et les OpEx à l’ère du Cloud et des IaaS (lebigdata.fr)

Et pour des décideurs, c’est important. Dans cette configuration, aucun CAPEX, que ce soit au lancement du projet que lors de sa mise à l’échelle, que de l’OPEX, qui est beaucoup plus facile à justifier financièrement pour un asset manager.

D’ailleurs si l’on devait décrire le processus de maturation des données d’un stade « brute, sortie de capteur » à « enrichie, exploitable et structuré », il serait composé de plusieurs étapes, que ce soit de traitement pur ou de contrôle. Chaque étape qui constituerait ce « pipeline » de traitement peut être considéré comme un microservice à part entière.

Et c’est toute cette réflexion que j’accompagne depuis plusieurs années en tant que directeur technique chez Altametris, filiale de sncf réseau. Nous développons toute une usine 3D, de la gestion et la valorisation de données brutes (3D, image, photogrammétrie), extraction de donnés métier avec des algorithmes dédiés, certains exploitant des modèles d’intelligence artificielle, pour offrir tout un catalogue de service, autant de l’assemblage de données de scanner 3D statiques ou dynamiques, de panoramas, de modèles 3D photogrammetriques, à de l’exploitation métier, notamment ferroviaire comme de l’extraction de rail, de fil caténaire, d’objets ferroviaires et général, permettant ensuite, par exemple des analyse de gabarit, de volumétrie de ballast, mesure sur les fils caténaires (entraxe, désaxement), mesure d’entraxe, étude ETCS pour la signalisation, mais aussi des applications en inspection de bâtiments et d’ouvrage d’arts, gestion de la végétation, …

Extraction d’éléments ferroviaire et détection d’obstacles dans un gabarit

La donné en qualité est ensuite distribuée à nos clients finaux, soit directement dans leurs puits de données, soit dans des interfaces de livraisons dédiées et simplifiées, que l’on peut encore penser comme autant de microservices😉

Une approche en microservices permet de ségréger les interfaces

Déployer rapidement des interfaces web avec Streamlit

Et vous comment gérez vous le jumeau numérique dans votre organisation ? Quels sont vos besoins ? Quelles solutions imaginiez vous y apporter ?

Je serais ravi que vous me partagiez vos avis en commentaire !

Le jumeau numérique à l’ère du cloud, le nouveau défi des gestionnaires d’infrastructure

Monolithe ou microservices ?

Cloud public ou privé ?

Sources

Laisser un commentaire Annuler la réponse