👏🏻 🎺 👐🏼 Microservices ou systèmes modulaires? Comment un client peut-il choisir une approche de l'architecture informatique d'un produit 👧🏿 🙍🏾 ⤵️

Les microservices et les systèmes modulaires sont des types d'architecture de solutions informatiques.

Lorsque nous travaillons avec des modules, nous finalisons une version boîte d'un produit informatique existant.

Par version en boîte, nous entendons un monolithe, un système prêt à l'emploi avec un noyau qui est livré à tous les clients de la même manière, "tel quel".

Le raffinement consiste à créer des modules avec des fonctionnalités manquantes.

Nous obtenons de nouveaux modules en réutilisant des parties du monolithe (noyau ou autres modules).
La logique métier est écrite à l'intérieur du monolithe: pour un programme (application, site, portail) il y a un point d'entrée et un point de sortie.

Lorsque nous travaillons avec des microservices, nous créons un produit informatique à partir de zéro, en le composant à partir de «briques» - des microservices atomiques qui sont responsables d'un petit processus distinct (envoyer une lettre, recevoir des informations sur la commande, modifier le statut de la commande, créer un client, etc.).
Un ensemble de ces blocs est combiné par la logique métier dans un système commun (par exemple, en utilisant BPMS). Malgré la présence de connexions, chaque bloc est autonome et possède ses propres points d'entrée et de sortie.

La plupart des produits informatiques pour nos clients commencent par un développement modulaire. Certains d'entre eux évoluent avec le temps vers des microservices. Pour l'autre partie, les microservices ne sont pas nécessaires. Dans cet article, nous examinerons pourquoi il en est exactement ainsi et quels critères aident à déterminer s'il est nécessaire d'implémenter des microservices ou si vous devez vous limiter à travailler avec des modules.

Avantages de l'architecture modulaire

Tous les systèmes CMS (Bitrix, Magento, Drupal, Hybris, etc.), CRM, ERP, WMS et bien d'autres ont des versions en boîte. Ils se vendent bien et sont très demandés.
Examinons ces raisons objectives pour lesquelles les clients choisissent le plus souvent de travailler avec une architecture modulaire et d'acheter volontiers des solutions en boîte.

Rapidité de mise en œuvre L'

installation, la configuration et le remplissage des répertoires de ces logiciels prennent un peu de temps. Il est réaliste pour une entreprise de taille moyenne de commencer à travailler avec une boîte trois à quatre mois après le début, parfois même un peu plus tôt.

Pour les petites entreprises, cette période ne peut être que de quelques jours.
. , enterprise- .
. . , , , .
,

. , .

Il existe d'autres facteurs subjectifs qui peuvent être trompeurs et influencer la décision d'utiliser des boîtes et des modules.

1. Course des fabricants

Les vendeurs de logiciels convainquent chaleureusement les clients que leur solution prête à l'emploi est la bonne: elle a été testée pendant des années, et à la mode, et en entreprise, et populaire, et marketing ... Tout fournisseur: Bitrix, Magento, SAP, Oracle, OpenCart, Django et tout le monde travaille dur sur les techniques de marketing et de vente.

2. Idée fausse sur la complexité des améliorations

Les clients sont souvent pleins d'optimisme. Ils choisissent un logiciel en boîte et pensent: «Oui, des améliorations seront nécessaires. Mais c'est facile: vous n'avez pas à inventer quelque chose de nouveau. Nous avons une version populaire, mais des millions d'utilisateurs ne peuvent pas faire d'erreurs et acheter un mauvais produit. »
À leur avis, le processus de raffinement ressemble à ceci: il existe une fonctionnalité principale (encadrée). Pour "terminer" quelque chose, les développeurs devront "simplement" redéfinir le module ou écrire rapidement le leur. Dans ce cas, il n'est pas nécessaire d'utiliser des méthodes répétées, car tout est censé être pensé dans le monolithe: des méthodes communes de calcul des taxes sont prescrites, il existe des règles claires pour l'écriture des modes de livraison et de paiement, un flux de travail clair des commandes, etc.

