Des monolithes aux microservices: l'expérience de M.Video-Eldorado et MegaFon

Le 25 avril, nous, au Groupe Mail.ru, avons organisé une conférence sur les nuages ​​et les environs - mailto: CLOUD . Quelques faits saillants:

• Les principaux fournisseurs russes se sont réunis en une seule étape - Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center et Yandex.Cloud ont parlé des spécificités de notre marché du cloud et de leurs services;
• Des collègues de Bitrix24 ont expliqué comment ils en sont venus au multiclaud ;
• Leroy Merlin, Otkrytie, Burger King et Schneider Electric ont fourni un point de vue intéressant de la part des consommateurs de cloud computing - quelles tâches leurs business sets pour l'informatique et quelles technologies, y compris celles du cloud, ils considèrent comme les plus prometteuses.

Toutes les vidéos de la conférence mailto: CLOUD peuvent être consultées ici , mais ici vous pouvez lire comment s'est déroulée la discussion sur les microservices. Alexander Deulin, directeur du centre de recherche et développement des systèmes commerciaux MegaFon, et Sergey Sergeyev, directeur des technologies de l'information du groupe M. Video-Eldorado, ont partagé leurs cas - réussis - de se débarrasser des monolithes. Ils ont également discuté des questions liées à la stratégie informatique, aux processus et même aux RH.

Panélistes

• Sergey Sergeev , directeur des technologies de l'information , M.Video-Eldorado Group ;
• Alexander Deulin , directeur du centre de recherche et de développement des systèmes commerciaux MegaFon ;
• Modérateur - Dmitry Lazarenko , responsable de PaaS-direction Mail.ru Cloud Solutions .

Après un discours d'Alexander Deulin «Comment MegaFon étend ses activités via une plate-forme de microservices », Sergey Sergeev de M.Video-Eldorado se joint à lui pour la discussion et l'animateur de la discussion Dmitry Lazarenko, Mail.ru Cloud Solutions.

Ci-dessous, nous avons préparé pour vous une transcription de la discussion, mais vous pouvez également regarder la vidéo:

Passer aux microservices - une réponse aux besoins du marché

Dmitry:

Avez-vous déjà réussi à passer aux microservices? Et en général: où voyez-vous le plus grand avantage dans les affaires de l'utilisation des microservices ou de la transition des monolithes aux microservices?

Sergey:

Nous avons déjà parcouru un certain chemin vers la transition vers les microservices et utilisons cette approche depuis plus de trois ans. Le premier besoin qui justifiait le besoin de microservices était l'intégration sans fin de différents produits de première ligne avec le back-office. Et à chaque fois, nous avons dû faire une intégration, un développement supplémentaire, la mise en œuvre de nos règles pour le fonctionnement d'un service.

À un moment donné, nous avons réalisé que nous devions accélérer nos systèmes et nos fonctionnalités de sortie. À ce moment, des concepts tels que les microservices, l'approche microservice existaient déjà sur le marché, et nous avons décidé de l'essayer. Cela a commencé en 2016. Ensuite, la plate-forme a été posée et les 10 premiers services ont été mis en œuvre, par une équipe distincte.

L'un des premiers services, le plus chargé, était un service de calcul des prix. Chaque fois que vous accédez à un canal, au groupe d'entreprises M.Video-Eldorado, que ce soit un site Web ou un magasin de détail, ramasser des marchandises là-bas, voir le prix sur le site Web ou dans le «panier», un service calcule automatiquement le prix. Pourquoi cela est nécessaire: avant cela, chaque système avait ses propres principes de travail avec les promotions - les remises, etc. Le back office est engagé dans la tarification, la fonctionnalité de réduction est implémentée dans un autre système. Il était nécessaire de centraliser et de créer un service unique et détachable sous la forme d'un processus opérationnel qui nous permettrait de le mettre en œuvre. C’est ainsi que nous avons commencé.

La valeur des premiers résultats était très grande. Premièrement, nous avons pu créer des entités détachables qui nous permettent de travailler séparément, agrégées. Deuxièmement, nous avons réduit le coût de possession en termes d'intégration avec un grand nombre de systèmes.

