Get best of the week

Comment nous avons résolu le problème de trois monolithes

Dans les stratégies de la plupart des entreprises, la digitalisation est de plus en plus mentionnée: certaines entreprises tentent de mettre en œuvre des technologies modernes (par exemple, Big Data, IoT, AI, blockchain), tandis que d'autres automatisent partout leurs processus internes. Malgré les efforts et les investissements croissants dans la mise en œuvre des systèmes, beaucoup considèrent les résultats comme médiocres. Idéalement, les organisations modernes devraient être en mesure de créer rapidement de nouveaux produits numériques ou de s'intégrer à des services tiers populaires; prendre des processus au-delà de leur organisation; être en mesure d'interagir efficacement avec les partenaires, tout en maintenant l'isolement de leurs processus. Vous devez également être en mesure non seulement de collecter des données, mais également d'y accéder rapidement et de les gérer. Cependant, même les entreprises matures sont confrontées aux défis de la transformation et de la gestion des données,avec une concurrence constante des priorités de l'entreprise. Qu'est-ce qui les empêche d'atteindre la perfection? 

L'expérience de notre équipe DTG dans la création de produits et services numériques nous permet d'affirmer que la solution à ces problèmes est entravée par le problème de trois monolithes: le monolithe d'application, le monolithe d'intégration et le monolithe de données . Ils sont le résultat des paradigmes hérités de l'architecture et de la culture traditionnelles, en s'appuyant sur les données disponibles et en travaillant dans un système «en couches», où l'isolement du service informatique et des affaires entraîne la perte de données et de connaissances à leur sujet. Comme solution à ce problème, nous voyons une transition des approches traditionnelles de développement et de gestion vers des approches distribuées, ce qui implique de graves changements techniques et culturels dans l'organisation.

Mais tout d'abord. Décrivons brièvement ce que sont les monolithes notoires, puis nous passerons aux solutions que nous proposons pour surmonter les difficultés engendrées par les monolithes.


Monolith d'application


L'un des trois problèmes architecturaux lors de la création de solutions d'entreprise est le monolithe d'applications , qui apparaît à mesure que de plus en plus de fonctions sont ajoutées à une application existante. Au fil des ans, l'application se transforme en un "monstre" avec beaucoup de fonctionnalités entrelacées et de composants co-dépendants, entraînant les points négatifs suivants:

  • la présence d'un point de défaillance unique (en cas de défaillance de l'un des modules d'application, l'application entière échoue et tous les employés travaillant avec cette application cessent de fonctionner);
  • difficulté d'assurer la qualité requise du produit développé, nécessité de tests de régression volumétrique;
  • une équipe monolithique, qu'il n'est pas pratique d'agrandir, car cela n'accélérera pas et ne facilitera pas le processus de développement;
  • , ; , ; 
  • ( -). , , « ». ;
  • .

Les microservices aident à surmonter les problèmes décrits. Le sens de l'approche est qu'une application monolithique est divisée en plusieurs petites applications constituées d'un groupe de services. 


Contrairement aux applications monolithiques, cela offre une évolutivité beaucoup plus grande que l'approche monolithique, car il devient possible de mettre à l'échelle des services fortement chargés selon les besoins, et non l'application entière. Les microservices permettent à plusieurs équipes d'une organisation de travailler de manière indépendante et de publier de nouvelles fonctionnalités comme bon leur semble.

Bien que l'idée de modularité existe depuis de nombreuses années, l'architecture des microservices offre une flexibilité beaucoup plus grande, permettant aux organisations de répondre plus rapidement aux conditions changeantes du marché.

Mais ne croyez pas naïvement que les microservices sauveront complètement votre environnement informatique de la complexité. Avec l'avènement des microservices, il existe un compromis pour augmenter la flexibilité du développement tout en augmentant la complexité de la gestion, du développement et du support du fait de leur décentralisation. De plus, toutes les applications dans un environnement d'entreprise ne conviennent pas à l'architecture de microservices.

Monolith d'intégration


Le deuxième problème architectural, le monolithe d'intégration, est lié à l'utilisation du bus d'entreprise d'intégration ( Enterprise Service Bus , ESB). Il s'agit d'un modèle architectural avec une seule couche d'interaction à l'échelle de l'entreprise qui fournit une messagerie centralisée et unifiée orientée événement. 


Dans cette approche traditionnelle, l'intégration est considérée comme une couche intermédiaire entre les couches de sources de données et leurs consommateurs. ESB fournit des services utilisés par de nombreux systèmes dans différents projets. L'ESB est géré par une seule équipe d'intégration, qui doit être très qualifiée. De plus, il est difficile à mettre à l'échelle. Étant donné que l'équipe ESB est le «goulot d'étranglement» du projet, il est difficile d'émettre des changements et une gamme croissante d'améliorations:

  • L'intégration n'est possible que via le bus dans le cadre de la prochaine version, qui est préférable de soumettre une demande en raison du flux important en quelques mois;
  • tout changement ne peut être effectué que s'il est convenu avec d'autres consommateurs, car tout n'est pas décomposé et isolé. La dette technique s'accumule et ne fait qu'augmenter avec le temps. 

