🧘 ↪️ 👰 Coûts cachés du passage aux microservices 🖕🏻 📡 🧑🏾‍🤝‍🧑🏽

Dans un monde idéal, on pourrait simplement prendre le code source d'un monolithe, diviser son code entre des microservices et, en les connectant entre eux, obtenir le même système, mais sur une nouvelle architecture. Cela n'arrive jamais dans la vie. La vie apporte beaucoup de complexité à cette image parfaite. Quels sont les défis spécifiques qui peuvent doubler ou tripler votre budget de migration de microservices?

Je décrirai les facteurs qui retardent la transition vers les microservices et la rendent beaucoup plus chère que prévu initialement. Vous recevrez une liste de contrôle pour évaluer ces facteurs et serez plus réaliste quant à votre budget de transition.

J'ai parlé de ce sujet à ArchDays 2020 . Suivez le lien pour trouver des diapositives et des vidéos (à paraître prochainement) du discours https://blog.byndyu.ru/2020/12/archdays-2020.html .

# 1 Changer l'approche du travail avec les données de base

Un monolithe a généralement une ou deux grandes bases de données contenant des données de base variées. Le monolithe lui-même contient du code qui gère ces données de base. Par exemple, si la partie "verte" de la base de données est un répertoire d'adresses, alors le code monolithe "vert" contrôle les adresses. Il s'avère qu'il existe de nombreuses données de base dans la base de données monolithique, et dans le code monolithique, il existe de nombreux systèmes maîtres:

Dans les microservices, la gestion des données de base est différente: il existe de nombreuses bases de données, vous ne pouvez pas mélanger les données de base entre les microservices et un seul microservice peut gérer les données de base. Par exemple, le microservice «vert» a maintenant reçu sa propre base de données avec des adresses et lui seul peut apporter des modifications à ces données de base. D'autres microservices peuvent lire des données avec des adresses, mais uniquement via le microservice "vert":