Dans la vraie vie, les choses sont différentes. Et après des émotions agréables depuis le début facile de travailler avec la boîte, les clients sont toujours confrontés à une dure réalité. Le plus souvent, cela se produit avec des entreprises de moyennes et grandes entreprises, dont les projets ont une logique commerciale unique, et des améliorations à grande échelle sont nécessaires.

Si votre entreprise est une petite entreprise et que le logiciel n'est pas votre principal atout, une solution en boîte populaire (ou mieux - un cloud) vous conviendra très probablement.

Examinons les problèmes que vous pouvez rencontrer lorsque vous travaillez avec une architecture modulaire et comment les microservices aident à éviter cela.

Problèmes des systèmes modulaires

Le principal problème est que tous les systèmes modulaires ne sont pas conçus pour redéfinir sérieusement la fonctionnalité. Ils ont une boîte, des modules prêts à l'emploi - il vaut mieux les utiliser.

Plus la taille du projet et la complexité de leurs personnalisations seront proches du niveau de l'entreprise, plus la réalisation des modules posera de problèmes. Parlons des principaux.

Problème n ° 1. Le cœur du système devient un point de décélération et la modularité devient une complication inutile.

Supposons que votre projet soit associé à une logique d'entrepôt complexe. Si vous choisissez une architecture modulaire, les développeurs n'ont pas seulement besoin de créer des fonctionnalités pour gérer ces entrepôts - ils doivent redéfinir ou étendre le module multicœur, qui, à son tour, utilise des méthodes de noyau.

Dans ce cas, il est nécessaire de prendre en compte la logique complexe des retours aux entrepôts: dépendance vis-à-vis des événements du système CRM, circulation des marchandises entre les catalogues, etc. Il convient également de considérer la logique cachée associée au retour des fonds, aux points bonus, etc.

Lorsque tant de redéfinitions se produisent, le monolithe change considérablement. Il est important de se rappeler que la relation entre le volume de nouvelles fonctionnalités et le nombre de modules est non linéaire: pour ajouter une fonction, vous devez soit apporter des modifications à plusieurs modules, chacun changeant le fonctionnement de l'autre, soit redéfinir un grand nombre de méthodes d'autres modules dans le nouveau module, ce qui ne change pas l'essence.

Après toutes les modifications, le système devient si compliqué qu'un nombre indécemment important d'heures sera nécessaire pour ajouter les personnalisations suivantes.

Problème n ° 2. Le principe de l'auto-documentation n'est pas pris en charge dans les systèmes modulaires.

La documentation des systèmes modulaires est difficile à maintenir à jour. C'est beaucoup et cela devient obsolète à chaque changement. L'affinement d'un module implique des modifications dans plusieurs autres documents (utilisateur, documentation technique), et tous doivent être réécrits.

En règle générale, il n'y a personne pour faire un tel travail: passer du temps de précieux informaticiens à ce sujet signifie simplement épuiser le budget. Même l'utilisation du stockage de documentation en code (PHPDoc) ne garantit pas sa fiabilité. Au final, si la documentation peut différer de l'implémentation, elle sera forcément différente.

Problème n ° 3. Plus grande cohérence du code - le chemin de la régression: "ils l'ont changé ici, il est tombé"

Les problèmes classiques des systèmes modulaires sont dans la lutte contre la régression.

Le développement TDD est difficile à utiliser pour les monolithes en raison de la grande cohérence des différentes méthodes (vous pouvez facilement passer 30 lignes de tests sur cinq lignes de code, plus les appareils).
Par conséquent, dans la lutte contre la régression, il est nécessaire de couvrir le fonctionnel avec des tests d'intégration.
Mais compte tenu du développement déjà lent (après tout, vous devez le développer soigneusement pour permettre de nombreux remplacements), les clients ne veulent pas payer pour des tests d'intégration complexes.

Les tests fonctionnels deviennent aussi gros que vides de sens. Ils courent pendant des heures, même en parallèle.