Dans les architectures monolithiques, les données «reposent». Mais toute l'entreprise repose sur des événements en streaming et nécessite des changements rapides. Et là où tout change très rapidement, l'utilisation d'ESB est inappropriée. 

Pour résoudre ces problèmes, l'approche d'intégration Agile aide, ce qui n'implique pas une solution d'intégration centralisée unique pour l'ensemble de l'entreprise ou une seule équipe d'intégration. En l'utilisant, plusieurs équipes de développement interfonctionnelles apparaissent qui savent de quelles données elles ont besoin et de quelle qualité elles devraient être. Oui, avec cette approche, le travail effectué peut être dupliqué, mais il vous permet de réduire la dépendance entre les différentes équipes et aide à mener principalement le développement parallèle de différents services.

Monolith de données


Le troisième problème architectural, mais non moins important, est le problème du monolithe de données, associé à l'utilisation d'un entrepôt de données d'entreprise centralisé ( Enterprise Data Warehouse, EDW). Les solutions EDW sont coûteuses, elles contiennent des données au format canonique, qui, en raison de connaissances spécifiques, sont prises en charge et comprises par une seule équipe de spécialistes, au service de tous. Les données dans EDW proviennent de diverses sources. L'équipe EDW les vérifie et les convertit en un format canonique, qui devrait satisfaire les besoins des différents groupes de consommateurs au sein de l'organisation, et l'équipe est chargée. De plus, les données converties dans un certain format canonique ne peuvent pas être pratiques pour tout le monde et toujours. Conclusion - cela prend trop de temps pour travailler avec les données. En conséquence, il n'est pas possible de lancer rapidement un nouveau produit numérique sur le marché.


Une telle orientation vers la composante centrale, sa dépendance aux changements dans les systèmes environnants est un réel problème dans le développement de nouveaux processus numériques et la planification de leurs améliorations. Les changements peuvent être conflictuels et leur coordination avec d'autres équipes ralentit encore le travail. 

Pour résoudre le problème du monolith de données, un référentiel de données non structuré, Data Lake , a été inventé.. Sa principale différence est que les données «brutes» sont chargées dans Data Lake, il n'y a pas d'équipe unique pour travailler avec elles. Si une entreprise a besoin d'obtenir des données pour résoudre son problème, une équipe est formée qui extrait les données nécessaires à une tâche particulière. À proximité, une autre équipe peut faire de même pour une autre tâche. Ainsi, Data Lake a été introduit afin que plusieurs équipes puissent travailler simultanément sur leur produit. Cette approche implique que les données peuvent être dupliquées dans différents domaines, car les équipes les convertissent sous une forme adaptée au développement de leur produit. Ici, le problème se pose - l'équipe doit avoir des compétences pour travailler avec différents formats de données. Cependant, cette approche, bien qu'elle comporte le risque de coûts supplémentaires,donne aux entreprises une nouvelle qualité et affecte positivement la vitesse de création de nouveaux produits numériques.

Et seules quelques-unes parmi les organisations avancées utilisent une approche encore plus «mature» pour travailler avec les données - le Data Mesh , qui hérite des principes des deux précédents, mais élimine leurs lacunes. Les avantages du Data Mesh sont l'analyse des données en temps réelet une réduction des coûts de gestion de l'infrastructure Big Data. L'approche favorise le traitement de flux et implique que le système externe fournit un flux de données qui fait partie de l'API de la solution source. La qualité des données est de la responsabilité du propriétaire de l'équipe du système qui génère ces données. Pour maximiser cette approche, un contrôle plus strict de la façon dont les données sont traitées et appliquées est nécessaire pour éviter de «faire entrer les gens dans un tas d'informations dénuées de sens». Et cela nécessite un changement dans la pensée de la direction et de l'équipe concernant la façon dont l'interaction de l'informatique avec l'entreprise est construite. Cette approche fonctionne bien dans un modèle orienté produit et non dans un modèle orienté projet.

Une telle infrastructure de données ouvre une perspective complètement différente et facilite la transition de l'état de «stockage des données» à l'état de «réactivité aux données». Le traitement en continu permet aux entreprises numériques de réagir immédiatement aux événements lors de la génération de données, fournissant des moyens intuitifs d'obtenir des données analytiques et de configurer des produits ou des services en temps réel, ce qui aidera l'organisation à prendre une longueur d'avance sur ses concurrents.

Approches distribuées


Pour résumer, la solution aux problèmes de tous les monolithes répertoriés est:

  • diviser le système en blocs distincts axés sur les fonctions commerciales;
  • l'affectation d'équipes indépendantes, chacune pouvant créer et gérer une fonction commerciale;
  • parallélisation du travail entre ces équipes afin d'augmenter l'évolutivité, la vitesse.