Au cours des trois dernières années, nous avons ajouté trois systèmes de première ligne. Il était difficile de les maintenir dans la même quantité de ressources que l'entreprise pouvait se permettre. Par conséquent, la tâche s'est posée de rechercher de nouvelles sorties, répondant au marché en termes de rapidité, en termes de coûts internes et d'efficacité.

Comment évaluer le succès de la transition vers les microservices

Dmitry:

Comment le succès du passage aux microservices est-il déterminé? Quel était «avant» dans chaque entreprise? Quelle mesure avez-vous utilisée pour déterminer le succès de la transition, qui l'a réellement déterminée?

Sergey:

Tout d'abord, il est né au sein de l'informatique en tant que catalyseur - «déverrouillant» de nouvelles fonctionnalités. Nous avions besoin de tout faire plus rapidement pour relativement le même prix, répondant aux défis du marché. Désormais, le succès s'exprime par le nombre de services réutilisés par différents systèmes, l'unification des processus entre eux. Maintenant, c'est le cas, et à ce moment-là, c'était l'occasion de créer une plate-forme et de confirmer l'hypothèse que nous pouvons le faire, cela donnera l'effet et le calcul de l'analyse de rentabilisation.

Alexandre:

Le succès est plutôt une sensation intérieure. Les entreprises en veulent toujours plus, et la profondeur de notre carnet de commandes est la confirmation du succès. Je pense que oui.

Sergey:

Oui, je suis d'accord. Depuis trois ans, nous avons déjà plus de deux cents services et carnet de commandes. La demande de ressources au sein de l'équipe ne fait qu'augmenter - de 30% par an. C'est parce que les gens ont ressenti: c'est plus rapide, différemment, d'autres technologies, tout cela se développe.

Des microservices viendront, mais le cœur restera

Dmitry:

C'est comme un processus sans fin où vous investissez dans le développement. La transition vers les microservices pour l'entreprise elle-même est-elle déjà terminée ou non?

Sergey:

Réponse très simple. Que pensez-vous: le remplacement des téléphones est un processus sans fin? Nous achetons nous-mêmes des téléphones chaque année. Et voilà: s'il y a un besoin de rapidité, dans l'adaptation au marché, certains changements seront nécessaires. Cela ne signifie pas que nous refusons les choses standard.

Mais nous ne pouvons pas tout embrasser et tout refaire immédiatement. Nous avons des services d'intégration standard hérités qui étaient avant cela: les bus d'entreprise, etc. Mais il y a un arriéré et un besoin aussi. Le nombre d'applications mobiles et leurs fonctionnalités augmentent. En même temps, personne ne dit qu'ils vous donneront 30% plus d'argent. Autrement dit, il y a toujours des besoins d'une part, et d'autre part, une recherche d'efficacité.

Dmitry:

La vie est en bonne forme. (Rires)

Alexandre:

En général, oui. Nous n'avons pas d'approches révolutionnaires pour retirer les parties centrales du paysage. Un travail systématique est en cours pour décomposer les systèmes afin qu'ils soient plus cohérents avec l'architecture des microservices, afin de réduire l'influence des systèmes les uns sur les autres.

Mais nous prévoyons de garder la partie principale, car dans le paysage de l'opérateur, nous allons toujours acheter certaines plates-formes. Encore une fois, vous avez besoin d'un équilibre sain: nous ne devons pas nous précipiter dans le noyau "coupant". Nous mettons les systèmes côte à côte, et maintenant, il s'avère que déjà sur de nombreuses pièces essentielles. De plus, en développant la fonctionnalité, nous faisons les représentations nécessaires pour tous les canaux qui travaillent avec nos services de communication.

Comment vendre des microservices à une entreprise

Dmitry:

Je suis toujours intéressé - pour ceux qui n’ont pas changé d’état, mais qui vont le faire: a-t-il été facile de vendre cette idée aux entreprises et était-ce un pari, un projet d’investissement? Ou c'était une stratégie délibérée: maintenant nous passons aux microservices et c'est tout, rien ne nous arrêtera. Comment c'était avec toi?