Oui, un front moderne comme PWA peut être testé de manière API. Mais les tests dépendent souvent de la réception de données du circuit externe - et commencent donc à échouer si, par exemple, le test SAP est en retard sur l'épicerie de N mois, et le test «1C» envoie des données incorrectes.

Lorsque vous devez télécharger une petite modification pour un module, les développeurs doivent choisir entre deux maux: lancer une exécution complète de CI et passer beaucoup de temps sur un déploiement ou mettre en place un correctif sans exécuter de test, risquant de casser quelque chose. C'est très dramatique lorsque de telles modifications arrivent du service marketing le Black Friday. Bien sûr, tôt ou tard, une régression et une erreur humaine se produiront. Est-ce familier?

En fin de compte, pour atteindre les objectifs commerciaux, l'équipe passe en mode de fonctionnement d'urgence, jongle habilement avec les tests et examine attentivement les tableaux de bord des journaux - Kibana, Grafana, Zabbix ... Et qu'obtenons-nous finalement? Burnout.

Vous devez admettre qu'une telle situation de régression n'est pas comme «l'entreprise stable» comme elle devrait l'être dans les rêves et les rêves du client.

Problème n ° 4: Connectivité du code et mise à jour de la plateforme

Un autre problème avec la connectivité du code est la difficulté de mettre à jour la plateforme.

Par exemple, Magento contient deux millions de lignes de code. Partout où nous regardons, il y a beaucoup de code partout (Akeneo, Pimcore, Bitrix). Lors de l'ajout de fonctionnalités au noyau, il serait préférable de prendre en compte les changements dans vos modules personnalisés.

Voici un exemple en direct pour Magento.
Fin 2018, une nouvelle version de la plateforme Magento 2.3 est sortie. Multistores et Elasticsearch ont été ajoutés à l'édition Open Source. De plus, des milliers de bugs ont été corrigés dans le noyau et quelques goodies dans OMS ont été ajoutés.

À quels problèmes les projets de commerce électronique ont-ils déjà écrit plusieurs magasins dans Magento 2.2? Ils avaient besoin de réécrire un tas de logique dans le traitement des commandes, le paiement, les cartes de produits afin d'utiliser la fonctionnalité en boîte. En effet, «si bien» - pourquoi dupliquer la fonctionnalité de la version en boîte dans les modules? La réduction du volume de code personnalisé dans un grand projet est toujours utile - après tout, toutes les méthodes de boîte prennent en compte ces multi-entrepôts, et la mise à jour de la boîte sans une telle refactorisation peut être inutile (notez les problèmes de sécurité pour plus de simplicité, d'autant plus qu'ils peuvent être cumulés sans mise à jour).

Imaginez maintenant: combien de temps sera consacré à une telle mise à jour et comment peut-elle être testée sans tests d'intégration, qui sont difficiles à écrire?

Il n'est pas surprenant que pour beaucoup, la mise à niveau de la plateforme se fasse soit sans refactoring, mais avec une augmentation de la duplication, ou (si l'équipe veut tout faire par le feng shui) avec un «départ» de longue date en refactoring et restauration de l'ordre.

Problème n ° 5. Opacité des processus opérationnels

