Вижу растущий тренд критики микросервисов. Лет 10 назад на конференциях люди делились опытом распиливания монолитов и подходом к правильному управлению микросервисами. Потом был период, когда разрабы приняли микросервисы как лучшую практику и перестали думать о других подходах. Это сказалось и на докладах — учить готовить микросервисы перестали, но стали говорить о том, как они успешно живут со своим монолитом. Теперь, когда спираль завершает половину витка, люди снова говорят, что микросервисы — вообще говоря ошибка, или тех долг, как в приложенном коротком интервью.
Действительно, микросервисы никогда не помогали справиться с большей нагрузкой напрямую. Микросервисы — инструмент масштабирования команды, а не кода. Как правильно замечает Мэтт: обычно микросервисы возникают как решение проблемы деплоя, а вовсе даже не общего владения большой кодовой базой.
В том же AWS код деплоят волнами и постоянно тестируют на отклонения: 1) Один сервер в одной зоне 2) один сервер в одной зоне каждого региона, 3) все зоны одного региона и так далее. В итоге один релиз может катиться день. В таком случае, если команд много, то своей очереди можно ждать очень долго. Микросервис у каждой команды свой (а то и десяточек микросервисов), поэтому есть определенная независимость.
Получается, что в эпоху больших команд и бешеного потока изменений кода. Теперь, когда большие команды выброшены на мороз, а от фич требуется не количество, а окупаемость, программисты задумались, а не фигню ли они делают с микросервисами?
Когда людей сократили и микросервисы сбросили на оставшиеся команды. Оказалось, что разрешать всем писать на любом языке — было не очень дальновидное решение. Да, даже на том же самом языке — устанешь зависимости обновлять в случае CVE.
Самое смешное, что фичи в итоге катить еще сложнее и дольше. Потому что теперь нужно сделать изменения в 3х сервисах, выкатить их под флагами в определенном порядке, а потом почистить временный код (нет, временный код конечно никто не чистит). А уж сколько созвончиков для алаймента трех команд это требует + текникал програм менеджера.
В итоге этот временный мусор и флаги накапливаются загаживая идею чистой микрушки, которая должна делать одну вещь.
Посмотрев на это, люди начинают группировать сервисы сперва по базе данных, потом размещать их в одном контейнере, потом валят в микро-моно-репозитории, чтобы хоть как-то сократить число пайплайнов и пулреквестов для относительно простых изменений.
Почему я говорю, что это только половина спирали? Потому что полный виток — когда мы снова начнем себя убеждать в правильности микросервисов, но это будет в следующую золотую декаду. А пока сдувай пыль с Django, мы пишем монолитики.
https://www.youtube.com/watch?v=LcJKxPXYudE
@seniorsoftwarevlogger | закрытый чат