Sergey:

Nous n'avons pas vendu l'approche, mais le gain commercial. Il y avait un problème dans les affaires et nous avons essayé de le supprimer. À ce moment-là, cela s'exprimait par le fait que, dans différents canaux, différents principes de tarification étaient utilisés - séparément pour les promotions, les stocks, etc. C'était difficile à entretenir, des erreurs sont survenues, nous avons écouté les plaintes des clients. Autrement dit, nous avons vendu l'élimination du problème, mais est venu avec le fait que nous avons besoin d'argent pour créer une plate-forme. Et ils ont montré une analyse de rentabilisation sur l'exemple de la première étape de l'investissement: comment allons-nous continuer à payer pour cela et que cela nous permettra-t-il de faire.

Dmitry:

Avez-vous en quelque sorte fixé l'heure de la première étape?

Sergey:

Oui bien sûr. Nous avons mis 6 mois à créer un noyau en tant que plateforme et à tester les pilotes. Pendant ce temps, nous avons essayé de créer une plateforme sur laquelle le pilote a patiné. Ils ont en outre confirmé l'hypothèse, et comme cela fonctionne, nous pouvons continuer. Ils ont commencé à reproduire et à renforcer l'équipe - ils l'ont amenée dans une unité distincte, qui ne s'occupe que de cela.

Vient ensuite le travail systématique qui procède des besoins de l'entreprise, des opportunités, de la disponibilité des ressources et de tout ce qui est maintenant en cours.

Dmitry:

Ok Alexander, que dites-vous?

Alexandre:

Nos microservices sont nés de la «mousse de la mer» - en raison d'économies de ressources, en raison de certains équilibres sous forme de capacités de serveur et de redistribution des forces au sein de l'équipe. Initialement, nous n'avons pas vendu ce projet aux entreprises. C'était un projet où nous avons tous deux recherché et développé en conséquence. Nous avons commencé début 2018 et avons développé cette direction avec enthousiasme. Les ventes viennent de commencer et nous sommes en train de le faire.

Dmitry:

Mais il arrive qu'une entreprise vous permette de faire de telles choses sur le principe de Google - en une journée gratuite par semaine? Avez-vous une telle direction?

Alexandre:

Parallèlement à la recherche, nous étions engagés dans des tâches métiers, car tous nos microservices sont des solutions aux problèmes métiers. Ce n'est qu'au début que nous avons construit des microservices qui couvrent une petite partie de la base d'abonnés, et maintenant nous sommes dans presque tous les produits phares.

Et l'impact matériel est déjà clair - nous pouvons déjà être comptés, nous pouvons estimer la vitesse de production des produits et la perte de revenus si nous devions suivre l'ancienne voie. C'est là que nous construisons le dossier.

Microservices: battage médiatique ou besoin?

Dmitry:

Les nombres sont des nombres. Et les revenus ou l'argent économisé sont très importants. Et si vous regardez de l'autre côté? Il semble que les microservices soient une tendance, un battage médiatique et de nombreuses entreprises en abusent? Dans quelle mesure distinguez-vous clairement ce que vous traduisez de ce que vous ne traduisez pas en microservices? Si l'héritage est maintenant, l'auras-tu encore dans 5 ans? Quel sera l'âge des systèmes d'information qui fonctionnent chez M. Video-Eldorado et MegaFon dans 5 ans? Y aura-t-il des systèmes d'information sur dix, quinze ans ou sera-ce une nouvelle génération? Comment voyez-vous cela?

Sergey:

Il me semble que très loin est difficile à faire. Si vous regardez en arrière, qui a suggéré que cela développerait le marché de la technologie et du même apprentissage automatique, l'identification des utilisateurs par face? Mais si vous regardez dans les années à venir, il me semble que les systèmes de base, les systèmes d'entreprise de la classe ERP dans les entreprises - ils fonctionnent depuis longtemps.

