От монолита к микросервисам. Как упростить и ускорить работу онлайн-магазина продуктов

Опыт «Утконоса».

Уже 21 год компания «Утконос ОНЛАЙН» доставляет продукты жителям Москвы и области. Мы были одними из первых на рынке: в нулевых наши клиенты выбирали товары из печатного каталога, делали заказ по телефону и потом забирали его в пунктах выдачи. С тех пор многое изменилось: сейчас на нашем сайте более 70 тысяч товаров, которые мы можем привезти за два часа, а в год доставляем около 3 млн заказов. В блоге компании будем рассказывать о том, как эти изменения стали возможны.

Начинаем блог с разговора про бэкэнд: директор ИТ-департамента Мария Артамонова делится опытом перехода от неповоротливого приложения к быстрым сервисам, которые подстраиваются под любые бизнес-задачи.

Монолитом называют продукт, все компоненты которого взаимосвязаны и взаимозависимы. Если один не работает, то не работают и все остальные.

Микросервисы — небольшие, автономные сервисы, которые работают совместно и нацелены, как правило, на выполнение одной задачи.

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

Например, раньше мы хранили часть данных в системе планирования SAP ERP, другую часть — в компоненте для управления запасами EWM и на нашем сайте. Это значит, чтобы отобразить интервал доставки при оформлении заказа, нужно получить данные о доступности ресурсов из трёх разных систем. То же самое с любыми доработками, в том числе с простыми изменениями логики доставки для курьеров.

Отслеживать сбои в монолите тоже было непросто. Из-за запутанной, где-то сращённой логики невозможно было разобраться, чей набор функций работал некорректно. Например, адрес доставки каким-то неявным способом влияет на скидки. Кто должен это исправить? Продуктовые команды перекладывают ответственность друг на друга: «это не наше, идите к логистике». Поэтому на устранение проблемы уходило слишком много времени.

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

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

Мы не могли остановить бизнес-процессы, переделывать приходилось на ходу.

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

В тот период всем нужно было меняться быстрее обычного. Нам удалось запустить экспресс-доставку за 2 часа (до этого привозили только на следующий день), расширить ассортимент на десятки тысяч товаров (сейчас в ассортименте 70 тысяч позиций, это сопоставимо с ассортиментом огромного гипермаркета) и создать самописную WMS-систему (warehouse management system), которая автоматизирует работу складов. Последнее обычно занимает полтора-два года, но мы справились за 9 месяцев, над этим проектом сегодня трудятся 70 специалистов: продакты, разработчики, аналитики и тестировщики.

Нагрузку увеличивали постепенно. Сначала рядовая проверка на тестовых стендах, потом интеграционная, потом — выкладка в продуктив на минимальный трафик 1–5% и плавное увеличение до 100%. Некоторые сервисы мы просто «зеркалировали»: процессы работали по старой логике, пока мы тестировали новую.

При переходе от монолита к микросервисам мы не привлекали сторонних специалистов, обращались к ним только за консультацией (иногда важно услышать другую точку зрения). Поэтому команду расширили — в три раза (причём через профильные сайты нашли всего половину, остальных — по рекомендациям и через соцсети, в том числе LinkedIn). Разработчиков стало больше, около 80%, тестировщиков — порядка 20%.

При этом обновление технологического стека и переход на Python сильно упростили наём: молодые специалисты теперь охотнее идут к нам в команду.

Сейчас в ИТ-команде «Утконоса» более 400 человек, в начале года нас было 219.

До перехода мы вели работу в разных вариациях системы SAP. Система — всё ещё часть компании, но большая её часть превратилась в микросервисы и разделилась на 3 основные части:

Раньше, если что-то не получалось, мы часто слышали: «виноват ИТ-департамент». Теперь этот тезис благополучно забыт. С переходом на микросервисы мы моментально подхватываем практически любую инициативу бизнеса.

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

У каждого набора функций от бизнеса свой продакт-менеджер: он оценивает инициативы бизнеса с точки зрения юнит-экономики (сколько денег принесёт та или иная доработка), отклоняет неактуальные, ставит задачи по наиболее важным изменениям.

«Распил» монолита — это долго, сложно и травматично. Именно поэтому так много компаний продолжают использовать устаревший легаси-код. Если ваша компания всё же решилась на трансформацию, наш главный совет:

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