Lorsque nous avons réalisé que ce serait ennuyeux pour nous de tenir la prochaine réunion, nous avons décidé d'en faire quelque chose de plus bourré d'action. A savoir, dans un duel, dans un
duel entre deux approches d'intégration - ESB et Distributed - dont l'honneur a été défendu par des experts poids lourds. Dans cet article, nous vous expliquerons comment la bataille s'est déroulée et découvrirons le vainqueur.
Quelques mots sur le format
Alexander Trekhlebov , notre architecte d'entreprise, a parlé au nom du bus centralisé. Pour la décentralisation - Andrey Trushkin, chef du centre pour l'innovation et les technologies prometteuses de Promsvyazbank. Ils se sont relayés pour faire des rapports sur leurs technologies et ont répondu à diverses questions, provocantes et peu nombreuses. C'était comme ça.
Pourquoi ESB est cool?
Pour commencer, vous devez le mettre au courant et dire comment tout a commencé. Beaucoup se souviennent probablement qu'au tout premier stade, tout s'est passé sans aucune intégration, lorsque chaque système a communiqué et effectué ses tests d'intégration avec tous les autres systèmes.
Par conséquent, si une personne démissionnait ou que quelque chose d'autre lui arrivait, personne ne savait comment tout cela fonctionnerait. Chaque ordinateur a interagi avec un serveur. Quel protocole, quel type d'interaction? Seule la personne qui travaillait dans le système savait tout cela.
Puis vint le bus d'intégration. Cela est apparu non seulement comme ça, mais parce que les principaux protocoles et méthodes d'interaction ont été collectés dessus et qu'il était possible de ne pas forcer le système à décrire des choses spécifiques. Elle pouvait communiquer avec eux en utilisant ses algorithmes internes.
De plus, il s'est avéré que le plus souvent, ils communiquent avec le bus via des files d'attente ou via REST.
Au fil du temps, cependant, le besoin d'un bus et d'un REST dans de nombreux cas a disparu. Mais cela ressemblait à un retour en arrière, des questions importantes étaient à nouveau suspendues:
- Comment orchestrer s'il n'y a pas de pneu. Où cela se produira-t-il?
- Que faire des formats de données et de protocole?
De plus, les performances dans un système centralisé sont bien meilleures que dans Distributed. Vous pouvez compter sur la vitesse, le volume et la disponibilité. Tout cela parce que c'est un système qu'une équipe particulière gère.
À quel point ce système est-il vulnérable? Que se passe-t-il si un ordinateur est piraté?Il y a toujours redondance et centralisation. Dans le cas où l'un est en panne, le système fonctionnera.
Qui est responsable du pneu? Votre équipe ou des développeurs tiers?Dans l'équipe interne, nous fournissons des services opérationnels, assurons la fiabilité et le suivi. Si quelque chose ne fonctionne pas, nous savons où chercher. Il y a une question: "Est-il possible de faire confiance aux fournisseurs dans de tels cas et aux équipes tierces?" Un bon suivi est nécessaire ici. Parce que la qualité, en tout cas, est de la responsabilité de l'équipe interne.
À mesure que le bus se développe, les services ne se connectent pas. Modifiez-vous les services avec des versions ou quoi? Que faire avec Agile?Nous arrivons ici à la question fondamentale.
L'intégration n'est pas une application. Il faisait partie, mais maintenant ce n'est plus le cas. Le développement d'intégration n'est pas le développement d'applications. C'est le développement d'interactions d'intégration ou le développement dans le cadre d'un projet distinct, mais pas spécifiquement d'une application.
Vos préoccupations agiles sont compréhensibles. Ce modèle est utilisé lorsque nous créons un système séparé qui est connecté au bus quelque part sur le côté. Quand je travaillais dans une autre banque, il y avait un tel système: un mois de tests, un mois de développement. Par conséquent, toutes les interactions d'intégration sont rapidement mises en œuvre sur le bus. Encore plus vite que les analystes ne les décrivent, car les systèmes de développement sont assez sophistiqués et simples. Et l'agilité est utilisée dans le développement du système final.
Combien de temps l'équipe recherche-t-elle le service dont elle a besoin et où la recherche-t-elle?Tout le monde rêve qu'il existe une carte du monde sur laquelle tous les principaux secteurs d'activité sont dispersés à travers les continents. Et il est même partiellement mis en œuvre. L'analyste s'y rend et commence à errer intensément à travers les continents, après un certain temps, il trouve l'interaction nécessaire. De plus, si tout va parfaitement, il l'utilise simplement. Sinon, décrit dans TK les ajouts dont il a besoin. Ce serait formidable d'avoir une telle option, mais jusqu'à présent, les systèmes moins pratiques qui nécessitent beaucoup plus de temps et d'efforts pour travailler avec eux sont pertinents.
Ou peut-être que le service Mesh est plus frais?
Pour commencer, beaucoup de choses ont vraiment changé en 3-4 ans. Mais que s'est-il passé exactement? La même banalité que tous les intervenants répètent régulièrement, et par laquelle nous ne pouvons pas non plus passer, s'est produite: le monde change.
Les exigences de vitesse de changement deviennent énormes. Dans le même temps, les exigences de fiabilité, les exigences de sécurité ne disparaissent nulle part et les exigences de charge ne font qu'augmenter. Comme nous pouvons le voir, tout le monde essaie de gagner des parts de marché, ce qui entraîne inévitablement une augmentation de la charge pesant sur les systèmes d'entreprise et, par conséquent, sur l'intégration.
En effet, l'ESB à une époque très cool a servi de modèle pour la mise en œuvre technique en termes de décentralisation des applications, d'allocation de la logique entre les différentes applications, un dispositif unifié pour intégrer les applications entre elles. Disons simplement conditionnellement unifié.
Imaginons maintenant qu’il n’existe pas 20 systèmes dans l’entreprise - après tout, elle cherche à passer à l’architecture même que l’on appelle le mot à la mode «microservices». Et qu'est-ce qu'un microservice? Il existe de nombreuses définitions, l'une d'elles est périodiquement utilisée par Martin Fowler: c'est un service qu'un développeur moyen peut développer en un seul sprint. Imaginez le nombre de ces services dans une grande entreprise. Par exemple, Netflix estime le nombre de ses microservices à 800-900. En principe, dans une entreprise qui cherche à construire un écosystème externe partenaire, ces services peuvent dépasser mille. Mais chacun de ces services à long terme supporte une charge énorme et devrait se développer de manière indépendante.
Et le bus? Si le bus reste ce complexe commun entre eux, il s'avère qu'il devient un goulot d'étranglement et retarde le développement des services. Non seulement parce qu'elle attend ces mêmes services, mais parce qu'elle se développe en tant qu'équipe distincte, par des personnes qui possèdent ces mêmes technologies et compétences.
Et maintenant, imaginons: plusieurs dizaines d’équipes de produits se développent et travaillent avec nous. Et chacun d'eux a vu plusieurs services. Et le bus est conduit par deux équipes. Naturellement, ces équipes à forte probabilité ne pourront pas développer cette intégration même avec le niveau de vitesse et de qualité nécessaire.
La question se pose: "Comment pouvons-nous assurer la même vitesse rapide sans perdre l'accessibilité, la sécurité, etc.?" La réponse est très simple: "Laissez ces services interagir directement, sans intermédiaire explicite."
Ensuite, la prochaine question importante se pose: "Comment les services apprennent-ils les uns des autres?" Et ici, la réponse est également très simple: vous pouvez trouver un système avec lequel les services eux-mêmes rendraient compte d'eux-mêmes. Autrement dit, au moment où le service est développé, il publiera indépendamment des informations sur lui-même dans un certain registre. Et sur la base de ces informations, tous les services pourront commencer à interagir avec lui.
Ainsi, le concept d'une «grille» de services a été formé - comme on l'appelait à l'origine,
«maillage de services» . Comme une sorte de niveau intermédiaire d'intégration entre les services, qui fournit une telle intégration, comme s'il s'agissait d'une solution cloud.
Les grandes entreprises tentent désormais de résoudre les problèmes de vitesse de développement en parallèle - pour trouver pour cela une certaine solution générale, distribuée et souvent embarquée. Dans ce cas, chaque service utilise un ensemble particulier de bibliothèques prédéfinies afin de publier automatiquement des informations dans un registre lors du déploiement.
Souvent, la question se pose toujours: «Mais que faire du modèle canonique de données, dont la source, en règle générale, était l'ESB, qui a investi tant d'argent et d'efforts pour le mettre en œuvre et le maintenir?» Après tout, c'était un modèle standard. Voici une contre-question: «Et quels avantages cela nous a-t-il apportés? Et n'est-ce pas le point même qui a retardé notre développement? " En effet, lors du développement de services, le modèle se développe de plus en plus. Il y aura toujours de nouveaux défis.
Pour le dire franchement, le
coût de l'ajout de nouveaux appareils, de l'organisation de l'interaction, etc., en règle générale, est nettement inférieur au coût de la mise à jour du modèle de données canonique ESB .
De plus, l'intégration décentralisée garantit dans une large mesure cette même haute disponibilité. Chacun des microservices est indépendant, y compris des autres microservices, mais dépend de manière critique de la charge externe qui lui est placée. Déployé en parallèle avec l'intégration, il peut également être mis en œuvre indépendamment sur le plan technologique.
Parfois, l'utilisation d'un ESB assez lourd dans des conditions modernes n'a pas de sens, ou même vice versa, réduit la qualité de la solution. L'application des technologies sans serveur, l'infrastructure même qui ne s'adapte pas aux besoins éphémères des solutions en cours de création, est déjà sur le point, mais est déjà livrée dans la version nécessaire formée pour un service particulier. Maintenant, cela ressemble à quelque chose de très éloigné, mais le monde change, comme cela a déjà été dit, assez rapidement.
De nombreux éditeurs de logiciels optent pour cette solution en termes de solutions d'intégration. Il existe déjà des cadres qui implémentent essentiellement le concept de maillage de service (le même Linkerd ou Istio). La même chose se produit déjà dans le cadre de l'hébergement d'un grand nombre de proxys réseau et de services d'intégration de maillage de service. Beaucoup en commun avec les systèmes d'orchestration de maillage de service et de conteneurs comme Kubernetes.
Est-il possible de construire Distributed basé sur ESB? Autrement dit, est-il possible d'en créer un autre à partir d'un système? Et si oui, à quoi servent ces différends?Ici, Hegel et son «déni de négation» viennent à l'esprit. Quand une idée se répète à un niveau historique supérieur. Venir de l'un à l'autre, à mon avis, est possible. Une autre question est de savoir comment nous allons procéder à ce sujet. En effet, par essence, le concept même de microservices et leur mise en œuvre est largement similaire au concept d'intégration, qui était à l'origine: l'interaction des microservices entre eux, chacun avec chacun.
Est-il possible d'en venir à l'intégration selon les principes du réseau, si on passe de l'ESB? En fait, Red Hat, maintenant IBM, suit déjà le même principe. Il suffit de regarder leur compréhension du concept de pile d'intégration et d'intégration flexible (Agile Integration). Ils offrent un grand nombre de proxys d'intégration qui ne sont pas surchargés de logique. La chose la plus importante est la transparence et la connaissance même des services requis par tous les nouveaux entrants dans l'interaction.
Votre banque comprend-elle que l'ESB a survécu si elle continue à y investir des budgets importants?Franchement, les questions budgétaires sont un secret commercial. Quant aux approches utilisées, nous développons actuellement un parallèle de deux approches. À Promsvyazbank, il y a vraiment de nombreux systèmes liés au bus. Ils sont toujours intégrés via le bus. Mais nous, pour notre part, comprenons que l'ESB est une approche peu prometteuse et qu'il est plus efficace d'investir dans des intégrations distribuées sans utiliser de bus. C'est maintenant notre priorité stratégique.
Où est la place pour la surveillance des affaires dans un système distribué?Dans l'intégration décentralisée, la présence d'un grand nombre de services n'exclut pas la présence d'un suivi des activités. Tout cela peut être défini au niveau des cadres respectifs. En conséquence, cette surveillance peut fusionner des informations dans un certain stockage responsable des données. Ces données y sont analysées et un rapport de synthèse est préparé.
Comment voyez-vous le plan de transition vers une intégration décentralisée?La transition vers une intégration décentralisée est logique à considérer dans le contexte de la transition vers de nouveaux principes architecturaux. Il s'agit d'une transition complexe qui ne peut pas se produire en même temps. Oui, vous pouvez essayer de le tenir sous la forme d'un "big bang", mais cette option de scénario comporte de sérieux risques. Plus logique est la possibilité de créer un nouveau circuit en parallèle avec le circuit existant et, à mesure qu'il est créé (en mode itératif), d'y introduire de nouveaux produits. Au fur et à mesure que le nouveau contour architectural se développe, les produits du paysage informatique actuel qui ont résisté à l'épreuve du temps peuvent y être transférés. Un tel chemin est assez long - il est estimé jusqu'à 4-5 ans - mais grâce à l'itération, il est possible d'obtenir des résultats dans le mode de fonctionnement industriel en séquence.
Qui a gagné?
Après trois tours interactifs avec présentations, questions et réponses, le public s'est caché en prévision de l'annonce du résultat final. Vous vous rendez probablement compte que le vainqueur de la bataille PSB était Andrey Trushkin et le système distribué.
En conclusion, nous vous proposons une vidéo qui vous aidera à ressentir l'atmosphère de notre bataille: