Почему микросервисы не нужны: антихайповый разбор

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

Но правда в том, что это решение подходит далеко не всем компаниям. В 90% ситуаций микросервисная архитектура (она же MSA) — избыточность, а не необходимость. Это не просто сложно, а очень сложно. Микросервисы требуют мощной инфраструктуры, глубоких знаний DevOps, тонкой настройки мониторинга и отказоустойчивости. И самое главное — они редко нужны на старте проекта.

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

Почему все говорят про микросервисы

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

Если вы погружены в ИТ-тематику, интересуетесь вакансиями для специалистов, читаете каналы и блоги программистов, у вас может сложиться впечатление, что микросервисы — волшебная кнопка для разработчиков, без которой не обойтись. Но это не так: популярность этой темы — результат нескольких причин. О них — ниже.

Маркетинг на волне хайпа

Разработчики инструментов в этой сфере хорошо зарабатывают на своих продуктах.

Микросервисы — не просто архитектура, это целая индустрия. Компании вроде Google и AWS активно продвигают Kubernetes, Istio и прочие сложные инструменты. Им это выгодно: чем больше людей верят, что без этого стека нельзя, тем больше подписок, лицензий и консультаций продаются.

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

Ориентированность на резюме

Многие разработчики (особенно начинающие) учат микросервисы не потому, что столкнулись с их необходимостью, а потому, что это круто звучит. В итоге в вакансиях пишут «знание Docker/K8s — огромный плюс», а на собеседованиях спрашивают про «опыт работы с распределенными системами», даже если у компании всего лишь сайт-визитка.

Это создает порочный круг:

• новички учат Kubernetes, потому что это востребовано;
• компании требуют Kubernetes, потому что так делают конкуренты; 
• в итоге люди тратят месяцы на сложные технологии, которые никогда не применят.

Факт. Несмотря на универсальность микросервисов, далеко не все гиганты перешли на такой формат работы. Например, GitLab и Spotify до сих пор работают на монолитах.

Завышенные ожидания по проекту

Создатели стандартного проекта искренне считают, что он слишком сложен для монолита. Начинающие разработчики часто переоценивают масштаб своих задач. Они внимательно читают доклады Netflix про архитектуру и решают, что их pet-проект тоже нуждается в распределенной системе.

Что происходит на практике:

• Вместо одного приложения — 10 сервисов, которые падают вразнобой.
• Вместо локальной отладки — часы борьба с сетью и синхронизацией данных.
• Вместо «гибкости» — множество лишних элементов.

В итоге пока вы разбираетесь с Istio и мониторингом, ваш конкурент уже запустит тот же функционал на монолите и получит первых клиентов.

Нужны ли вашему проекту микросервисы

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

Чтобы понять, стоит ли внедрять в ваш проект микросервисы, ответьте на три важных вопроса.

Действительно ли ваш проект настолько масштабен?

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

Сразу проверьте себя:

• Если ваш сервис — это один API, который обслуживает 5 конечных адресов, микросервисы вам не нужны.
• Если вы не можете четко объяснить, какие части системы могут жить автономно (например, платежи без каталога товаров), значит, у вас монолит. И это нормально.

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

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

Действительно ли вам необходимо масштабировать части приложения автономно?

Типичный аргумент за микросервисы: «У нас нагрузка только на платежи, а не на каталог — выгодно масштабировать их по отдельности». На самом деле 99% стартапов никогда не сталкиваются с такой нагрузкой, где это критично. Кроме того, современные облака (AWS, GCP) умеют масштабировать отдельные модули монолита.

Пример. Команда разбила HR-систему на 10 микросервисов. В итоге форма подачи заявок зависела от сервиса сотрудников, который в свою очередь зависел от сервиса отделов. При пиковой нагрузке (раз в месяц) все равно масштабировали все сервисы сразу.

Если вы не Amazon — вам, скорее всего, хватит вертикального масштабирования (+1 сервер) или модульного монолита.

Есть ли у вас услуги, связанные с транзакциями?

В монолите транзакция — это пара строк кода. В микросервисах — сложный квест.

Вот как это выглядит:

1. Платежный сервис списал деньги.
2. Инвентарный сервис не ответил (упал или залагал).
3. Теперь у пользователя списаны деньги, но заказ не создан.

Микросервисы создают проблемы согласованности. В монолите вы обновляете данные одной транзакцией, в MSA это стоит в 10 раз дороже.

7 причин не лезть в микросервисы

Значительная часть начинающих прогеров по умолчанию считает, что микросервисы — это прогрессивно и круто. Но они просто не видят подводных камней. На самом деле MSA — это компромисс со сложностью, деньгами и нервами. И не нужно считать, что монолит — это отсталая технология. Решения, касающиеся архитектуры продукта, нужно принимать, основываясь на объективных данных, а не хайпе.

Рассмотрим главные причины, по которым вам не стоит связываться с микросервисами.

Сложность съедает пользу

Итак, ваша небольшая команда из 5-10 человек решила перейти на микросервисы с расчетом на гибкость, масштабируемость и прочие фишки новой архитектуры.

На практике получается следующее:

• Kubernetes (или иной подобный инструмент) становится источником проблем. Вместо написания кода вы теперь разбираетесь, почему поды (базовые строительные блоки) не стартуют, настраиваете контроллеры, обновляете Helm-чарты. Это занимает 30-50% рабочего времени. 

