Распределённый монолит

В прошлой статье о стоимостях разработки я рассказал про Change, но все же не могу здесь не рассмотреть одну тему, которая ярко подсвечивает один из антипаттернов, который взвинчивает стоимость изменений в потолок.

Как я сказал раньше, монолит - это нормальная архитектура для решения достаточно широкого спектра задач. 
Но есть особый случай, в котором цена Change улетает в космос. Называется распределённый монолит.

С точки зрения системы это выглядит так: "Мы распределили системы по репозиториям, контрибьютим командами. Но между ними есть одна общая база. Да, а еще вот тут часть логики осталась". Фактор связанности настолько высок в такой системе, что при декларируемом разделении на компоненты, ни один из них нельзя выкатить отдельно от других.

Итак, признак у подозреваемого яркий: чтобы зарелизить фичу, нужно согласовать релиз трёх сервисов. Меняешь контракт в одном, два соседних падают. Деплоить приходится в строгом порядке, по цепочке, с созвоном "кто за кем катится".

Почему это хуже обычного монолита.

Обычный монолит вполне работает. Всё в одном месте, один деплой, и все это знают. Да, связность (coupling) высокая - но она вся внутри, видна компилятору, ловится тестами, рефакторится средствами IDE. Если при разработке ломается контракт, то об этом можно узнать при сборке, а не при выкатке в прод. А вот распределённый монолит берёт ту же связность и растаскивает её. Теперь связи между подсистемами - это сетевые вызовы и очереди. Компилятор их не видит напрямую, а тесты на них писать дороже. Как следствие, отслеживаемость этого добра быстро падает, покрытие портится. На выходе имеем как раз тот самый сломанный контракт, который всплывает в лучшем случае при релизе, а в худшем - ночью в проде, у дежурного из поста про Run.

Откуда же берётся этот тип систем? Да ровно из той же логики "потом разрулим". Команда вроде бы и видит, что надо начинать преобразовывать архитектуру. И даже начинает это делать, но по итогу не справляется с давлением бизнеса и проблем, не отстаивает свою долю ресурса. И система остаётся в состоянии недостроя. Дальше никто не думает, где провести границу, по каким данным разрезать подсистемы. Какой там bounded context? Тут порядок выкатки бы запомнить. И все потому, что на проработку забили ради скорости Build.

Я не говорю о том, что обязательно надо прийти к микросервисам. Уверяю, можно жить и с модульным монолитом, и с разделением монолита на сервисы (не путайте, пожалуйста, с микросервисами) и еще много как. Но делать это надо, аккуратно подумав на тему границ разделения подсистем.

#разработка #процессы #архитектура #ценаразработки