Микросервисы — это не всегда хорошо и не нужно их применять бездумно. Меня бомбит от того, что все хотят себе микросервисы. Не понимают зачем, но хотят. Даже в компаниях из двух человек многие разработчики хотят втянуть раздробить свой продукт на десяток микросервисов. Не надо.
Микросервисы — это плохо, и вот почему
Микросервисы затрудняют разработку
Это всегда источник геморроя. Ну серьёзно, помимо функциональности сервиса, нам приходится разрабатывать протоколы общения микросервисов, а составить хороший протокол — это отдельная сложная задача. Потом этот протокол ещё и нужно поддерживать. А это сложно и дорого. А ещё вам придётся на каждый чих делать отдельный сервис, регулярно обновлять в нём библиотеки, иначе он перестанет развиваться и превратится в легаси.
Если у нас совсем новый продукт, который ещё не прошёл проверку временем, и мы собираемся выпустить MVP, просто нет никакого смысла городить микросервисную архитектуру, берём готовый фреймворк, делаем монолит и проверяем идею — взлетела или нет. А уже потом думаем, переписывать на микросервисы или нет.
Микросервисы требовательны к инфраструктуре
Когда у нас монолит, мы просто можем вызвать функцию и тут же получить результат. На вызов функции накладных расходов нет. А с микросервисами — мы должны отправить запрос, принять его, распарсить. Это лишние накладные расходы на сеть, память и CPU. А накладные расходы — это лишняя трата денег.
Микросервисы затрудняют развёртывание
Вот представьте себе, вам нужно выкатить на продакшен какую-то новую фичу. Окей, вы готовите репозиторий, собираете контейнеры (у вас ведь Docker, правда?). И наступает время деплоя. И тут, вам придётся аккуратно последовательно отключать все ваши микросервисы и накатывать новые версии. Процесс долгий, многое может пойти не так. Монолит — если запустился, уже хорошо. А с микросервисами — что-то запустилось, что-то нет — и придётся откатывать всё к предыдущей версии. А если уже миграции базы применились — то вообще пиши пропало.
А когда микросервисы — это хорошо?
Когда у вас несколько команд, которые независимо делают разные компоненты сервиса.
Тогда команды не будут мешать друг другу и могут пилить и выкатывать эти микросервисы в своём темпе.
Когда нам нужно масштабировать сервисы по-разному
Например, когда на них разная нагрузка. Скажем, у нас есть api, веб-интерфейс и какая-нибудь штука, которая долго обрабатывает данные. Нейросети, например, обучает в фоне. Так вот, на каждый микросервис мы можем отдельно замерить нагрузку и настроить масштабирование так, чтобы ресурсы сервера расходовались оптимально.
Когда сервис должен выжить, при падении какой-то функциональности
Тогда разделяем продукт на критичные микросервисы и на некритичные. И при падении каких-то некритичных микросервисов, работа всего продукта не останавливается, просто некоторая функциональность временно блокируется. Например, на сайте интернет-магазина может отвалиться чат с техподдержкой или личный кабинет, но точно должна работать витрина и приём платежей. Потому что конверсия — это самое важное (ща меня заклюют за эту фразу).
Когда у вас в компании уже давно сложившийся зоопарк технологий
Когда половина бекендеров пишут на Python, половина на PHP, а ещё 46% на Perl, то без микросервисов тут не обойтись. Языки, особенно, скриптовые, слабо умеют интегрироваться между собой.
Разработчики, тимлиды, архитекторы, перед тем, как принимать решение об архитектуре, лишний раз перечитайте этот текст и взвесьте все за и против. Помните, что в ряде случаев монолит сильно выигрывает у микросервисов.
И менеджеры, отдельно вас прошу, если вы это читаете, не навязывайте микросервисную архитектуру в своих проектах. Это серьёзное техническое решение и подходить к нему должны ваши технические специалисты.
А ещё этот пост доступен в формате видео на моём YouTube-канале.
Автор: Александр Шишенко
