Вижу растущий тренд критики микросервисов. Лет 10 назад на конференциях люди делились опытом распиливания монолитов и подходом к правильному управлению микросервисами. Потом был период, когда разрабы приняли микросервисы как лучшую практику и перестали думать о других подходах. Это сказалось и на докладах — учить готовить микросервисы перестали, но стали говорить о том, как они успешно живут со своим монолитом. Теперь, когда спираль завершает половину витка, люди снова говорят, что микросервисы — вообще говоря ошибка, или тех долг, как в приложенном коротком интервью.

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

В том же AWS код деплоят волнами и постоянно тестируют на отклонения: 1) Один сервер в одной зоне 2) один сервер в одной зоне каждого региона, 3) все зоны одного региона и так далее. В итоге один релиз может катиться день. В таком случае, если команд много, то своей очереди можно ждать очень долго. Микросервис у каждой команды свой (а то и десяточек микросервисов), поэтому есть определенная независимость.

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

Когда людей сократили и микросервисы сбросили на оставшиеся команды. Оказалось, что разрешать всем писать на любом языке — было не очень дальновидное решение. Да, даже на том же самом языке — устанешь зависимости обновлять в случае CVE.

Самое смешное, что фичи в итоге катить еще сложнее и дольше. Потому что теперь нужно сделать изменения в 3х сервисах, выкатить их под флагами в определенном порядке, а потом почистить временный код (нет, временный код конечно никто не чистит). А уж сколько созвончиков для алаймента трех команд это требует + текникал програм менеджера.

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

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

Почему я говорю, что это только половина спирали? Потому что полный виток — когда мы снова начнем себя убеждать в правильности микросервисов, но это будет в следующую золотую декаду. А пока сдувай пыль с Django, мы пишем монолитики.

https://www.youtube.com/watch?v=LcJKxPXYudE

@seniorsoftwarevlogger | закрытый чат