На 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 и т.д. Также на качество конечного технического решения влияют процессы, связанные с развитием процесса разработки, тестированием”, – отметил специалист.
Добавить комментарий