L'un des problèmes les plus importants de la gestion de projet est que le client ne voit pas toute la logique et tous les processus métier du projet. Ils ne peuvent être restaurés qu'à partir de code ou de documentation (dont la pertinence, comme nous l'avons dit plus haut, est problématique à maintenir dans les systèmes modulaires).

Oui, Bitrix a une partie BPM, tandis que Pimcore a une visualisation de flux de travail. Mais cette tentative de gérer des modules via des processus métier est toujours en conflit avec la présence d'un noyau. En outre, les événements, les temporisations complexes, les opérations transactionnelles - tout cela ne se produit pas dans les monolithes BPM. Je le répète: cela s'applique aux moyennes et grandes entreprises. Pour une petite entreprise, les capacités des systèmes modulaires sont suffisantes. Mais si nous parlons du segment des entreprises, il manque encore à cette solution un centre de contrôle unique où vous pouvez aller voir le diagramme de tout processus, de tout état, comment exactement quelque chose se passe, quelles sont les exceptions, les minuteurs, les événements et les couronnes . Il n'y a pas suffisamment d'opportunités pour changer les processus métier, mais pas les modules. La gestion des processus du projet se noie dans la vitesse du changement et la cohérence de la logique.

Problème 6. Complexité de la mise à l'échelle du système

Si vous déployez un monolithe, il sera déployé dans son intégralité avec tous les modules sur chaque serveur d'applications. Ceux. vous ne pouvez pas augmenter séparément le service de traitement des commandes et des bonus dans une saison, séparément du reste du code.

Besoin de plus de mémoire et de processeurs, ce qui augmente considérablement le coût du cluster.

Comment les microservices sauvent les clients des défauts typiques du développement modulaire. Microservices Orchestration dans Camunda et jBPM

Spoiler: La solution aux problèmes répertoriés dans le dernier paragraphe est possible en utilisant BPMS et en orchestrant des systèmes de microservices.

BPMS (English Business Process Management System) est un logiciel de gestion des processus métier dans une entreprise. Les BPMS populaires avec lesquels nous travaillons sont Camunda et jBPM.

Orchestration décrit comment les services doivent interagir les uns avec les autres à l'aide de la messagerie, y compris la logique métier et une séquence d'actions. En utilisant BPMS, nous ne dessinons pas seulement des schémas abstraits - notre processus métier sera exécuté en fonction du dessin. Ce que nous voyons dans le diagramme est garanti en corrélation avec le fonctionnement du processus, quels microservices sont utilisés, quels paramètres, selon quelles tables de décision, une logique particulière est sélectionnée.

Par exemple, nous prenons un processus fréquemment rencontré - l'envoi d'une commande pour livraison.

Par tout message ou appel direct, nous commençons le traitement des commandes avec le processus de choix d'un mode de livraison. La logique de sélection est définie.

En conséquence, les processus, les services et le développement:

devenir rapidement lisible;
auto-documentation (ils fonctionnent exactement comme ils sont dessinés, et il n'y a pas de rassynchronisation entre la documentation et le travail réel du code);
vient d'être débogué (il est facile de voir comment se déroule tel ou tel processus et de comprendre l'erreur).

Nous nous familiariserons avec les principes de fonctionnement des systèmes de gestion des processus métier.

Principe n ° 1 du BPMS. Le développement devient visuel et processus

BPMS vous permet de créer un processus métier dans lequel l'équipe projet (développeur ou utilisateur métier) détermine la séquence de lancement des microservices, ainsi que les conditions et les branches le long desquelles elle se déplace. Dans ce cas, un processus métier (séquence d'actions) peut être inclus dans un autre processus métier.

Tout cela est clairement présenté dans BPMS: en temps réel, vous pouvez regarder ces schémas, les éditer, les mettre de manière productive. Ici, le principe d'un environnement auto-documenté est pleinement respecté - le processus fonctionne exactement comme il est visualisé.

Tous les microservices deviennent des cubes de processus qui peuvent être ajoutés à partir d'un composant logiciel enfichable à un utilisateur professionnel. L'entreprise gère le processus et le développeur est responsable de la disponibilité et du bon fonctionnement d'un microservice particulier. De plus, toutes les parties comprennent la logique générale et le but du processus.

Principe n ° 2 du BPMS. Chaque service a des entrées et des sorties claires.

Le principe semble très simple, et il peut sembler à un développeur ou utilisateur professionnel inexpérimenté que BPMS n'améliore en rien la stratégie d'écriture de microservices. Comme, les microservices normaux peuvent être écrits sans BPMS.

Oui, c'est possible, mais difficile. Lorsqu'un développeur écrit un microservice sans BPMS, il souhaite inévitablement économiser sur l'abstrait. Les microservices deviennent franchement grands, et parfois ils commencent même à en réutiliser d'autres. Il y a une volonté d'économiser sur la transparence du transfert du résultat d'un microservice à un autre.

BPMS vous encourage à écrire de manière plus abstraite. Le développement est effectué avec précision le processus, avec la définition de l'entrée et de la sortie.

