«Вынесите из монолита один сервис — станет на 50 % быстрее»: всегда ли нужно переходить на микросервисы

Сейчас все большую популярность приобретает микросервисная архитектура как более гибкий инструмент в разработке проектов. За последнее десятилетие многие BigTech-компании, среди которых eBay, Amazon, Netflix и более десятка других, сделали выбор в пользу микросервисной архитектуры и успешно развивают проекты с ее помощью.

В чем преимущества такого типа архитектуры, когда на нее следует мигрировать и на что обратить внимание при переходе, рассказывает Tech Lead Manager в Preply и лектор курса «Микросервисная архитектура» Влад Карнаушенко.

Микросервисная архитектура (microservice architecture, MSA) — один из подходов к проектированию, при использовании которого единое приложение состоит из набора небольших независимых компонентов, называемых микросервисами. Каждый из них работает в отдельном процессе, отвечает за конкретный функционал и взаимодействует с другими модулями.

Влад Карнаушенко, Tech Lead Manager в Preply и лектор курса «Микросервисная архитектура»

Почему микросервисы не панацея — и какие у них подводные камни

— Какие преимущества есть у микросервисной архитектуры?

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

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

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

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

— Какие вызовы и риски существуют в случае перехода на микросервисы и как с ними бороться?

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

Но даже если вы знаете, как правильно спроектировать и реализовать микросервисы, остается открытым вопрос, как с ними жить:

• Первое, о чем инженеры часто забывают, — это необходимость согласовать организационную структуру с новой архитектурой. К примеру, если у вас при монолитной архитектуре была одна команда из 30 человек, при переходе на микросервисы есть смысл разбить эти 30 человек на меньшие команды по пять работников.
• Во время перехода более актуальным становится вопрос девопсинга. При монолите обычно есть один сервер, а в случае с микросервисной архитектурой — это множество серверов, о которых нужно заботиться, мониторить и развертывать там код. Даже простые операции с инфраструктурой в этой ситуации будут усложнены, так что готовьтесь инвестировать в девопс-культуру и высококачественных инженеров.
• Также не следует забывать о мониторинге. Раньше у вас все обрабатывалось в одном месте, где писали логи, и было достаточно их там почитать, чтобы понять, что происходит. А теперь у вас один запрос пользователя прыгает по разным сервисам — и вам нужно понимать, где в этот момент что-то пошло не так.
• То же касается и вопросов безопасности. Условно, у вас есть где-то бридж, через который пытается попасть злоумышленник. Знаете ли вы, куда именно он пытается попасть, или это останется для вас незамеченным?

Еще очень важна коммуникация микросервисов между собой. Нет менее стабильной вещи, чем сеть, а именно с помощью нее микросервисы непрерывно общаются друг с другом.

— В каких случаях микросервисная архитектура будет не самым лучшим решением и от нее лучше воздержаться?

Прежде всего если вы только начинаете проект и имеете слабое представление о том, что будете разрабатывать. В этом случае сосредоточьтесь на предмете разработки, сделайте какой-нибудь proof of concept, а дальше посмотрите, какие у вас есть проблемы и возможно ли решить их с помощью микросервисов. Кроме того, учитывайте также домен вашего проекта и его особенности.

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

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

• есть микросервис, собирающий деньги;
• и тот, который бронирует места и сообщает другим микросервисам, какие еще свободны.

В какой последовательности двигаться?

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

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

Как перейти на микросервисы вовремя и без проблем

— Какие проблемы обычно решает микросервисная архитектура?

• Разрастание организации, когда люди начинают мешать друг другу из-за величины команд. Если с приходом нового человека в команду скорость разработки не растет, а иногда даже спадает, то стоит присмотреться к микросервисам.
• Набор избранных технологий начинает вас сильно ограничивать. Условно код написан на Java, а теперь вам необходимо machine learning решение с библиотеками на Python. На разных языках в одной кодовой базе вы писать не будете, поэтому это путь к сервис-ориентированной архитектуре. В данном случае вы можете реализовать отдельную часть на другом языке или с другой базой данных.
• Масштабирование системы. Представим, что у вас есть новостной сайт и условный график пользовательской активности. К примеру, в 14:00 люди идут на обед и читают новости: начинается наплыв пользователей, а дальше активность снова падает до привычной. В этом случае нет необходимости платить за большие мощности в течение всех суток: они нужны только в моменты пиковой нагрузки. Здесь очень выручает микросервисная архитектура, позволяющая усилиться именно там, где нужно.

курс: Микросервисная архитектура

Владислав Карнаушенко Tech lead manager в Preply

 

— На каком этапе следует задуматься о переходе на микросервис?

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

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

— Что делать, когда пора, а тимлид сомневается и не спешит переходить на микросервисы?

— Покажите эффективность микросервисов на конкретном примере. Вынесите из монолита один микросервис, придите к руководству и покажите: «Было так, а стало на 50 % быстрее. Хотите, чтобы мы двигались в таком направлении? Приоритизируйте эту задачу, выделите ресурсы — и работаем».

С другой стороны, если руководство до сих пор не хочет покидать монолит, то теперь на определенные технические проблемы вы имеете право реагировать аргументом «а если бы мы перешли на микросервис, то этого не было бы» (смеется. — Ред.). По этическим соображениям это не самый правильный способ, но довольно действенный.

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

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

Цена перехода на микросервис

— Как раз если говорить о финансах, сколько это стоит и насколько оправдана такая инвестиция?

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

Несколько упрощенная, но понятная схема архитектуры

Подробная схема архитектуры с мобильным приложением и веб-версией

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

Оценили, все взвесили, теперь начинаем считать:

• Пусть нам потребуется привлечение 20 специалистов в течение шести месяцев. Считаем стоимость их работы.
• Также у нас есть ряд проблем, по которым мы решили мигрировать на микросервисы. Влияние этих проблем, вероятнее всего, тоже можно посчитать в денежном эквиваленте: сколько мы теряем из-за того, что наша архитектура такая, какова она сейчас.
• Далее возникает вопрос, за какое время микросервис себя окупит. Большая часть расходов будет локализована по времени: условно, мы предусматриваем три месяца активных расходов, которые будут окупаться следующие два года. И если компания видит будущее этого проекта в такой временной перспективе, а затраты оправданы, то решение о переходе очевидно.

— Можно ли выделить KPI перехода на микросервисную архитектуру?

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

К примеру, это может быть количество функционала, который вы разрабатываете у себя на сервисе. Эта характеристика называется modifiability и оценивает, насколько продукт способен к модификации, анализируя касательные показатели (такие как скорость тестирования, количество появляющихся багов, частота падения вашего продакшена и т. п.).

Также не стоит забывать о guard-rail метрике и вещах, на которых вы не фокусируетесь в первую очередь во время миграции на микросервисную архитектуру, но которые также не должны проседать.

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