Nos entreprises sont ensemble depuis 25 ans, en elles l'ERP classique est situé très profondément dans le paysage du système. Il est clair que nous en retirons quelques morceaux et essayons de les agréger en microservices, mais le noyau restera. C’est difficile pour moi d’imaginer maintenant que nous allons remplacer tous les systèmes de base là-bas et passer rapidement de l’autre côté, plus lumineux, des nouveaux systèmes.

Je soutiens que tout ce qui est plus proche du client et du consommateur, où il y a le plus grand avantage et la plus grande valeur commerciale, où vous avez besoin d'adaptabilité et de vous concentrer sur la vitesse, sur les changements, sur «essayez, annulez, réutilisez, faites autre chose "- là le paysage va changer. Et les produits en boîte n'y sont pas très bien intégrés. Au moins, nous ne voyons pas cela. Il nécessite les solutions les plus simples et les plus légères.

Nous voyons une telle évolution:

• systèmes d'information de base (principalement back-office);
• les couches intermédiaires sous forme de microservices connectent le noyau, agrègent, créent un cache et ainsi de suite;
• les systèmes de première ligne s'adressent au consommateur;
• couche d'intégration, qui est généralement intégrée aux marchés, à d'autres systèmes et écosystèmes. Cette couche est aussi légère que possible, simple, avec un minimum de logique métier.

Mais en même temps, je suis partisan de continuer à utiliser les anciens principes, s'ils sont habitués à l'endroit.

Disons que vous avez un système d'entreprise classique. Il est situé dans le paysage d'un fournisseur, se compose de deux modules qui fonctionnent ensemble. Il existe également une interface d'intégration standard. Pourquoi le refaire et y apporter un microservice?

Mais lorsqu'il y a 5 modules dans le back-office, à partir desquels des informations sont collectées dans le processus métier, qui sont ensuite utilisées par 8 à 10 systèmes frontaux, les avantages sont immédiatement perceptibles. Vous sortez de cinq systèmes de back-office, créez un service, de plus, isolé, qui se concentre sur le processus métier. Vous faites un service technologique - pour qu'il cache les informations et soit tolérant aux pannes, et fonctionne également avec des documents ou des entités commerciales. Et l'intégrer sur un seul principe avec tous les produits de première ligne. Ils ont annulé le produit de première ligne - ils ont simplement désactivé l'intégration. Demain, vous devez écrire une application mobile ou créer un petit site et une seule partie pour atterrir dans le fonctionnel - c'est simple: vous le mettez en place en tant que constructeur. Je vois davantage le développement dans cette direction - du moins dans notre pays.

Alexandre:

Sergey a décrit en détail notre approche, merci. Je dirai simplement où nous n'irons certainement pas - au cœur du sujet, au sujet de la recharge en ligne. Autrement dit, la notation et la facturation resteront, en fait, une batteuse de «battage» qui amortira de manière fiable l'argent. Et ce système continuera d'être certifié par nos autorités réglementaires. Tout ce qui regarde les clients, bien sûr, ce sont des microservices.

Dmitry:

Ici, la certification n'est qu'une histoire. Probablement plus de soutien. Si vous dépensez un peu sur le support ou que le système ne nécessite pas de support et d'amélioration, il vaut mieux ne pas y toucher. Compromis raisonnable.

Comment développer des microservices fiables

Dmitry:

Bon. Mais je suis toujours intéressé. Vous racontez maintenant une histoire à succès: tout allait bien, nous sommes passés aux microservices, avons défendu l'idée devant l'entreprise et tout a fonctionné. Mais j'ai entendu d'autres histoires.

Il y a quelques années, une entreprise suisse, qui a investi deux ans dans le développement d'une nouvelle plateforme de microservices pour les banques, a finalement clôturé ce projet. Complètement plié. Plusieurs millions de francs suisses ont été dépensés, mais finalement ils ont dispersé l'équipe - ce n'est pas le cas.

