Что это

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

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

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

Куралай: “Наша команда разработчиков специализируется на цифровых кредитных процессах. Мы успели поработать над десятками проектов, где учитывались разные данные. Поэтому мы пробовали разные решения”.

‍

Для кого это

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

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

‍

Как это работает

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

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

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

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

Сейчас мы создаем продукты как на монолите, так и на микросервисах. Планируем часть “монолитных” приложений перенести на микросервисы, но точно не все. Потому что стабильные проекты, соответствующие всем требованиям и полностью удовлетворяющие нас, в этом не нуждаются. Иначе получится работа ради работы, а мы смотрим на результат, который сможем принести бизнесу”.

‍

Что особенного

Четкого “красного флага” для перехода от одной архитектуры к другой – нет. Оба решения позволяют писать приложения и управлять ими. Важно понять – какова бизнес-цель, и чем обусловлен выбор определенного решения. Обычно выбирают одну из двух бизнес-целей – либо возможность зарабатывать больше, либо возможность тратить меньше.

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

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

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

Куралай: “В Globerce Capital мы разработали достаточно много кредитных конвейеров. И то, что мы решили перейти на микросервисную архитектуру, было лишь вопросом времени. Мы научились разрабатывать кредитные продукты на монолите, изучили боли и потребности бизнеса.

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

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