ГлавнаяБлог

Микросервисная или монолитная архитектура: что выбрать бизнесу при разработке приложения?

На Kazakhstan Technology Summit (K-Tech) в Алматы руководители IT-подразделений крупных компаний обсудили современные подходы разработки приложений. Мероприятие для  руководителей и экспертов в IT проводится под эгидой корпоративного фонда Kazakhstan Growth Forum с 2018 года. 

Чем монолитная архитектура отличается от микросервисной?

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

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

Монолит или микросервис: что выбрать CEO?

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

Главный управляющий директор по IT и инновациям Halyk Bank Антон Мусин отметил, что переход на микросервисную архитектуру выгоден компании в том случае, если ей нужно масштабироваться, увеличить производительность, произвести быстрые изменения и уменьшить время от начала разработки идеи до ее реализации (Time to Market). Особенно актуален этот переход будет для компаний, работающих с розницей и имеющих большие нагрузки.

В свою очередь главный архитектор PS Cloud Solutions Павел Черторогов считает, что универсального решения не существует. Актуальность микросервисного или монолитного подхода зависит от решений бизнеса. Иногда проще несколько мелких вещей объединить в одну, а иногда – раздробить одну большую на несколько мелких, чтобы ими было легче управлять. Для того чтобы изолированные группы и системы функционировали между собой, нужно создавать канал коммуникации. 

Обратная сторона перехода с монолита на микросервисы – высокая стоимость. 

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

Как сделать переход правильным? 

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

“В первую очередь бизнес должен подумать, как обеспечить экспертную поддержку подразделения, которое собирается дробить существующий рабочий продукт. В IT-подразделение нужно будет внедрять доменных экспертов, которые на каждом этапе проектирования будут поддерживать новые архитектуры”, – говорит Ярослав Белов. 

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

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

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

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

Roadmap

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

“Нужно подготовить и настроить инфраструктуру. Затем нанять и обучить экспертных сотрудников. Возможно, архитектор должен разработать типизированные шаблоны того как, как должен вести себя разработчик при создании нового сервиса”, – отметил эксперт.  

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

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

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