Почему микросервисы нецелесообразны для стартапа
Что проверяют
Способны ли вы обосновать архитектурное решение через стадию продукта и цену владения, а не через моду. Ждут понимания, что дорого не поднять сервисы, а жить с ними в маленькой команде.
Как отвечать
Главный довод в неопределённости. У стартапа предметная область меняется каждый месяц, границы будущих сервисов ещё не нащупаны, а микросервисы фиксируют эти границы в самом дорогом для изменения месте, в сети. Передвинуть метод между пакетами это минуты, передвинуть его между сервисами это новый контракт, версионирование, миграция данных и согласованный релиз двух команд.
Дальше перечисляем счёт, который приходит сразу: оркестрация и выкладка, обнаружение сервисов, сквозная трассировка и централизованные логи, дежурства и алерты на каждый сервис, локальный запуск целой связки, контрактные тесты вместо интеграционных в одном процессе. Отдельной строкой идёт согласованность: в монолите на Spring это одна транзакция, в распределённой системе сага, компенсирующие операции и идемпотентные обработчики.
Рабочая альтернатива называется модульный монолит. Одно развёртывание, но внутри жёсткие границы: модуль на предметную область, доступ только через явный интерфейс, своя схема в базе, запрет на чужие таблицы и на циклические зависимости пакетов. Такой код выделяется в сервис за дни, когда появится настоящая причина.
Причины бывают: отдельный профиль железа, жёсткая изоляция чувствительных данных, кусок на другом стеке, отдельная команда со своим релизным циклом. Полезно сказать, что решение зависит от числа команд, а не от числа разработчиков.
Где спотыкаются
Отвечают лозунгом, что микросервисы для стартапа всегда плохо. Интервьюер ждёт критерий, а не догму, и следующий вопрос будет про то, когда всё-таки стоит.
Перечисляют только инфраструктуру и забывают про транзакции. Именно распределённая согласованность съедает время команды, а не установка оркестратора.
Обещают распилить потом, но пишут монолит без границ: общие сущности, доступ в чужие таблицы, всё видно всем. Распиливать такой код дороже, чем переписать, поэтому модульность нужна с первого дня, а сеть между модулями не нужна.