BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. M>Да, микросервисы делать сложнее по многим причинам. В какой-то книжке это прекрасно сформулированно было: если ваши разработчики не могут нормально сделать модульность в рамках одного монолита, то почему вы решили, что они смогут сделать нормальную модульность в рамках распределенной системы? Именно в дизайне модулей, разбиении на компоненты и начинаются проблемы. Всякие там зацепление и связность (coupling & cohesion). Почему-то не любят разработчики эти понятия. Разбивают систему на куски чисто механически. А в распределенной системе этот бардак становится заметен очень рано.
Так всетаки микросервисы проще монолитов или сложнее? Я везде вижу один аргумент в пользу микросервисов, что они проще и масштабировать их легче. А вы пишите что нет.
BE>>В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
M>Так а это две стороны одной и той же медали. В микросервисах вам нужно согласовывать API между компонентами. В одной базе — согласовывать форматы данных хранения. Вот представьте, что моя команда сделала рефакторинг и переколбасила с десяток таблиц. Ваши sql запросы по вытаскиванию данных придется пересматривать. При определенной зрелости команды меньше согласований именно в микросервисах. Одна команда выкатила обратно-совместимый API (новые поля, новые content type, в крайнем случае — новые /api/vX). Затем туда переползают все пользователи сервиса, старый API отключается. Иногда так сделать нельзя, но очень часто все-же можно. Только это нужно уметь, а это задача вроде сложнее сортировки гномиков.
При использовании правильных средств в монолитном приложении запросы проверяются при компиляции.
