🎒 🤙🏻 🐪 Versteckte Kosten für den Wechsel zu Microservices 👸🏿 😧 💆

In einer idealen Welt könnten Sie einfach den Quellcode eines Monolithen nehmen, seinen Code auf Microservices aufteilen und durch Verbinden dasselbe System erhalten, jedoch auf einer neuen Architektur. Das passiert im Leben nie. Das Leben bringt viel Komplexität in dieses perfekte Bild. Welche spezifischen Herausforderungen können Ihr Migrationsbudget für Microservices verdoppeln oder verdreifachen?

Ich werde die Faktoren beschreiben, die den Übergang zu Microservices verzögern und ihn viel teurer machen als ursprünglich erwartet. Sie erhalten eine Checkliste zur Bewertung dieser Faktoren und können das Übergangsbudget realistischer berechnen.

Ich habe bei ArchDays 2020 mit diesem Thema gesprochen . Folgen Sie dem Link, um Folien und Videos (die in Kürze veröffentlicht werden) der Rede https://blog.byndyu.ru/2020/12/archdays-2020.html zu finden .

# 1 Ändern des Ansatzes zum Arbeiten mit Stammdaten

Ein Monolith verfügt normalerweise über eine oder zwei große Datenbanken mit unterschiedlichen Stammdaten. Der Monolith selbst enthält Code, der diese Stammdaten verwaltet. Wenn der "grüne" Teil der Datenbank beispielsweise ein Adressverzeichnis ist, steuert der "grüne" Monolithcode die Adressen. Es stellt sich heraus, dass die Monolith-Datenbank viele Stammdaten enthält, und im Monolith-Code gibt es viele Master-Systeme:

In Microservices unterscheidet sich die Stammdatenverwaltung: Es gibt viele Datenbanken, Sie können keine Stammdaten zwischen Microservices mischen, und nur ein Microservice kann Stammdaten verwalten. Beispielsweise hat der "grüne" Mikrodienst jetzt eine eigene Datenbank mit Adressen erhalten, und nur er kann Änderungen an diesen Stammdaten vornehmen. Andere Microservices können Daten mit Adressen lesen, jedoch nur über den "grünen" Microservice: