Le 25 avril, chez Mail.ru Group, nous avons organisé une conférence sur les nuages et leurs environs - . Quelques faits marquants :
- Le principal — 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 raconté comment ils ;
- Leroy Merlin, Otkritie, Burger King et Schneider Electric ont fourni des — quelles tâches leur entreprise définit pour l'informatique et quelles technologies, y compris celles du cloud, elles considèrent comme les plus prometteuses.
Vous pouvez regarder toutes les vidéos de la conférence mailto:CLOUD , et ici vous pouvez lire comment s'est déroulée la discussion sur les microservices. Alexander Deulin, responsable du centre de recherche et développement des systèmes d'entreprise MegaFon, et Sergey Sergeev, directeur des technologies de l'information du groupe M.Video-Eldorado, ont partagé leurs cas réussis d'élimination des monolithes. Nous avons également discuté de questions connexes de stratégie informatique, de processus et même de ressources humaines.
Panélistes
- Sergey Sergeev, DSI Groupe "M.Vidéo-Eldorado";
- Alexandre Deulin, responsable du centre de recherche et de développement de systèmes d'affaires MégaFon;
- Modérateur — Dmitri Lazarenko, Responsable de la direction PaaS Solutions Cloud Mail.ru.
Après le discours d'Alexandre Deulin il est rejoint pour la discussion par Sergey Sergeev de M.Video-Eldorado et le modérateur 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 :
La transition vers les microservices est une réponse aux besoins du marché
Dmitry:
Avez-vous eu une expérience réussie de migration vers des microservices ? Et de manière générale : où voyez-vous le plus grand avantage commercial de l’utilisation des microservices ou du passage des monolithes aux microservices ?
Sergey:
Nous avons déjà parcouru un certain chemin dans la transition vers les microservices et utilisons cette approche depuis plus de trois ans. Le premier besoin qui a justifié le besoin de microservices était l’intégration sans fin de divers produits front-end avec le back-office. Et à chaque fois nous avons été obligés de faire des intégrations et des développements supplémentaires, en mettant en œuvre nos propres règles pour le fonctionnement de tel ou tel service.
À un moment donné, nous avons réalisé que nous devions accélérer le fonctionnement de nos systèmes et la production de fonctionnalités. À cette époque, des concepts tels que les microservices et l'approche microservice existaient déjà sur le marché, et nous avons décidé de les essayer. Cela a commencé en 2016. Ensuite, la plateforme 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 le service de calcul des prix. Chaque fois que vous accédez à n'importe quelle chaîne du groupe de sociétés M.Video-Eldorado, qu'il s'agisse d'un site Web ou d'un magasin de détail, que vous y sélectionnez un produit, que vous voyez le prix sur le site Web ou dans le « Panier », le coût est automatiquement calculé par un service. Pourquoi est-ce nécessaire : avant cela, chaque système avait ses propres principes pour travailler avec des promotions - avec des remises, etc. Notre back-office gère la tarification ; la fonctionnalité de réduction est implémentée dans un autre système. Il fallait que cela soit centralisé et qu'un service unique et séparable soit créé sous la forme d'un processus métier qui nous permettrait de mettre en œuvre cela. C'est à peu près comme ça que nous avons commencé.
La valeur des premiers résultats a été très grande. Premièrement, nous avons pu créer des entités séparables qui nous permettent de travailler séparément et de manière agrégée. Deuxièmement, nous avons réduit le coût de possession en termes d’intégration avec davantage 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 entretenir avec la même quantité de ressources que l’entreprise pouvait se permettre. Il s'est donc imposé de rechercher de nouveaux débouchés répondant au marché en termes de rapidité, de coûts internes et d'efficacité.
Comment mesurer le succès de la migration vers les microservices
Dmitry:
Comment est déterminé le succès de la migration vers les microservices ? Quel était « l’avant » dans chaque entreprise ? Quelle mesure avez-vous utilisée pour déterminer le succès de la transition, et qui l’a réellement déterminé ?
Sergey:
Tout d’abord, il est né au sein de l’informatique en tant que catalyseur – « déverrouillant » de nouvelles capacités. Nous devions tout faire plus rapidement pour relativement le même budget, en répondant aux défis du marché. Désormais, le succès s'exprime dans le nombre de services réutilisés par différents systèmes, l'unification des processus entre eux. C'est maintenant le cas, mais à ce moment-là, c'était l'occasion de créer une plateforme et de confirmer l'hypothèse que nous pouvons faire cela, cela donnera un effet et calculera le business case.
Alexander:
Le succès est plutôt un sentiment intérieur. Les entreprises en veulent toujours plus, et l’ampleur de notre retard est une preuve de réussite. Il me semble que oui.
Sergey:
Oui je suis d'accord. En trois ans, nous avons déjà plus de deux cents prestations et un carnet de commandes. Le besoin de ressources au sein de l'équipe ne fait qu'augmenter - de 30 % par an. Cela se produit parce que les gens ont senti : c’est plus rapide, c’est différent, il y a différentes technologies, tout cela évolue.
Les microservices viendront, mais le noyau restera
Dmitry:
C'est comme un processus sans fin dans lequel vous investissez dans le développement. La transition vers les microservices pour les entreprises est-elle déjà terminée ou non ?
Sergey:
C'est très facile de répondre. Qu'en pensez-vous : remplacer un téléphone est un processus sans fin ? Nous achetons nous-mêmes des téléphones chaque année. Et voilà : tant qu’il faudra de la rapidité, de l’adaptation au marché, certains changements seront nécessaires. Cela ne veut pas dire que nous abandonnons les choses standards.
Mais nous ne pouvons pas tout couvrir et tout refaire d’un coup. Nous disposons de services d’intégration standards et existants qui existaient auparavant : des bus d’entreprise, etc. Mais il y a un retard, mais il y a aussi un besoin. Le nombre d'applications mobiles et leurs fonctionnalités augmentent. En même temps, personne ne dit que vous recevrez 30 % d’argent en plus. Autrement dit, il y a toujours des besoins d’un côté et une recherche d’efficacité de l’autre.
Dmitry:
La vie est en bonne forme. (Des rires)
Alexander:
En général, oui. Nous n’avons pas d’approche révolutionnaire pour supprimer l’élément central 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 conserver la partie centrale, car dans le paysage des opérateurs, il y aura toujours des plates-formes que nous achèterons. Encore une fois, nous avons besoin d’un équilibre sain : nous ne devons pas nous précipiter pour supprimer le noyau. Nous plaçons les systèmes côte à côte, et il s'avère maintenant que nous maîtrisons déjà de nombreuses parties essentielles. De plus, en développant la fonctionnalité, nous créons les représentations nécessaires pour tous les canaux qui fonctionnent avec nos services de communication.
Comment vendre des microservices aux entreprises
Dmitry:
Je suis également intéressé - pour ceux qui n'ont pas encore changé de modèle, mais qui envisagent de le faire : dans quelle mesure a-t-il été facile de vendre cette idée aux entreprises et était-ce une aventure, un projet d'investissement ? Ou était-ce une stratégie consciente : maintenant nous passons aux microservices et c’est tout, rien ne nous arrêtera. Comment c'était pour vous?
Sergey:
Nous ne vendions pas une approche, mais un bénéfice business. Il y avait un problème dans les affaires et nous avons essayé de le résoudre. À cette époque, cela se traduisait par le fait que différentes chaînes utilisaient des principes différents pour calculer les prix - séparément pour les promotions, pour les promotions, etc. C'était difficile à maintenir, des erreurs se produisaient et nous écoutions les plaintes des clients. Autrement dit, nous vendions une solution à un problème, mais nous sommes arrivés au fait que nous avions besoin d’argent pour créer une plateforme. Et ils ont présenté une analyse de rentabilisation en utilisant l'exemple de la première étape de l'investissement : comment nous allons continuer à le récupérer et ce que cela nous permettra de faire.
Dmitry:
Avez-vous enregistré d'une manière ou d'une autre le temps de la première étape ?
Sergey:
Oui bien sûr. Nous avons alloué 6 mois pour créer le noyau en tant que plateforme et tester le pilote. Pendant ce temps, nous avons essayé de créer une plateforme sur laquelle patiner le pilote. Puis l’hypothèse s’est confirmée, et comme ça marche, ça veut dire qu’on peut continuer. Ils ont commencé à reproduire et à renforcer l'équipe - ils l'ont transférée dans une division distincte qui fait exactement cela.
Vient ensuite un travail systématique basé sur les besoins de l'entreprise, les opportunités, la disponibilité des ressources et tout ce qui est actuellement en préparation.
Dmitry:
D'ACCORD. Alexandre, qu'en dis-tu ?
Alexander:
Nos microservices sont nés de « l'écume de la mer » - grâce à l'économie de ressources, à certains restes sous forme de capacité de serveur et à la redistribution des forces au sein de l'équipe. Au départ, nous n'avons pas vendu ce projet aux entreprises. Il s’agissait d’un projet sur lequel nous avons tous deux recherché et développé en conséquence. Nous avons commencé début 2018 et avons simplement développé cette direction avec enthousiasme. Les ventes viennent de commencer et nous sommes en train de le faire.
Dmitry:
Arrive-t-il qu'une entreprise vous permette de faire des choses comme Google - un jour libre par semaine ? Avez-vous une telle direction ?
Alexander:
Parallèlement à la recherche, nous traitons également de problèmes métiers, tous nos microservices sont donc des solutions à des problèmes métiers. Au début seulement, nous avons créé des microservices qui couvraient une petite partie de la base d'abonnés, et nous sommes désormais présents dans presque tous les produits phares.
Et l'impact matériel est déjà clair : nous pouvons déjà être comptés, la vitesse des lancements de produits et la perte de revenus peuvent être estimées si nous avions suivi l'ancienne voie. C’est sur cela que nous bâtissons notre dossier.
Microservices : mode ou nécessité ?
Dmitry:
Les nombres sont des nombres. Et les revenus ou l’argent économisé sont très importants. Et si vous regardiez de l'autre côté ? Il semble que les microservices soient une tendance, un battage médiatique et que de nombreuses entreprises en abusent ? Dans quelle mesure faites-vous clairement la différence entre ce que vous faites et ce que vous ne traduisez pas en microservices ? Si vous héritez maintenant, en aurez-vous toujours 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 qui auront dix, quinze ans ou bien une nouvelle génération ? Comment voyez-vous cela ?
Sergey:
Il me semble qu'il est difficile de penser très loin. Si l’on regarde en arrière, qui aurait imaginé que le marché des technologies se développerait de cette manière, y compris l’apprentissage automatique et l’identification des utilisateurs par le visage ? Mais si vous regardez les années à venir, il me semble que les systèmes de base, les systèmes de classe ERP d'entreprise dans les entreprises, fonctionnent depuis assez longtemps.
Nos entreprises ont collectivement 25 ans, avec un ERP classique très ancré dans le paysage des systèmes. Il est clair que nous retirons certains éléments et essayons de les regrouper en microservices, mais le noyau restera. Il m’est difficile d’imaginer maintenant que nous remplacerons tous les systèmes de base et passerons rapidement à l’autre côté positif des nouveaux systèmes.
Je suis partisan du fait que tout ce qui est plus proche du client et du consommateur est celui où se trouvent le plus grand avantage et la plus grande valeur commerciale, où l'adaptabilité et l'accent mis sur la rapidité, sur le changement, sur « essayer, annuler, réutiliser, faire quelque chose de différent » sont nécessaire « – c’est là que le paysage va changer. Et les produits en boîte ne s’y intègrent pas très bien. Au moins, nous ne le voyons pas. Les solutions les plus simples et les plus simples y sont nécessaires.
On voit cette évolution :
- systèmes d'information de base (principalement back-office) ;
- les couches intermédiaires sous forme de microservices connectent le cœur, agrègent, créent un cache, etc. ;
- les systèmes de première ligne sont destinés au consommateur ;
- une 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 la plus légère possible, simple et contient un minimum de logique métier.
Mais en même temps, je suis partisan de continuer à utiliser les anciens principes s’ils sont utilisés de manière appropriée.
Disons que vous disposez d'un système d'entreprise classique. Il est situé dans le paysage d'un fournisseur et se compose de deux modules qui fonctionnent l'un avec l'autre. 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 un processus métier, qui est ensuite utilisé par 8 à 10 systèmes de première ligne, l'avantage est immédiatement perceptible. Vous partez de cinq systèmes de back-office et créez un service, isolé, axé sur le processus métier. Rendre le service technologiquement avancé - afin qu'il mette en cache les informations et soit tolérant aux pannes, et qu'il fonctionne également avec des documents ou des entités commerciales. Et vous l'intégrez selon un principe unique 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 devrez écrire une application mobile ou créer un petit site Web et n'en mettre qu'une partie en fonctionnalité - tout est simple : vous l'avez assemblé comme un constructeur. Je vois davantage de développement dans cette direction – du moins dans notre pays.
Alexander:
Sergey a décrit complètement notre approche, merci. Je dirai simplement où nous n'irons certainement pas - à l'essentiel, au sujet de la facturation en ligne. Autrement dit, la tarification et la tarification resteront, en fait, un « gros » batteur qui amortira de manière fiable l'argent. Et ce système continuera d'être certifié par nos autorités de régulation. Bien entendu, tout ce qui s’adresse aux clients est constitué de microservices.
Dmitry:
Ici, la certification est une histoire. Probablement plus de soutien. Si vous dépensez peu en support ou si le système ne nécessite ni support ni modification, il vaut mieux ne pas y toucher. Un compromis raisonnable.
Comment développer des microservices fiables
Dmitry:
Bien. Mais je suis toujours intéressé. Vous racontez maintenant une success story : tout s'est bien passé, nous sommes passés aux microservices, avons défendu l'idée auprès du business et tout s'est bien passé. Mais j'ai entendu d'autres histoires.
Il y a quelques années, une entreprise suisse qui avait investi deux ans dans le développement d'une nouvelle plateforme de microservices pour les banques a finalement clôturé le projet. Complètement effondré. Plusieurs millions de francs suisses ont été dépensés et l'équipe a finalement été dispersée - cela n'a pas fonctionné.
Avez-vous eu des histoires similaires ? Y a-t-il eu ou existe-t-il des difficultés ? Par exemple, la maintenance des microservices et la surveillance constituent également un casse-tête dans les activités opérationnelles de l’entreprise. Après tout, le nombre de composants est multiplié par dix. Comment le voyez-vous, y a-t-il eu des exemples d’investissements infructueux ici ? Et que pouvez-vous conseiller aux gens pour qu’ils ne rencontrent pas de tels problèmes ?
Alexander:
Parmi les exemples d’échecs figurent des entreprises qui ont modifié leurs priorités et annulé des projets. Lorsqu’elle est à un bon stade de préparation (en fait, le MVP est prêt), l’entreprise a déclaré : « Nous avons de nouvelles priorités, nous passons à un autre projet et nous clôturons celui-ci. »
Nous n’avons eu aucun échec global avec les microservices. Nous dormons paisiblement, nous avons un service 24h/7 et XNUMXj/XNUMX qui dessert l'ensemble du BSS [business support system].
Et encore une chose : nous louons des microservices selon les règles qui s'appliquent aux produits en boîte. La clé du succès est que vous devez tout d’abord constituer une équipe qui préparera pleinement le microservice pour la production. Le développement lui-même est, sous condition, de 40 %. Le reste est une question d'analyse, de méthodologie DevSecOps, de bonnes intégrations et de bonne architecture. Nous accordons une attention particulière aux principes de création d’applications sécurisées. Les représentants en sécurité de l'information participent à chaque projet à la fois au stade de la planification de l'architecture et pendant le processus de mise en œuvre. Ils gèrent également des systèmes d'analyse du code pour détecter les vulnérabilités.
Disons que nous déployons nos services sans état – nous les avons dans Kubernetes. Cela permet à tout le monde de dormir paisiblement grâce à la mise à l'échelle et à l'augmentation automatiques des services, et l'équipe de service détecte les incidents.
Dans toute l’existence de nos microservices, seuls un ou deux incidents ont atteint notre ligne. Il n'y a désormais aucun problème de fonctionnement. Nous n'avons bien sûr pas 200, mais environ 50 microservices, mais ils sont utilisés dans des 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 vers le support - sur le fait que le travail doit être organisé correctement. Mais je vais vous parler des problèmes qui existent bien sûr.
Premièrement, la technologie est nouvelle. C'est un battage médiatique dans le bon sens du terme, et trouver un spécialiste qui comprendra et pourra créer cela est un grand défi. La concurrence pour les ressources est folle, les experts valent donc leur pesant d'or.
Deuxièmement, avec la création de certains paysages et 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 maintenant... » De ce fait, le système grandit et perd de son efficacité en termes d'argent, de coût de possession, etc. Autrement dit, il est nécessaire d'inclure la réutilisation dans l'architecture du système, de l'inclure dans la feuille de route pour l'introduction des services et le transfert de l'héritage vers une nouvelle architecture.
Un autre problème - même s'il est positif à sa manière - est la concurrence interne. "Oh, de nouveaux mecs à la mode sont apparus ici, ils parlent une nouvelle langue." Bien entendu, les gens sont différents. Il y a ceux qui sont habitués à écrire en Java, et ceux qui écrivent et utilisent Docker et Kubernetes. Ce sont des personnes complètement différentes, elles parlent différemment, utilisent des termes différents et parfois ne se comprennent pas. La capacité ou l’incapacité de partager des pratiques, des connaissances, dans ce sens, constitue également un problème.
Eh bien, faire évoluer les ressources. « Super, allons-y ! Et maintenant, nous voulons plus vite, plus. Quoi, tu ne peux pas ? N'est-il pas possible de livrer deux fois plus par an ? Et pourquoi?" De telles douleurs de croissance sont probablement courantes pour de nombreuses choses, de nombreuses approches, et vous pouvez les ressentir.
Concernant le suivi. Il me semble que les services ou les outils de surveillance industrielle apprennent déjà ou sont capables de travailler à la fois avec Docker et Kubernetes dans un mode différent et non standard. Pour que, par exemple, vous ne vous retrouviez pas avec 500 machines Java sous lesquelles tout cela tourne, c'est-à-dire que cela agrège. Mais ces produits manquent encore de maturité, il faut qu'ils passent par là. Le sujet est vraiment nouveau, il va continuer à se développer.
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 des compétences différentes. Et il y a probablement des avantages et des inconvénients. Auparavant, la blockchain et la science des données étaient à la mode, et leurs spécialistes valaient des millions. Aujourd’hui, les coûts baissent, le marché devient saturé et on observe une tendance similaire dans les microservices.
Sergey:
Oui, tout à fait.
Alexander:
Les RH posent la question : « Où est ta licorne rose entre le backend et le frontend ? Les RH ne comprennent pas ce qu'est un microservice. Nous leur avons révélé le secret et leur avons dit que le backend faisait tout et qu'il n'y avait pas de licorne. Mais les RH évoluent, apprennent rapidement et recrutent des personnes possédant des connaissances de base en informatique.
L’évolution des microservices
Dmitry:
Si vous regardez l’architecture cible, les microservices ressemblent à un monstre. Votre voyage a duré plusieurs années. D'autres ont un an, d'autres trois ans. Avez-vous prévu tous les problèmes, l'architecture cible, est-ce que quelque chose a changé ? Par exemple, dans le cas des microservices, les passerelles et les maillages de services réapparaissent. Les avez-vous utilisés au début ou avez-vous modifié l’architecture elle-même ? Avez-vous de tels défis ?
Sergey:
Nous avons déjà réécrit plusieurs protocoles de communication. Au début, il y avait un protocole, maintenant nous sommes passés à un autre. Nous augmentons la sécurité et la fiabilité. Nous avons commencé avec les technologies d'entreprise - Oracle, Web Logic. Nous nous éloignons désormais des produits technologiques d’entreprise dans les microservices et passons à des technologies open source ou complètement ouvertes. Nous abandonnons les bases de données et passons à ce qui fonctionne le plus efficacement pour nous dans ce modèle. Nous n'avons plus besoin des technologies Oracle.
Nous avons commencé simplement en tant que service, sans penser à quel point nous avions besoin d'un cache, à ce que nous ferions lorsqu'il n'y avait pas de connexion avec un microservice, mais que des données étaient nécessaires, etc. Nous développons maintenant une plate-forme pour que l'architecture puisse être décrite pas dans le langage des services, mais dans le langage des affaires, faites passer la logique commerciale au niveau supérieur lorsque nous commençons à parler avec des mots. Maintenant, nous avons appris à parler en lettres, et le niveau suivant est celui où les services seront regroupés en une sorte d'agrégat, alors qu'il s'agit déjà d'un mot - par exemple, une fiche produit entière. Il est assemblé à partir de microservices, mais il s’agit d’une API construite sur cette base.
La sécurité est très importante. Dès que vous commencez à être accessible et que vous disposez d'un service grâce auquel vous pouvez obtenir beaucoup de choses intéressantes, et très rapidement, en une fraction de seconde, alors il y a une envie de l'obtenir de la manière la plus sécurisée. Pour sortir de cette situation, nous avons dû modifier nos approches en matière de tests et de surveillance. Nous avons dû changer l'équipe, la structure de gestion des livraisons, CI/CD.
Il s'agit d'une évolution - comme pour les téléphones, mais en beaucoup plus rapide : il y a d'abord eu les téléphones à bouton-poussoir, puis les smartphones sont apparus. Ils ont réécrit et repensé le produit parce que le marché avait un besoin différent. C'est comme ça qu'on évolue : CP, CEXNUMX, travail.
De manière itérative, quelque chose est prévu chaque année du point de vue de la technologie, autre chose du point de vue du retard et des besoins. Nous connectons une chose à une autre. L'équipe dépense 20 % en dette technique et en support technique pour l'équipe, 80 % pour l'entité commerciale. Et nous avançons en comprenant pourquoi nous le faisons, pourquoi nous apportons ces améliorations technologiques, à quoi elles mèneront. Comme ça.
Dmitry:
Cool. Qu'y a-t-il dans MegaFon ?
Alexander:
Le principal défi lorsque nous sommes arrivés aux microservices était de ne pas sombrer dans le chaos. Le bureau d'architecture MegaFon nous a immédiatement rejoint, est même devenu initiateur et moteur - nous disposons désormais d'une architecture très solide. Sa tâche était de comprendre vers quel modèle cible nous nous dirigeons et quelles technologies doivent être pilotées. Avec l'architecture, nous avons mené nous-mêmes ces pilotes.
La question suivante était : « Alors comment exploiter tout cela ? Et encore une : « Comment assurer une interaction transparente entre les microservices ? Service Mesh nous a aidé à répondre à la dernière question. Nous avons piloté Istio et apprécié les résultats. Nous en sommes désormais au stade du déploiement dans les zones productives. Nous avons une attitude positive face à tous les défis - le fait que nous devons constamment changer de stack, apprendre quelque chose de nouveau. Nous souhaitons développer et non exploiter des solutions anciennes.
Dmitry:
Des mots d'or ! De tels défis maintiennent l’équipe et l’entreprise sur leurs gardes et créent l’avenir. Le RGPD a créé des responsables de la protection des données, et les défis actuels créent des responsables des microservices et de l'architecture. Et ça fait plaisir.
Nous avons beaucoup discuté. L'essentiel est qu'une bonne conception des microservices et de l'architecture elle-même permet d'éviter de nombreuses erreurs. Bien sûr, le processus est itératif et évolutif, mais il s’agit de l’avenir.
Merci à tous les participants, merci à Sergei et Alexander !
Questions du public
Question du public (1) :
Sergey, comment la gestion informatique a-t-elle changé dans votre entreprise ? Je comprends que lorsqu'il existe une grande pile de plusieurs systèmes, la façon dont elle est gérée est un processus assez clair et logique. Comment avez-vous reconstruit la gestion du composant informatique après avoir intégré un très grand nombre de microservices en si peu de temps ?
Sergey:
Je suis d'accord avec mon collègue que l'architecture est un moteur de changement très important. Nous avons commencé par avoir une division d'architecture. Les architectes sont à la fois propriétaires de la répartition des fonctionnalités et des exigences relatives à leur apparition dans le paysage. Ils agissent donc également en tant que coordinateurs de ces changements. En conséquence, des changements spécifiques ont été apportés à un processus de livraison spécifique lorsque nous avons créé une plateforme CI/CD.
Mais la norme, les principes de base du développement, de l'analyse commerciale, des tests et du développement n'ont pas été annulés. Nous avons juste ajouté de la vitesse. Auparavant, le cycle prenait beaucoup de temps, l'installation sur des environnements de test en prenait beaucoup plus. Aujourd’hui, les entreprises en voient les avantages et se demandent : « Pourquoi ne pouvons-nous pas faire la même chose ailleurs ? »
C’est comme, dans le bon sens, une injection sous forme de vaccin qui montrait : vous pouvez le faire de cette façon, mais vous pouvez le faire d’une autre manière. Bien sûr, il y a un problème de personnel, de compétences, de connaissances, de résistance.
Question du public (2) :
Les critiques de l’architecture des microservices affirment que les tests et le développement sont difficiles. C'est logique là où les choses se compliquent. À quels défis votre équipe a-t-elle été confrontée et comment les avez-vous surmontés ? Question pour tout le monde.
Alexander:
Il existe des difficultés lors du passage des microservices à une plateforme, mais elles peuvent être résolues.
Par exemple, nous créons un produit composé de 5 à 7 microservices. Nous devons fournir des tests d'intégration sur l'ensemble de la pile de microservices pour donner le feu vert au passage à la branche principale. Cette tâche n'était pas nouvelle pour nous : nous le faisions depuis longtemps chez BSS, lorsque l'éditeur nous a fourni des solutions déjà livrées.
Et notre problème réside uniquement dans la petite équipe. Un ingénieur QA est nécessaire pour un produit conditionnel. Ainsi, nous livrons un produit de 5 à 7 microservices, dont 2 à 3 peuvent être développés par des tiers. Par exemple, nous avons un produit au développement duquel participent notre fournisseur de système de facturation, le groupe Mail.ru et MegaFon R&D. Nous devons couvrir cela avec des tests avant de l'envoyer en production. L'ingénieur QA travaille sur ce produit depuis un mois et demi, et le reste de l'équipe se retrouve sans son soutien.
Cette complexité est uniquement causée par la mise à l’échelle. Nous comprenons que les microservices ne peuvent pas exister en vase clos ; l’isolement absolu n’existe pas. Lors du changement d'un service, nous essayons toujours de préserver le contrat API. Si quelque chose change sous le capot, le service avant reste. Si les changements sont fatals, une sorte de transformation architecturale a lieu et nous passons à un métamodèle de données complètement différent, totalement incompatible - alors seulement nous parlons de l'apparition de la spécification de l'API de service v2. Nous prenons en charge simultanément la première et la deuxième versions, et une fois que tous les consommateurs sont passés à la deuxième version, nous fermons simplement la première.
Sergey:
Je veux ajouter. Je suis tout à fait d'accord sur les complications : elles surviennent. Le paysage devient plus complexe et les frais généraux augmentent, notamment pour les tests. Comment gérer cela : passez aux tests automatisés. Oui, vous devrez investir davantage dans l’écriture d’autotests et de tests unitaires. Pour que les développeurs ne puissent pas s'engager sans réussir le test, ils ne pouvaient pas modifier le code. Pour que même le bouton poussoir ne fonctionne pas sans autotest, test unitaire.
Il est important de conserver la fonctionnalité précédente, ce qui représente une surcharge supplémentaire. Si vous réécrivez une technologie dans un autre protocole, vous la réécrivez jusqu'à ce que vous fermiez tout complètement.
Parfois, nous ne faisons pas exprès de tester de bout en bout, car nous ne voulons pas arrêter le développement, même si nous avons aussi une chose après l'autre. Le paysage est très vaste, complexe, il existe de nombreux systèmes. Parfois, ce ne sont que des talons - oui, vous réduisez la marge de sécurité, plus de risques apparaissent. Mais en même temps, vous libérez l’offre.
Alexander:
Oui, les autotests et tests unitaires permettent de créer un service de haute qualité. Nous sommes pour un pipeline qui ne peut être réussi sans tests unitaires et d'intégration. Nous devons souvent déplacer des émulateurs et des systèmes commerciaux vers des zones de test et des environnements de développement, car tous les systèmes ne peuvent pas être placés dans des zones de test. De plus, ils ne se contentent pas d'être mouillés : nous générons une réponse à part entière du système. Il s’agit d’un aspect important du travail avec les microservices, et nous y investissons également. Sans cela, le chaos s’ensuivra.
Question du public (3) :
D'après ce que je comprends, les microservices sont initialement nés d'une équipe distincte et existent désormais dans ce modèle. Quels sont ses avantages et ses inconvénients ?
Nous avons juste une histoire similaire : une sorte d’usine de microservices est née. Nous avons maintenant conceptuellement atteint le point où nous étendons cette approche de la production à tous les flux et à tous les systèmes. En d’autres termes, nous nous éloignons du développement centralisé de microservices, de modèles de microservices, et nous rapprochons des systèmes.
En conséquence, notre action s'étend également aux systèmes, c'est-à-dire que nous décentralisons ce sujet. Quelle est votre approche et quelle est votre histoire cible ?
Alexander:
Vous avez laissé tomber le nom « usine de microservices » de votre bouche : nous voulons également évoluer. Premièrement, nous n’avons vraiment qu’une seule équipe maintenant. Nous souhaitons offrir à toutes les équipes de développement de MegaFon la possibilité de travailler dans un écosystème commun. Nous ne voulons pas reprendre complètement toutes les fonctionnalités de développement dont nous disposons actuellement. La tâche locale est d'évoluer, la tâche globale est de diriger le développement vers toutes les équipes de la couche microservice.
Sergey:
Je vais vous raconter le chemin que nous avons emprunté. Nous avons vraiment commencé à travailler comme une seule équipe, mais maintenant nous ne sommes plus seuls. Je suis partisan de ce qui suit : il doit y avoir un propriétaire du processus. Quelqu'un doit comprendre, gérer, contrôler et construire le processus de développement des microservices. Il doit posséder des ressources et s'engager dans la gestion des ressources.
Ces ressources, qui connaissent les technologies, les spécificités et comprennent comment créer des microservices, peuvent être situées dans des équipes produit. Nous avons un mélange où des personnes de la plate-forme de microservices font partie de l'équipe produit qui crée l'application mobile. Ils sont là, mais ils travaillent selon le processus du service de gestion de la plateforme de microservices avec leur responsable de développement. Au sein de cette division, il existe une équipe distincte qui s'occupe de la technologie. Autrement dit, nous mélangeons un pool commun de ressources entre nous et les divisons, en les donnant aux équipes.
En même temps, le processus reste général, contrôlé, il se déroule selon des principes technologiques généraux, avec des tests unitaires, etc. - tout ce qui est construit par-dessus. Il peut y avoir des colonnes sous forme de ressources collectées auprès des différents départements de l'approche produit.
Alexander:
Sergey, vous êtes en fait le propriétaire du processus, n'est-ce pas ? Le backlog des tâches est-il partagé ? Qui est responsable de sa distribution ?
Sergey:
Regardez : voici à nouveau le mix. Il y a un retard qui se forme sur la base des améliorations technologiques - c'est une histoire. Il y a un retard, qui est formulé à partir des projets, et il y a un retard dans les produits. Mais la séquence d'introduction dans chacun des produits de service ou de création de ce service est élaborée par un spécialiste produit. Il ne fait pas partie de la direction informatique, il en a été spécialement démis. Mais mes collaborateurs travaillent définitivement selon le même processus.
Le propriétaire de l'arriéré dans différentes directions - l'arriéré de changements - sera constitué de différentes personnes. La connexion des services technologiques, leur principe d'organisation, tout cela sera dans l'informatique. Je possède également la plateforme et les ressources. Au sommet se trouvent ce qui concerne le backlog et les changements fonctionnels, et l'architecture dans ce sens.
Disons qu'une entreprise dit : "Nous voulons cette fonction, nous voulons créer un nouveau produit - refaire un prêt." Nous répondons : « Oui, nous allons le refaire. » Les architectes disent : « Réfléchissons : où dans le prêt allons-nous écrire des microservices et comment allons-nous le faire ? » Ensuite, nous le décomposons en projets, produits ou pile technologique, le répartissons en équipes et le mettons en œuvre. Avez-vous créé un produit en interne et décidé d'utiliser des microservices dans ce produit ? Nous disons : « Maintenant, les systèmes existants dont nous disposions, ou les systèmes de première ligne, doivent passer à ces microservices. » Les architectes disent : « Donc : dans le retard technologique au sein des produits de première ligne - la transition vers les microservices. Aller". Et les spécialistes produits ou les propriétaires d’entreprise comprennent quelle quantité de capacité est allouée, quand cela sera fait et pourquoi.
La fin de la discussion, mais pas tout
La conférence mailto:CLOUD a été organisée .
Nous organisons également d'autres événements - par ex. Rencontre @Kubernetes, où nous recherchons toujours de bons conférenciers :
- Suivez @Kubernetes et d'autres actualités @Meetup sur notre chaîne Telegram
- Vous souhaitez prendre la parole lors de l’un des @Meetups ? Laissez une demande pour
Source: habr.com