От монолита к микросервисам: кейс Костадина Алмишева по трансформации IT-систем

Фото: предоставлено героем публикации

Переход от монолитной архитектуры к микросервисам стал своеобразным императивом для многих IT-директоров и технических лидеров. Однако на практике этот процесс часто оборачивается возрастающими инфраструктурными трудностями. Рост сложности связей, конфликты зависимостей, потеря управляемости и непрогнозируемое поведение системы при нагрузке - типичные спутники такой трансформации. Чтобы разобраться, как пройти этот путь без потерь и превратить хаос в систему, мы обратились к практику, который реализовывал подобные проекты в нагруженных системах страны.

Наш собеседник — Костадин Алмишев, инженер, специализирующийся на создании инфраструктурных инструментов. За его плечами опыт в Ozon, Яндекс.Вертикали и крупнейших банках страны. Он обладает редким навыком - объяснять сложные архитектурные концепции так, чтобы логика процесса становилась понятной даже тем, кто далек от написания кода. Костадин не уходит в технические нюансы ради деталей, он выстраивает цепочку от бизнес-проблемы к архитектурному решению. Благодаря этому становится видно: перед нами инженер, который привык работать на уровне структурных изменений, фундаментально влияющих на скорость и качество всей разработки.

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

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

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

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

- В чем заключается главная невидимая сложность при переходе на микросервисную архитектуру? О чем обычно забывают компании, начиная этот путь?

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

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

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

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

- Это один из самых сложных вопросов в инженерии. Главный вызов заключается в обеспечении целостности данных и их предсказуемости.

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

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

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

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

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

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

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

- Вы упомянули стандартизацию. Не убирает ли она творчество в разработке? Ведь инженеры любят свободу выбора инструментов.

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

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

- К чему в итоге приводит такая работа для бизнеса? Как генеральный директор или акционеры могут почувствовать результат деятельности платформенного инженера?

- Бизнес чувствует это через два ключевых показателя: скорость запуска новых функций, решений на рынок и стабильность. Предсказуемость релизов - это главное, что мы даем. Бизнес получает возможность планировать маркетинговые кампании и запуски, не боясь, что IT-отдел не сможет реализовать новый продукт к его выходу и потребуется перенести сроки. Это добавляет время на эксперименты, аналитику, позволяя находить новые прибыльные решения.

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

- Какой совет вы бы дали техническим директорам компаний, которые сейчас находятся в процессе этой трансформации? На чем держать фокус?

- Не пытайтесь скопировать чужой успех, например, Netflix или Google, один в один. У каждой компании свой контекст. Начинайте с малого: выделите один домен, переведите его на микросервисы, отработайте процессы, и только потом масштабируйте.

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

Кейс Костадина Алмишева наглядно показывает: трансформация IT-систем - это не просто смена технологий, это глубинное изменение философии разработки программного продукта. Работая со сложными проектами, Костадин сформировал компетенции, которые выходят далеко за рамки типовой инженерной роли. Он не только оптимизирует процессы разработки, но и выстраивает предсказуемые архитектурные принципы для масштабных платформ. Такой уровень влияния на систему делает его одним из специалистов высшего уровня, к которым обращаются за методологией, а не только за техническими решениями. Именно такие инженеры превращают хаотичный набор микросервисов в стройную, надежную и эффективную экосистему, способную развиваться годами.