Разговоры о микросервисной архитектуре звучат тут и там. Тут и там работу с монолитом описывают черными и серыми тонами. В то же время микросервисам присваивают все самые положительные свойства. Для меня, как для человека, который поработал и с тем и с другим, это стало поводом внести в этот вопрос немного ясности, приправленной личным мнением.
Если лень читать всё, сразу запомните основное. Монолит — это не плохо, это неудобно. Особенно в больших командах. Впрочем, все подробности ниже.
Монолит против микросервисов. Аналогия
Представим архитектуру приложения как точку общественного питания.
В таком случае монолит будет маленьким ларьком с шаурмой. В нем один сотрудник левой рукой принимает деньги за блюдо, правой — заворачивает начинку в лаваш и кладет на гриль. Он же делает кофе и чай, а когда посетителей нет он еще и приводит рабочее место в порядок и выносит мусор (хочется верить что моет руки после всего этого). И это работает. Работает дешево и сердито, но эффективно. И работает до тех пор, пока поток посетителей не превышает 10-20 человек в час или пока сотрудник не заболеет.
Микросервисный зоопарк — это уже фуд-корт в огромном ТЦ где-нибудь на окраине мегаполиса. Тут делают кофе, там — сочные бургеры, за чистотой и урнами следят «менеджеры по клинингу», а за безопасностью — служба охраны. Зоны ответственности строго разделены. И, например, если сотрудник кофейни проспит свою смену, это не помешает вам заказать бургер в ресторане. Такая система может обслужить около 1000 человек в час или даже больше. И она будет стабильной.
Однако стоимость содержания такого микросервисного общественного питания кратно выше. И платить её имеет лишь в том случае, если это будет окупаться. Никакой магии, простые законы рыночной экономики. Но даже при этом никто не хочет монолит. Но почему?
1. Риск сломать всё вокруг
В монолите весь код лежит в одной куче. Да, может быть структурированной и организованной, но в куче. Корзина, список товаров, фильтры, статические страницы — всё свалено внутри одной директории src.
Теперь представьте, что вам нужно поправить хендлер, который обрабатыват клик на кнопку подписки на рассылку. Дело несложное. Внеся пару неосторожных изменений в код и задеплоив все это на прод, вы обнаруживаете, что попытка подписаться на новости о скидках приводит к тому, что красивый фронтенд превращается в белый экран.
В монолите одна ошибка в любом месте приводит к коллапсу всего приложения. Как и в примере выше, если повар не вышел на работу, шаурмы вы не дождётесь. Даже воду не нальют.
В микросервисах, если упал сервис подписки, то всё остальное продолжает работать: корзина наполняется, каталог открывается, просто вместо модуля с подпиской показывается надпись «Не загрузилось». Падение одного звена не убивает всю цепь.
2. Бесконечное ожидание сборки — убийца продуктивности
Не знаю как у бэкендеров, но это болит у каждого фронтендера, который работает с монолитом.
Чтобы посмотреть, как поменялся внешний кнопки после мелких правок, тебе нужно запустить билд всего проекта. Через 3-5-10 минут сборка 5000 файлов будет завершена, его можно будет запустить и обнаружить, что отступы получились кривыми. И пройти весь путь по новой.
В микросервисах ты запускаешь только свой маленький сервис. Он стартует за 5 секунд, на дев-сервере настроен хот-релоад. Ты меняешь код — и сразу видишь результат.
Когда после каждого чиха приходится придумывать себе занятие на время десятиминутной сборки, желание работать пропадает.
3. Технологический ад и вендорская привязка
Допустим, когда-то вы начали проект на первом Ангуляре (том, который уже не поддерживается) и относительно свеженьком PHP 5.3. Время идет, технологии развиваются и вы не хотите отставать. Да и вообще вы поняли, что React подходит вам больше.
В мире микросервисов вы говорите: «Начнем с сервиса корзины товаров, перепишем на новый стек, и если все взлетит отлично — перепишем остальное, когда будет время».
В мире монолита вы не можете обновить стек «по кусочкам». Либо вы сидите в обнимку с древними технологиями до конца жизни, либо вы останавливаете всю разработку на несколько спринтов и делаете «Великий Рефакторинг», после которого всё летит к чертям. Особенно психика команды.
4. Масштабирование через боль и страдания
Представьте, что у вас сервис который транслирует спортивные события со всего мира, а сегодня — финал Лиги Чемпионов. Ожидается, что к началу матча на сайт придет в 10 раз больше людей, чем обычно. Сервису видео придется попотеть, и мы хотим ему помочь.
Если у вас микросервисы, вы нажмете в админке несколько кнопок и сделаете 10 копий сервиса, нагрузка на которые будет распределяться параллельно. При этом для остальных сервисов, например, для сервиса комментариев или новостей, можно оставить 2-3 копии.
В случае монолита вам придется скопировать всё приложение целиком. Это неэффективно, больно и дорого. Вам придется заплатить за железо, которое простаивает, потому вам нужно больше сервиса видео, но не сервиса новостей.
А есть ли жизнь с монолитом?
Я рассказал много неприятного про монолиты, но давайте по-честному. Для 80% проектов монолит — это ок. Если вы делаете лендинг, корпоративный сайт, небольшой интернет-магазин, блог — микросервисы это как из пушки по воробьям.
Вы потратите месяц, настраивая Kubernetes, Docker-контейнеры, а в итоге ваш сайт будет открываться на 0.2 секунды быстрее, но денег вы на это потратите как на крыло от Boeing.
Почему же никто не хочет монолит? Потому что в вакансиях пишут про высокие нагрузки, потому что на митапах крутые парни рассказывают про микросервисы, а всем нам хочется быть крутыми.
Однако давайте договоримся так
Если ты не понимаешь, зачем тебе микросервисы — тебе нужен монолит.
И наоборот: микросервисы нужны только тогда, когда монолит уже физически мешает командам работать и разваливается от нагрузки.
Вердикт
Не стоит бояться монолита. В начале карьеры — это вообще большое счастье, ведь сразу понятно что где лежит и как вносить изменения. Однако, если на вашем проекте:
- фронт собирается от 10 минут
- тестовые стенды падают целиком от любой маленькой ошибки на фронте
- внесение изменений превратилось в ад
поднимай вопрос о том, чтобы распилить приложение на микросервисы. Самое время изучать кубер, докер, nginx. Однако предупреждаю, что смена архитектуры с монолитной на микросервисную — захватывающее приключение, во время которого тебя ждут различные испытания, но это уже совсем другая история…
