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

А поскольку существенная сложность не зависит от действий проектировщика (это то, что должна смоделировать система, т.е. она объективно существует в предметной области), то есть только один способ с ней работать - это инкрементальное рассмотрение сложности. Т.е. способность рассмотреть фрагмент сложности изолированно. Именно это в наибольшей степени влияет на расход токенов.

Достигается это качественным выделением моделей (границей которых является Bounded Context). Когда модель сфокусирована на одной решаемой проблеме, она дистиллируется от паразитной сложности. И изменения системы, касающиеся этой решаемой проблемы, становится возможным изолировать в границах самой модели (не всегда, конечно, но эти исключения становятся редкими). Отсюда и пошло правило, что единицей обязанности команды разработки является модель.

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

С другой стороны, при качественных моделях микросервисы делают более дорогим сам процесс расползания границ моделей. Невозможность в сделать join во write (domain) model микросервиса защищает модель от расползания.

Независимо от того, как деплоятся компоненты системы, монолитно или независимо (микросервисы), всё упирается в качество моделей.