Il n'y a pas de solutions simples pour construire l'infrastructure informatique d'une organisation moderne. Et la transition de l'architecture traditionnelle à l'architecture distribuée n'est pas seulement une transformation technique, mais aussi culturelle. Cela nécessite des changements de mentalité concernant l'interaction des systèmes commerciaux et des systèmes d'information. Et si des applications monolithiques existaient auparavant dans l'organisation, des milliers de services fonctionnent désormais et doivent être gérés, maintenus et comparés en termes d'interfaces et de données. Cela augmente les coûts, augmente les exigences pour les compétences des personnes et la gestion de projet. Le service informatique et l'entreprise doivent assumer des responsabilités supplémentaires et s'ils apprennent à gérer cette complexité, cette infrastructure permettra à l'entreprise de répondre aux défis du marché avec une nouvelle qualité supérieure.

Et maintenant, dans quoi sommes-nous exactementUtilisons-nous DTG comme solution au «problème des monolithes» lors de l'optimisation des processus numériques de nos clients et de leur intégration dans l'écosystème des partenaires? Notre réponse est la classe Digital Business Technology Platform (voir la classification analytique de Gartner). Nous l'avons appelée GRANUMet, par tradition, construit sur une combinaison de technologies open source, ce qui nous permet de créer rapidement et facilement des systèmes distribués complexes dans un environnement d'entreprise. Nous aborderons les technologies plus en détail ci-dessous. Qu'est-ce qui est devenu plus facile et plus rapide? En utilisant la plate-forme, nous avons considérablement accéléré l'intégration des plates-formes informatiques client existantes, des systèmes d'interaction client, de la gestion des données, de l'IoT et de l'analyse, nous avons pu intégrer rapidement les systèmes client avec les partenaires de l'écosystème pour gérer les événements commerciaux et prendre des décisions conjointes pour créer une valeur commune. De plus, l'utilisation de technologies open source nous a aidés à répondre aux demandes des clients liées à l'évitement des logiciels sous licence. 

D'un point de vue technique, lors de la digitalisation des processus grâce à l'utilisation d'une architecture distribuée (microservices et approche DataMesh), nous avons pu réduire l'interdépendance des composants et résoudre le problème de développement complexe et long. De plus, nous avons pu traiter les événements de streaming en temps réel, en préservant la qualité des données, et également créer un environnement de confiance pour interagir avec les partenaires.


La plateforme peut être divisée en trois couches logiques. 

  1. La couche inférieure est l'infrastructure. Conçu pour fournir des services de base. Cela comprend la sécurité, la surveillance et l'analyse des journaux, la gestion des conteneurs, le routage réseau (équilibrage de charge), les devops. 
  2. Couche d'intégration - prend en charge une architecture distribuée (approche DataMesh, microservices et traitement de données en continu).
  3. — . (track&trace), , . . 

Parlons plus spécifiquement des technologies open source que nous avons choisies. Lesquels d'entre eux sont utilisés dans leurs meilleures pratiques par les principales sociétés Internet telles que Netflix, LinkedIn, Spotify. Les technologies Kubernetes, Jenkins, Keycloak, Spring Boot, Fluentd, Grafana, Prometheus sont choisies pour combattre le monolithe des applications et pour construire et travailler avec une architecture de microservices, ainsi que dans la poursuite de la flexibilité et de la rapidité des changements. Pour s'éloigner d'une architecture monolithique, l'approche d'intégration agile utilise généralement Apache Camel, NiFi, WSO2 API Manager. Enfin, Kafka, Flink, Salase Event Portal sont utiles pour résoudre le problème du monolith de données, son partitionnement et sa transition vers l'analyse de données en temps réel en utilisant l'approche Data Mesh.

L'illustration ci-dessous représente un ensemble de technologies que, à la suite d'expériences, nous, chez DTG, avons considérées optimales pour résoudre le problème de trois monolithes.


Nous avons commencé l'application pratique de la plate-forme décrite il y a environ un an et aujourd'hui, nous pouvons déjà conclure que, quelle que soit l'industrie, une telle solution intéresse les organisations qui envisagent de réduire les coûts d'exécution de leurs processus commerciaux, d'augmenter l'efficacité de l'interaction avec les partenaires, de créer nouvelles chaînes de valeur. Ces entreprises visent des expériences de flux numériques rapides (tests d'hypothèses, intégration, lancement rapide sur le marché et, en cas de succès local, mise en œuvre mondiale), et ouvriront également de nouveaux canaux de communication avec les clients et établiront une communication numérique plus intense avec eux. le monde. Des postes vacants intéressants

sont toujours ouverts dans notre groupe d'entreprises . Dans votre attente!

More articles:


All Articles