Pull to refresh

Хватит везде делать микросервисы

System Analysis and DesignDesigning and refactoringMicroservices

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


image


Микросервисы — это плохо, и вот почему


Микросервисы затрудняют разработку


Это всегда источник геморроя. Ну серьёзно, помимо функциональности сервиса, нам приходится разрабатывать протоколы общения микросервисов, а составить хороший протокол — это отдельная сложная задача. Потом этот протокол ещё и нужно поддерживать. А это сложно и дорого. А ещё вам придётся на каждый чих делать отдельный сервис, регулярно обновлять в нём библиотеки, иначе он перестанет развиваться и превратится в легаси.


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


Микросервисы требовательны к инфраструктуре


Когда у нас монолит, мы просто можем вызвать функцию и тут же получить результат. На вызов функции накладных расходов нет. А с микросервисами — мы должны отправить запрос, принять его, распарсить. Это лишние накладные расходы на сеть, память и CPU. А накладные расходы — это лишняя трата денег.


Микросервисы затрудняют развёртывание


Вот представьте себе, вам нужно выкатить на продакшен какую-то новую фичу. Окей, вы готовите репозиторий, собираете контейнеры (у вас ведь Docker, правда?). И наступает время деплоя. И тут, вам придётся аккуратно последовательно отключать все ваши микросервисы и накатывать новые версии. Процесс долгий, многое может пойти не так. Монолит — если запустился, уже хорошо. А с микросервисами — что-то запустилось, что-то нет — и придётся откатывать всё к предыдущей версии. А если уже миграции базы применились — то вообще пиши пропало.


А когда микросервисы — это хорошо?


Когда у вас несколько команд, которые независимо делают разные компоненты сервиса.
Тогда команды не будут мешать друг другу и могут пилить и выкатывать эти микросервисы в своём темпе.


Когда нам нужно масштабировать сервисы по-разному


Например, когда на них разная нагрузка. Скажем, у нас есть api, веб-интерфейс и какая-нибудь штука, которая долго обрабатывает данные. Нейросети, например, обучает в фоне. Так вот, на каждый микросервис мы можем отдельно замерить нагрузку и настроить масштабирование так, чтобы ресурсы сервера расходовались оптимально.


Когда сервис должен выжить, при падении какой-то функциональности


Тогда разделяем продукт на критичные микросервисы и на некритичные. И при падении каких-то некритичных микросервисов, работа всего продукта не останавливается, просто некоторая функциональность временно блокируется. Например, на сайте интернет-магазина может отвалиться чат с техподдержкой или личный кабинет, но точно должна работать витрина и приём платежей. Потому что конверсия — это самое важное (ща меня заклюют за эту фразу).


Когда у вас в компании уже давно сложившийся зоопарк технологий


Когда половина бекендеров пишут на Python, половина на PHP, а ещё 46% на Perl, то без микросервисов тут не обойтись. Языки, особенно, скриптовые, слабо умеют интегрироваться между собой.


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


И менеджеры, отдельно вас прошу, если вы это читаете, не навязывайте микросервисную архитектуру в своих проектах. Это серьёзное техническое решение и подходить к нему должны ваши технические специалисты.


А ещё этот пост доступен в формате видео на моём YouTube-канале.


Видеоверсия
Tags:микросервисымикросервисная архитектураотчаяниехватит это терпетьтеги все читают
Hubs: System Analysis and Design Designing and refactoring Microservices
Total votes 88: ↑80 and ↓8+72
Views27K
Comments Comments 105

Popular right now

Top of the last 24 hours