• Раньше логи были в одном файле, теперь размазаны по 15 сервисам, хранятся в разных форматах, требуют сложной агрегации. Чтобы найти одну ошибку, приходится тратить кучу времени.
• Проблемы с сетевым взаимодействием. Каждый вызов между сервисами — это таймауты, повторные запросы, непонятные ошибки.

Команда тратит полгода на переход. Но сервис получает те же 100 запросов в секунду. Только теперь он становится медленнее, сложнее в поддержке, дороже в эксплуатации.

Сложность ради сложности — это точно не про эффективность. Прежде чем переходить на микросервисы, подумайте — готовы ли вы тратить половину времени не на продукт, а на борьбу с инфраструктурой?

Микросервисы не лечат плохой код

У вас есть монолит — большой, тяжелый, с запутанными зависимостями. И вот вы решаете: «Давайте разобьем это на микросервисы!» В теории звучит отлично: каждый сервис — маленький, независимый, аккуратный.

Но на практике оказывается, что вы просто взяли ваш запутанный код и разделили его на несколько сервисов, не устранив существующие зависимости. Они не исчезают, а лишь меняют форму: вместо вызовов методов внутри одного приложения появляются HTTP-запросы между сервисами. Это не решение проблемы неорганизованного кода, вы создаете новую зависимость — сетевые взаимодействия.

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

Нужна подготовленная команда

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

• Без полноценного DevOps или SRE-инженера вы быстро утонете в бесконечной настройке и мониторинге. Это не та работа, которую можно взвалить на бэкендера — она требует специфических знаний и постоянного внимания. 
• Когда сервисов становится много, появляется новая головная боль — согласование контрактов между командами. Кто за что отвечает? Как тестировать изменения? Что делать, если один сервис ломает другой? Без четких договоренностей и CI/CD-культуры это превращается в хаос.
• В большинстве стартапов два бэкендера, один стажер и горящие сроки. Они едва успевают пилить фичи, не то что разбираться с продвинутыми практиками DevOps. 

В таких условиях попытка внедрить микросервисы чаще всего заканчивается тем, что команда тратит 80% времени на поддержку инфраструктуры вместо разработки продукта.

Деньги тратятся быстрее

Когда речь заходит о микросервисах, многие почему-то забывают простую истину — за все надо платить:

• Без профессионального DevOps-инженера (а хорошие специалисты стоят дорого) ваш «распределенный рай» быстро превратится в ад. Кто будет настраивать Kubernetes, разбираться с падающими подами и оркестрировать логи? 
• Базовый мониторинг вроде Prometheus + Grafana — это только начало. Когда сервисов станет много, вам понадобятся системы трассировки и еще десяток инструментов, каждый из которых требует времени и денег.
• Главная скрытая цена микросервисов — время инженеров. В монолите проверка занимает минуты. В мире микросервисов вам сначала придётся поднять пол-инфраструктуры, чтобы просто удостовериться, что код вообще работает.

Для проектов с нагрузкой меньше 100k пользователей микросервисы обходятся в 2-3 раза дороже монолита. И это без учета скрытых затрат — нервов, задержек и упущенных возможностей.

Отладка микросервисов — это головная боль

Отладка в микросервисной архитектуре требует серьезных затрат времени и финансов. В монолите все просто — есть трассировка стеков (список вызовов), есть логи, и обычно проблема лежит где-то между ними.

Но в мире микросервисов ошибка может прятаться где угодно: в сервисе А, который не так ответил сервису Б, который передал кривые данные сервису В, а тот и вовсе решил ничего не отвечать. И все это с таймаутами, повторными запросами и загадочными HTTP-статусами.

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

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

Легкого масштабирования не будет

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

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

Без этого масштабирование не сработает. Вместо того чтобы увеличивать только перегруженный сервис, вам придется масштабировать весь кластер целиком. Так что прежде чем разбивать систему, подумайте: действительно ли ваша нагрузка требует таких сложных решений?

Когда микросервисы все же нужны

Иногда микросервисная архитектура действительно необходима. Но точно не тогда, когда об этом кричат маркетологи или модные блогеры.

Вот три реальных ситуации, когда MSA имеет смысл.

Независимые продукты под одной крышей

Типичный пример — Яндекс. Это не просто такси, но и доставка еды, и грузоперевозки. Абсолютно разные бизнес-процессы, которые разрабатываются отдельными командами, используют разные технологии, масштабируются независимо.

Здесь микросервисы — не прихоть, а необходимость.

Огромные масштабы

Если у вас одновременно работают 100+ разработчиков, миллионы запросов в секунду, десятки дата-центров по всему миру, монолит просто не выдержит такой нагрузки. Но обратите внимание — мы говорим про реальных гигантов уровня Amazon.

Технический стек из разных компонентов

Иногда часть системы логичнее писать на Go (где важна скорость), часть на Python (для ML), а часть оставить на JVM (для legacy).

Микросервисы позволяют:

• использовать оптимальный язык для каждой задачи;
• обновлять компоненты независимо;
• не тащить в проект лишние зависимости

Все эти случаи объединяет одно: микросервисы решают конкретные проблемы, а не внедряются «на всякий случай». Если ваш проект не подпадает под эти критерии — возможно, стоит еще раз подумать. Использовать микросервисы без необходимости — это неоправданная роскошь.

Итоги

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

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

А если хочешь писать код, который не стыдно показывать, собрали всё для фронтендеров и бэкендеров в одном месте.