BPMS Principe No. 3. Concurrence du traitement de la file d'attente

Imaginez le processus de traitement des commandes: nous devons aller sur un marché, ramasser toutes les bonnes commandes et commencer à les traiter.

Regardez le diagramme (une partie du diagramme). Ici, il est déterminé que toutes les 10 minutes, nous vérifions tous les ordres du marché, puis exécutons en parallèle (comme indiqué par le «hamburger» vertical dans l'ordre de traitement) le traitement de chaque ordre. En cas de succès, transférez toutes les données vers ERP et terminez le traitement.

Si nous devons soudainement augmenter les journaux pour traiter une commande spécifique, dans Camunda, JBoss ou tout autre BPMS, nous serons en mesure de restaurer complètement toutes les données et de voir dans quelle file d'attente elles se trouvaient et avec quels paramètres d'entrée / sortie.

Principe BPMS n ° 4. Erreur et escalade

Imaginez qu'une erreur s'est produite lors du processus de livraison. Par exemple (en passant, c'est un cas réel), la société de transport a pris la commande, puis l'entrepôt a brûlé. Une autre histoire vraie: le réveillon du Nouvel An, le produit a d'abord été retardé, puis peut-être perdu.

Dans ce cas, les événements sont déclenchés par la souris dans BPMS, par exemple, la notification d'un client en cas de dépassement du délai de livraison. Si vous avez reçu une erreur de la société de transport à l'intérieur, vous pouvez démarrer le processus dans votre propre agence et tout interrompre: notifiez, accordez une remise sur la prochaine commande, retournez l'argent.

Toutes ces exceptions sont difficiles non seulement à programmer en dehors de BPMS (par exemple, une minuterie dans une minuterie), mais aussi à comprendre dans le contexte de l'ensemble du processus.

Principe n ° 5 du BPMS. Le choix des actions pour l'un des événements et les options interprocessus

Soumettez la même commande lors de la livraison.

Au total, nous avons trois scénarios:

les marchandises ont été livrées comme prévu;
les marchandises n'ont pas été livrées comme prévu;
l'article a été perdu.

Directement dans BPMS, nous pouvons déterminer la procédure pour l'expédition des marchandises à l'entreprise de transport et attendre l'un des événements par commande:

livraison réussie (messages du processus de livraison du produit indiquant que tout a été livré);
ou le début d'un certain temps.

Si le temps ne s'est pas écoulé, vous devez démarrer un autre service: analyser cette commande spécifique avec l'opérateur (vous devez définir une tâche pour lui dans le système OMS / CRM pour savoir où se trouve la commande) avec une nouvelle notification du client.

Mais si, au cours de l'enquête, la commande a néanmoins été rendue, il est nécessaire d'interrompre l'enquête et d'achever le traitement de la commande.

Dans BPMS, toutes les interruptions et exceptions sont du côté BPMS. Vous ne surchargez pas le code avec cette logique (et la présence même d'une telle logique dans le code rendrait les microservices volumineux et mal réutilisés dans d'autres processus).

Principe BPMS n ° 6. Dans votre Camunda, vous verrez tous les journaux

En utilisant les événements et l'option interprocessus, vous:

Vous voyez toute la séquence des événements dans une fenêtre (ce qui se passe avec la commande, quelle branche des exceptions elle a traversée, etc. - c'est facile à voir);
Vous pouvez collecter toutes les analyses pour BI sur la base des journaux BPMS seuls (sans avoir besoin de surcharger les microservices avec les événements de journalisation).

Vous pourrez ainsi collecter des statistiques spécifiques sur les problèmes de traitement, les taux de transition, tous les processus de l'entreprise. Il y a une unification des informations de journalisation - il est facile de lier l'événement dans la livraison avec l'action de l'opérateur ou l'événement de tout autre système d'information.

Faites attention à la différence avec le système modulaire: des journaux universels peuvent également y être créés, mais lorsque vous interagissez avec d'autres systèmes, vous devrez également faire quelque chose avec l'unification de la connexion, et ce n'est pas toujours possible.

Conclusions: une comparaison du microservice et de l'architecture modulaire

Chaque type d'architecture a ses avantages et ses inconvénients. Il n'y a pas de solution universelle.

Nous ne préconisons pas un passage massif aux microservices. Au contraire, pour une petite entreprise ou lors de l'utilisation d'un très petit nombre de personnalisations, une approche modulaire sera plus adaptée.

De plus, nous ne sommes opposés à aucune solution informatique (Bitrix, Magento, frameworks comme Symfony ou Django, etc.), car nous développons plus de six mille heures de code chaque mois sur ces seuls frameworks, et la même quantité de front'a et microservices. Par conséquent, nous sommes convaincus qu'il est important de rechercher une solution technique adaptée, et de ne pas promouvoir l'utilisation d'une plate-forme spécifique (vers laquelle, hélas, une part importante des ventes en informatique est en baisse).

Dans les sections précédentes de l'article, vous avez découvert les inconvénients et les avantages de l'architecture modulaire. Nous espérons que cela a déjà aidé à évaluer si le raffinement de la version en boîte ou la création de microservices à partir de zéro serait plus approprié. S'il n'a pas été possible de décider, voyons comment les différents types d'architecture changent en fonction de la durée de vie du projet.

Au début du projet:

avec les microservices - vous n'avez aucune fonctionnalité et vous devez tout écrire pour vous mettre au travail;
avec un système modulaire - à partir de la version en boîte, une grande quantité de fonctionnalités est immédiatement disponible, et vous pouvez commencer à utiliser le produit peu de temps après l'achat.

Après les 3 à 4 premiers mois de développement (il s'agit de la date de sortie moyenne du premier MVP) et au-delà:

avec microservices - le volume de fonctionnalités est progressivement aligné par rapport à la version en boîte. Pour les entreprises de taille moyenne, l'architecture de microservices rattrapera assez rapidement la modularité, mais pour les grandes - généralement instantanément. Et à l'avenir, la maintenance et le développement d'un système modulaire en termes d'unité fonctionnelle vont augmenter;
avec un système modulaire - la vitesse de développement des fonctionnalités sera nettement inférieure à celle des microservices.

En conclusion, regardons à quoi ressemble l'orchestration des microservices avec des exemples spécifiques.

Exemples de visualisation d'orchestration des services

Considérez l'orchestration des services à l'aide de Camunda. À partir des images suivantes, vous pouvez évaluer à quel point il est pratique de gérer les microservices à l'aide de BPMS avec un orchestrateur. Tous les processus sont visuels, la logique est évidente.

Les processus métier ressemblent à ceci:

Exemple (commande, service de disponibilité):

On peut voir que dans cette commande il y avait une branche «Pas de marchandise».

Une autre copie de la commande (est allée à l'assemblage): La

commande est allée plus loin et selon la table de décision (DMN) est allée à la branche de traitement par un certain opérateur de service de livraison (Boxberry):

Entretien du processus imbriqué: Le

processus imbriqué a fonctionné:

Historique des processus métier:

Propriétés de cette visualisation:

les processus métier sont faciles à lire même par un utilisateur non préparé;
ils sont exécutables, c'est-à-dire qu'ils fonctionnent exactement comme ils sont dessinés, il n'y a pas de rassynchronisation entre la "documentation" et le travail réel du code;
les processus sont transparents: il est facile de voir comment s'est déroulée une importation, une commande ou un traitement particulier, il est facile de voir où l'erreur a été commise.

Rappelons que chez kt.team, nous utilisons à la fois le développement modulaire et le développement de microservices, en choisissant la bonne option pour chaque produit individuellement. Mais si le choix a déjà été fait en faveur d'une architecture de microservices, alors nous sommes fermement convaincus qu'il est impossible de se passer de systèmes BPM comme Camunda ou jBPM.

Voir aussi: vidéo sur le thème «Microservice ou architecture monolithique: que choisir?»

Microservices ou systèmes modulaires? Comment un client peut-il choisir une approche de l'architecture informatique d'un produit