Avez-vous eu des histoires similaires? Avez-vous rencontré ou rencontré des difficultés? Par exemple, pour la maintenance de microservices, la même surveillance est également un casse-tête dans les opérations de l'entreprise. Après tout, le nombre de composants augmente des dizaines de fois. Comment voyez-vous cela, y a-t-il eu des exemples infructueux d'investissements ici? Et que peut-on conseiller aux gens pour qu'ils ne rencontrent pas de problèmes similaires?

Alexandre:

Des exemples infructueux ont été que l'entreprise a modifié ses priorités et annulé des projets. Lorsqu'elle est à un bon stade de préparation (MVP est en fait prêt), l'entreprise a déclaré: "Nous avons de nouvelles priorités, nous allons vers un autre projet, et nous clôturons celui-ci."

Nous n'avions pas de fichiers globaux avec des microservices. Nous dormons paisiblement, nous avons un quart de travail 24/7 qui dessert l'ensemble du BSS [système de soutien aux entreprises].

Et pourtant - nous louons des microservices selon les règles de location des produits en boîte. La clé du succès est que, premièrement, vous devez réunir une équipe qui préparera entièrement le microservice pour la production. Le développement lui-même est, conditionnellement, de 40%. Le reste est l'analyse, la méthodologie DevSecOps, les bonnes intégrations et la bonne architecture. Nous accordons une attention particulière aux principes de création d'applications sécurisées. Dans chaque projet, des représentants de la sécurité de l'information participent à la fois à la phase de planification de l'architecture et au processus de mise en œuvre. Ils gèrent également des systèmes d'analyse de code pour les vulnérabilités.

Supposons que nous déployions nos services sans état - nous les avons dans Kubernetes. Cela permet à tout le monde de dormir paisiblement grâce aux services de mise à l'échelle et de levage automatiques, et le changement de service détecte les incidents.

Pendant toute la durée de l'existence de nos microservices, il n'y a eu qu'un ou deux incidents qui ont atteint notre ligne. Maintenant, il n'y a plus de problèmes opérationnels. Bien sûr, nous n'avons pas 200, mais environ 50 microservices, mais ils sont utilisés dans les produits phares. S'ils échouaient, nous serions les premiers informés.

Microservices et RH

Sergey:

Je suis d'accord avec mon collègue sur le transfert de soutien - que vous devez organiser le travail correctement. Mais je vais parler des problèmes qui, bien sûr, le sont.

Premièrement, la technologie est nouvelle. C'est un battage médiatique dans le bon sens, et trouver un spécialiste qui comprendra et sera capable de créer cela est un grand défi. La concurrence pour les ressources est folle, respectivement, les experts valent son pesant d'or.

Deuxièmement, lors de la création de certains paysages et d'un nombre croissant de services, le problème de la réutilisation doit être constamment résolu. Comme les développeurs aiment le faire: «Écrivons ici beaucoup de choses intéressantes ici ...» De ce fait, le système grandit et perd son efficacité en termes d'argent, de coût de possession, etc. Autrement dit, vous devez intégrer la réutilisation dans l'architecture des systèmes, inclure dans la feuille de route l'introduction des services et le transfert de l'héritage à la nouvelle architecture.

Un autre problème - bien que bon à sa manière - est la concurrence interne. "Oh, de nouveaux gars de la mode sont apparus ici, ils parlent une nouvelle langue." Les gens, bien sûr, sont différents. Il y a ceux qui ont l'habitude d'écrire en Java et ceux qui écrivent et utilisent Docker et Kubernetes. Ce sont des gens complètement différents, ils parlent différemment, utilisent des termes différents et parfois ne se comprennent pas. La capacité ou l'incapacité de partager la pratique, le partage des connaissances, dans ce sens est également un problème.

Eh bien, la mise à l'échelle des ressources. «Super, allons-y! Et maintenant, nous voulons plus vite, plus. Tu ne peux pas? Est-il impossible de livrer deux fois plus en un an? Pourquoi? " De tels problèmes de croissance sont standard, probablement pour de nombreuses choses, de nombreuses approches, et ils se font sentir.

