🍥 👨🏽‍🎓 ⚠️ Hidden costs of switching to microservices 👨🏼‍⚕️ 🙋🏾 😟

In an ideal world, you could just take the source code of a monolith, split its code between microservices and, by connecting them together, get the same system, but on a new architecture. This never happens in life. Life brings a lot of complexity to this perfect picture. What are the specific challenges that can double or triple your microservices migration budget?

I will describe the factors that are delaying the transition to microservices and making it much more expensive than initially expected. You will receive a checklist for assessing these factors and will be more realistic in calculating the transition budget.

I spoke with this topic at ArchDays 2020 . Follow the link to find slides and videos (to be published soon) of the speech https://blog.byndyu.ru/2020/12/archdays-2020.html .

# 1 Changing the approach to working with master data

A monolith usually has one or two large databases containing variegated master data. The monolith itself contains code that manages this master data. For example, if the "green" part of the database is an address directory, then the "green" monolith code controls the addresses. It turns out that there are many master data in the monolith database, and there are many master systems in the monolith code:

In microservices, master data is managed differently: there are many databases, you cannot mix master data between microservices, and only one microservice can manage master data. For example, the "green" microservice has now received its own database with addresses and only he can make changes to this master data. Other microservices can read data with addresses, but only through the "green" microservice: