Au lieu d'introduire
Plusieurs mois se sont écoulés depuis le lancement des premiers microservices. Et maintenant, à notre avis, il est temps de parler de l'expérience acquise.
Il vaut la peine de faire immédiatement une réservation sur ce qui sera dans cet article et ce qui ne sera pas dans l'article. L'article ne décrira pas les solutions architecturales et les descriptions avec la justification de ces décisions. Nous ne nous concentrerons pas non plus sur la pile technologique sur laquelle nous avons construit des microservices.
L'objectif principal de l'article sera sur les problèmes mondiaux auxquels notre équipe a été confrontée tout au long du projet.
Cet article sera le premier d'une longue série. Et son objectif, tout d'abord, est d'introduire dans nos problématiques dans le cadre de la transition vers une architecture de microservice et de déboucher en douceur sur les sujets suivants qui révèlent en détail certains aspects de la transition.
Comment tout a commencé
La décision de passer à une architecture de microservices a été prise il y a environ un an et demi. Notre défi était de préparer la croissance rapide de notre entreprise. Nous devions devenir plus flexibles en termes de solutions techniques, augmenter la rapidité des changements et, bien sûr, augmenter la résilience de nos systèmes.
Une fois la décision prise de passer à une architecture de microservices, une unité distincte a été créée par des personnes expérimentées et proactives. Le facteur déterminant pour considérer un candidat pour un transfert dans un nouveau service était une grande expertise dans un ou plusieurs systèmes d'information existants.
Comme il n'y avait pas de compréhension claire du front de travail à ce moment-là, l'équipe a été formée assez spontanément. Mais en même temps, le principe d'autosuffisance était déjà posé à l'époque - les développeurs, les analystes et les testeurs de l'équipe devraient avoir le leur.
Deux chemins ont été choisis à la fois comme stratégie de passage aux microservices:
- nous prenons dans des microservices ce qui (comme nous le pensions) est le plus facile à retirer;
- Nous apportons dans les microservices celui dont le transfert vers les microservices résout le plus de problèmes pour les entreprises et les TI.
La première méthode était bonne car dans le processus, l'équipe acquerrait l'expertise nécessaire et se remplirait la main, augmentant ainsi son efficacité pour les travaux ultérieurs. La deuxième voie consistait à offrir une sorte de victoire rapide à l'équipe, montrant la justesse de la décision choisie de passer aux microservices pour l'entreprise et motivant l'équipe pour de nouveaux exploits.
L'équipe était au début du voyage. C'était une période heureuse: l'avenir paraissait brillant et sans nuages, et il nous semblait que nous avions un plan.
Premières difficultés
Et, bien sûr, puisque nous parlons de microservices, nous ne pouvons pas nous empêcher de parler de monolithes. Ce sont nos principaux systèmes d'information.
L'architecture de nos systèmes individuels est mieux illustrée par cette image tirée de l'article de Stefan Tilkov "Ne commencez pas par un monolithe". Comme nous pouvons le voir, les blocs fonctionnels du monolithe sont extrêmement étroitement liés les uns aux autres. Il s'agit d'un obstacle sérieux au processus de transfert de fonctionnalités distinctes vers un microservice.
Pour référence, nos monolithes ont environ 13 ans et la base de code moyenne d'un monolithe est d'environ 1,2 million de lignes.
En d'autres termes, l'équipe a été confrontée à maintes reprises aux problèmes suivants:
- processus extrêmement long d’analyse de la fonctionnalité existante;
- souvent un manque de compréhension de ce que nous apportons exactement dans le microservice;
- la complexité de l'intégration du monolithe avec le nouveau microservice.
Considérant qu'en plus de résoudre ces problèmes, l'équipe avait également besoin d'augmenter l'expertise dans une nouvelle pile et une nouvelle approche de conception, les progrès n'ont pas été très rapides.
Néanmoins, après quelques mois, l'équipe a commencé à montrer les premiers résultats - les premiers microservices ont amicalement fourni leurs API à tout le monde. L'équipe croyait en elle-même et savait avec certitude qu'elle faisait tout correctement. Eh bien, beaucoup de choses dans notre vie sont assez illusoires.
Premiers succès et nouvelles difficultés
Malgré les premières difficultés, l'équipe a reçu à la fois une nouvelle expérience et des premiers résultats. Mais certains risques non comptabilisés sont apparus, empêchant le lancement de microservices.
- Il s'est avéré que les monolithes n'étaient pas prêts à fonctionner avec la nouvelle pile, et l'intégration a été retardée.
- - .
- , , , , .
Les deux premiers problèmes ont été résolus assez simplement - en écrivant des clients séparés pour intégrer le monolithe et le microservice et en ajustant la fonctionnalité du monolithe en conséquence. Mais le troisième problème n'a pas été entièrement résolu à ce jour.
L'incohérence des ressources a été partiellement résolue grâce à la planification collaborative des ressources. Il semble que l'équipe a pris en compte toutes ses erreurs, il y avait une compréhension de ce qu'il faut faire et comment faire correctement, et au début de 2020, une douzaine de microservices ont été écrits (certains se sont avérés ne pas être des micro-services du tout) en attente d'intégration et de mise en production. Ils ont couvert leurs fonctionnalités. la plupart des processus critiques pour l'entreprise, tels que le calcul du coût et du délai de livraison, la conclusion de nouvelles régions et bureaux sur le site de vente, la recherche et la sélection de produits, etc.
Nous avons avancé avec confiance, ayant déjà une solide expérience et ayant comblé de nombreuses bosses. Il semblait que nous étions confrontés à tous les écueils, et maintenant il ne reste plus que délibérément, étape par étape, à mettre en œuvre notre plan.
Bien…
Quarantaine, exploits de main-d'œuvre et enfin succès
Le début de l'année a apporté des ajustements importants à nos plans, et cela est dû aux conséquences du nouveau coronavirus qui s'est propagé à ce moment-là. Evidemment, nul besoin d'expliquer les enjeux: tout le monde en sait déjà beaucoup sur ce sujet.
Le déclenchement de la pandémie et la crise économique qui l'accompagne ont contraint notre entreprise à reconsidérer légèrement ses priorités de développement. Et en conséquence, les priorités informatiques ont changé: de nouvelles tâches ont été définies, conçues pour remanier rapidement les processus métier pour les adapter aux nouvelles réalités.
Les changements ont également affecté les plans de microservices. En raison de la réaffectation des ressources, l'intégration des microservices avec les monolithes et, par conséquent, la publication des microservices eux-mêmes ont de nouveau été reportées.
Ici, enfin, il faut s'attarder plus en détail sur ce qui se passait dans l'équipe et comment l'équipe se sentait.
Premièrement, la démotivation. En raison de l'absence d'un résultat solide pendant longtemps, et il n'y avait pas de microservices complètement prêts à l'emploi et intégrés en production pendant près d'un an, l'équipe était très moralement épuisée (contre ce terme, mais néanmoins). L'efficacité a considérablement diminué. Non sans des pannes émotionnelles rares mais vives.
Deuxièmement, la quarantaine et une transition complète vers le contrôle à distance. Bien entendu, nous avons une riche expérience du travail à distance: près des ⅔ des développeurs sont des travailleurs à distance. Mais tous ceux qui ont travaillé sur des microservices ont travaillé ensemble dans le même bureau, et la transition vers le travail à distance n'a pas affecté au mieux l'efficacité de l'équipe. D'une part, le fait qu'il a fallu du temps pour restructurer et passer à un nouveau format de travail. D'un autre côté, c'est pendant la période de diminution de la motivation de l'équipe qu'une communication plus personnelle et un soutien mutuel au sein de l'équipe étaient nécessaires.
Troisièmement, l'équipe devait montrer le résultat. En effet, toute l'équipe, malgré les problèmes internes et externes, a clairement compris: le sort futur de toute l'entreprise dépend de la rapidité avec laquelle nous pouvons pousser nos objectifs vers un résultat solide. De nombreux membres de notre entreprise étaient prêts à admettre que le passage aux microservices était inopportun, infructueux et à dissoudre le département.
Pendant près de deux mois, l'équipe a travaillé 12 à 15 heures, souvent sept jours par semaine. Et elle a pu atteindre l'objectif souhaité - quatre microservices, entièrement fonctionnels et entièrement intégrés aux systèmes monolithiques, sont entrés en pleine production en même temps.
Il est important de noter que nous n'avons utilisé aucune technique délicate pour motiver l'équipe, il n'y a pas de savoir-faire à partager. C'est juste que jour après jour, l'équipe a fait ce qui suit:
- appels Skype fréquents avec mise à jour de l'état actuel du travail et résolution rapide des problèmes émergents;
- maintenir une attitude positive dans l'équipe avec un contrôle constant de l'état des ressources de chacun.
Par conséquent
Au lieu d'une conclusion, je voudrais m'arrêter sur les conclusions que nous nous sommes tirées ...
- Équipes croisées. Pour réussir à mettre en œuvre des projets aussi ambitieux, il faut une équipe entièrement dédiée et autonome avec des ressources suffisantes pour résoudre tout problème. Dans notre cas, cela signifie que l'équipe qui crée des microservices sur une nouvelle pile devrait avoir des membres des équipes de développement monolithes. Si nous avions compris cela plus tôt et pu pousser cette idée jusqu'au bout, cela nous aurait permis d'éviter des erreurs liées à une expertise insuffisante dans les processus métier et à une incohérence des ressources pour intégrer microservice et monolith
- . , , . . , , , , . .
- . , . .
Maintenant, après avoir fait le travail sur les erreurs, nous pouvons dire avec confiance: l'expérience, qui a commencé il y a près d'un an et demi, peut être considérée comme réussie. Et maintenant, de la catégorie de la simple expérimentation, le projet de transition vers une architecture de microservices devient l'une des stratégies informatiques clés de notre entreprise.
À l'avenir, nous reviendrons sur ce sujet et parlerons plus en détail de la pile technologique, des solutions individuelles et bien plus encore. Nous avons accumulé suffisamment de matériel et d'expérience.