Как бизнесу модернизировать архитектуру IT-сервисов, не теряя контроль и деньги: опыт Михаила Андреева, Dodo Engineering

Переход на микросервисы — уже не дань технологической моде, а ответ на реальные бизнес-вызовы: монолитные продукты, когда все части приложения представляют собой единый блок, тормозят релизы и рост. Необходимость внести даже небольшие изменения приводят к потере времени и ресурсов. Ответом на эту проблему может стать микросервисная архитектура с ее гибкостью, масштабируемостью и быстрыми релизами. Однако, по данным исследования Gartner «Hype Cycle for Application Architecture and Integration, 2023», более 70% компаний, начавших переход на распределенные микросервисные архитектуры, уже на начальном этапе сталкиваются с проблемами из-за недостаточной зрелости DevOps-практик и понимания стратегии. Как понять нужен ли переход, что поможет провести миграцию без потерь и с каким ошибками чаще всего сталкиваются команды — об этом в интервью с Михаилом Андреевым, старшим iOS-разработчиком компании, которая создает технологии и продукты для развития брендов Dodo, а его решения применяют также Raiffeisenbank и OneTwoTrip в приложениях с миллионами пользователей.

𝓲

Фото: Личный архив Михаила Андреева

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

— Самая распространенная — когда компании идут в микросервисы ради моды, а не ради конкретной цели: «так делают все», значит, нам тоже надо. Но если не разобраться, где именно у бизнеса проблема — например, почему релизы идут слишком долго или поддержка стоит слишком дорого, то вместо улучшения получается только хуже. Вместо одного монолита появляется десяток маленьких «монолитиков», которые сложнее поддерживать и связывать между собой. Частой причиной проблем на старте бывает отсутствие архитектурного лидерства — когда нет человека или группы, которые держат в голове общую картину, и каждая команда делает по-своему. В итоге архитектура превращается в пестрый набор решений, а стоимость владения только растет. И еще один момент, который часто недооценивают — человеческий фактор. Если не вкладываться в обучение и объяснение, зачем все это нужно, команда будет сопротивляться, и тогда никакая красивая архитектура не даст роста. В этом смысле данные Gartner хорошо иллюстрируют реальность: модульность — это не только техника, но и культура.Гид по российским системам PAM (Privileged Access Management) 88.7 т

— Как старший разработчик в Dodo Engineering в последние годы вы отвечаете за очередной этап миграции к микросервисам. Какие решения помогли вам вести проект без срывов?

— Во-первых, нужны единые правила разработки модулей. Когда каждый модуль создается «по-своему», архитектура быстро теряет управляемость. Поэтому мы сразу ввели архитектурный гайд и шаблоны для Tuist — это инструмент для работы со структурой проекта, чтобы разработчик не изобретал велосипед. Кроме того, чтобы процесс перестраивания монолитной архитектуры на отдельные сервисы не приводил к сбоям, мы выбрали поэтапную стратегию: сначала вынесли самые ресурсоемкие модули, затем критически важные функции и только потом — остальное. И сформировали центр ответственности за целостность проекта, чтобы избежать хаоса. У нас были выделенные архитекторы-наставники внутри команды, которые помогали разработчикам и проводили ревью ключевых изменений. Этот комплекс решений позволил избежать тех самых классических ловушек: мы сохранили управляемость системы, сократили время сборки на 10–15% и при этом не тормозили вывод новых функций.

— Объясните как тот, кто в том числе отвечает за ключевые решения и результаты, как техническое изменение превратилось в бизнес-результат?

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

— Вы упоминали важность предотвращения сопротивления внутри команды. А что помогало вам убедить менеджмент инвестировать в масштабный перезапуск? Для приложения с пользователями в 25 странах мира риск очень высок — ошибки могут стоить бизнесу очень дорого.

— Когда возникают сомнения, самое лучшее — это перестать говорить про техническую сторону и начать говорить как раз про ценность для бизнеса. Мы исходили из трех простых метрик, которые понятны менеджменту: первое — это скорость сборки и доставки. Для наглядности замеряли время сборки — в монолите условно 40 минут, после модульности — уже 34. Это уже около 15% прироста скорости. На языке бизнеса: команда выкатывает обновления чаще, а значит быстрее удовлетворяет пользователей. Второе — на реальных примерах мы показали, что в монолите даже небольшая правка могла затрагивать десятки несвязанных экранов и требовать длительного регресса. В модульной архитектуре изменения локализованы внутри конкретного модуля — это снижает затраты времени на доработку и тестирование. Третий довод — управляемость и риски: карта зависимостей наглядно показала, что ошибка в монолите могла блокировать весь релиз. В модульной структуре дефект изолируется, и команда быстрее выпускает исправления без «пожарного режима». Так бизнес получает не только ускорение релизов, но и снижение издержек. За счет этого вложения в модульность начинают окупаться уже через несколько месяцев.

— А как вы действовали, когда увидели необходимость полностью перестроить на более современной платформе мобильное приложение Райффайзенбанка? Вы ведь не могли знать сразу, что это увеличит конверсию на 20%.

— У нас была проверенная гипотеза — мы пришли к бизнесу с конкретными цифрами: переход на обновленное приложение позволит нам быстрее разрабатывать новые сценарии, а пользователи получат более современный и удобный интерфейс. Для банка это конвертируется в рост вовлеченности и транзакций. Чтобы снизить риски, мы пошли не «большим взрывом», а поэтапно: сначала переписали изолированные экраны, параллельно замеряли метрики, собирали обратную связь от пользователей и сравнивали конверсию. Когда увидели прирост более чем на 20% в тестовых сегментах, аргументировать продолжение миграции стало очень легко — это был уже не рефакторинг, не просто «переделка», а инвестиция с очевидным бизнес-эффектом. Таким образом, бизнес получил гарантированный рост, а команда — современный стек и более быстрые инструменты разработки. Принимать решения о трансформациях важно с опорой на реальные условия и данные.

— У вас большой опыт работы в Agile-командах — вы взаимодействуете с дизайнерами, аналитиками и маркетологам. Как выстраиваете «культуру модульности», о которой говорили в начале? � «Культура модульности» — это не только про код. Если разработчики пишут изолированные модули, но при этом дизайн остаётся «монолитным» — когда макеты собираются как цельные экраны без переиспользования компонентов, эффекта не будет. Важно, чтобы и дизайнеры опирались на библиотеку UI-элементов, и аналитики формулировали гипотезы в границах конкретного модуля, а тестировщики проверяли отдельные сценарии. Только так модульность работает на уровне всей команды и реально снижает издержки.

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

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

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

— Я бы не сказал, что микросервисы «сдают позиции». Скорее, рынок взрослеет и учится подбирать инструмент под задачу. Долгое время компании бросались в крайности: все в монолит, потом все в микросервисы. Сейчас идет поиск баланса. Новый виток интереса к монолитным системам — это не возврат к старым монолитам, а оптимизированные модульные архитектуры: четкие границы, независимые команды, но при этом меньше операционной нагрузки, чем у десятков сервисов. Компании поняли, что важна не сама архитектурная мода, а эффективность: скорость вывода фич, управляемость и затраты на поддержку. Так что речь не о том, что микросервисы уходят, а о том, что на смену догме приходит прагматизм. У кого-то по-прежнему выигрывает микросервисная модель, у кого-то — модульный монолит. Все зависит от зрелости команды, ресурсов и целей бизнеса.

Автор: Дмитрий Каминский