Антипаттерн миграции слонов

Встретил это замечательное определение в книге “Software architecture: the hard parts”. Антипаттерн описывает один из самых популярных, понятных, очевидных и неправильных подходов к распиливанию монолита - “мигрировать слона по кусочкам”.

Сама по себе идея - замечательная. Вот у нас есть большая штука, её нужно как-то переделать. Значит, нужно съесть этого слона по кусочкам! В случае обычных проектов в жизни этот подход работает прекрасно (сам проверял). Но в случае распиливания монолита на сервисы этот слоник способен легко вызвать несварение. При всей простоте, у подхода есть куча минусов и побочных эффектов.

Главный на мой взгляд минус - это игнорирование общей системы в пользу частного куска. Часто какая-то функциональная часть сервиса так и просится быть выделенной в отдельный микросервис. Команда увлечённо начинает этим заниматься (и даже, возможно, завершает этот процесс). Но на выходе оказывается, что полученный сервис превратил наш монолит в распределённый монолит со всем ворохом сопутствующих проблем. К сервису идёт куча сетевых обращений, появились распределённые транзакции или ещё неизвестно что.

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

В итоге такое распиливание “слона по кусочкам” частенько приводит к появлению на проекте архитектурного долга и проблем с надёжностью. И заканчивается это всё тем, что я на практике делал чуть ли не на каждом месте работы - заливанием микросервисов назад в монолит. Грустно, не так ли? В одном из самых неприятных сценариев мы полгода (полгода, Карл!) выносили микросервис - писали код, мигрировали данные, настраивали взаимодействие. А затем торжественно похоронили его и еще несколько месяцев заливали назад в монолит.

И ладно, когда дело ограничивается одним сервисом. Некоторые команды умудряются распилить ВЕСЬ монолит на микросервисы в таком подходе. В итоге код становится проще, а вся сложность монолита уезжает на уровень взаимодействий между микросервисами. Надёжность системы помахала ручкой и вышла из чата.

Именно поэтому так важно изучать то же DDD и выносить микросервисы, основываясь на домене. Это тоже не панацея, но вероятность сливания микросервиса назад в монолит всё-таки становится пониже.

Есть ещё одна отличная практика. В следующий раз, когда у вас или кого-то из команды зачешутся руки что-то вынести в микросервис, можно задать очень отрезвляющий вопрос: “А, собственно, нахрена?”