Concernant le suivi. Il me semble que les services ou les outils de surveillance industrielle apprennent déjà ou sont capables de travailler avec Docker et Kubernetes dans un mode différent et non standard. Pour que vous, par exemple, vous ne disposiez pas de 500 machines Java sous lesquelles tout cela fonctionne, à savoir des agrégats. Mais ces produits manquent encore de maturité, ils doivent passer par là. Le sujet est vraiment nouveau, il sera encore développé.

Dmitry:

Oui, très intéressant. Et cela s'applique aux RH. Peut-être que votre processus RH et votre marque RH ont un peu changé au cours de ces 3 années. Vous avez commencé à recruter d'autres personnes avec une compétence différente. Et il y a probablement des avantages et des inconvénients. Auparavant, la blockchain et la science des données étaient de haute technologie et leurs spécialistes ne valaient que des millions. Maintenant, le prix baisse, le marché est saturé et il y a une tendance similaire dans les microservices.

Sergey:

Oui, absolument.

Alexandre:

HR pose la question: "Où est votre licorne rose entre le backend et le frontend?" Les RH ne comprennent pas ce qu'est un microservice. Nous leur avons révélé un secret et leur avons dit que ce backend avait tout fait et qu'il n'y avait pas de licorne. Mais les RH évoluent, apprennent et recrutent rapidement des personnes qui possèdent des connaissances informatiques de base.

L'évolution des microservices

Dmitry:

Si vous regardez l'architecture cible, les microservices ressemblent à un tel monstre. Votre voyage a duré plusieurs années. D'autres ont un an, d'autres ont trois ans. Vous avez prévu tous les problèmes, l'architecture cible, quelque chose a changé? Par exemple, dans le cas des microservices, passerelles, les maillages de service réapparaissent désormais. Les avez-vous utilisés au début ou avez-vous changé l'architecture elle-même? Avez-vous de tels défis?

Sergey:

Nous avons déjà réécrit plusieurs protocoles d'interaction. Initialement, un protocole est maintenant passé à un autre. Nous augmentons la sécurité et la fiabilité. Nous avons commencé avec la technologie d'entreprise - Oracle, Web Logic. Nous nous éloignons maintenant des produits technologiques d'entreprise dans les microservices et passons à l'open source ou aux technologies complètement ouvertes. Nous abandonnons les bases de données, passons à ce qui fonctionne plus efficacement pour nous dans ce modèle. Nous n'avons plus besoin des technologies Oracle.

, , , , , , . . , , -, - , . , — - , — , . , API.

. , , , , . , . , , CI/CD.

— , : , . , , . : , , .

- , - — backlog' . . 20% , 80% — -. , , , , . .

:

. «»?

:

— . , «» — . , . .

: « ?». : « ?». service mesh. Istio, . . — , , - . , .

:

! . GDPR chief data protection officers, . .

. — . , , .

, !

(1):

, IT- ? , , — . IT- , ?

:

, . , . , . . , CI/CD.

, , -, — . . -, — -. : « ?».

, , , : , -. , , , , .

(2):

, . , - . ? .

:

, .

, , 5-7 . , -. : BSS, .

. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .

. , , . , API-. - , front . , - , — , API- v2. , .

:

. — . , , . : . , unit-. , . push , unit-.

, . , , .

end-to-end , , . , , . — , , . .

:

, unit- . , unit- . , , . — . , . .

(3):

, . ?

: . , . , , , .

, , . ?

:

« » — . -, . , «», . , . — , — .

:

, . , . : . - , , . -.

, , , , . , , . , . , . , .

, , , unit- — , . , .

:

, , ? Backlog ? ?

:

: . backlog, , — . backlog, , backlog . . IT-, . .

backlog' — backlog' — . , — IT. , — . , backlog' , .

, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .

,

La conférence mailto: CLOUD a été organisée par Mail.ru Cloud Solutions .

Nous organisons également d'autres événements - par exemple, @Kubernetes Meetup , où nous recherchons toujours des conférenciers sympas:

• Suivez l'actualité de @Kubernetes et d'autres @Meetup sur notre chaîne Telegram t.me/k8s_mail
• Vous voulez parler à l'un des @Meetup? Laissez une demande à mcs.mail.ru/speak