Архитектура как ИТ-искусство. Монолиты или микросервисы?

Проблема выбора между двумя разными подходами к построению архитектуры приложений, кажется, не потеряет актуальности никогда. Действительно ли монолитная архитектура непоправимо устарела и уже не способна закрыть все кейсы, а микросервисная, в противоположность ей, куда более современна и продвинута? И в каких случаях простота, рациональное использование ресурсов и производительность – всё, что отличает монолиты, – и сегодня более востребованы, чем масштабируемость, гибкость и технологическое разнообразие микросервисов? Чем представители ИТ-сообщества могут обосновать бизнес-заказчику выбор в пользу того или иного подхода при создании корпоративных приложений и какими доводами они оперируют в том или ином случае?

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

Авенир ВОРОНОВ (CTO «Корус Консалтинг»)«Помимо монолитной и микросервисной, существует множество других архитектур и подходов к разработке. Их можно комбинировать. Есть так называемые микромонолиты, есть гига-микросервисы. Некорректно утверждение, что только лишь процессы разработки микросервисов соответствуют принципам DevOps. Это вовсе не означает, что при разработке «монолитов» следование принципам DevOps отсутствует, гетерогенная среда вполне может присутствовать и в монолитной архитектуре. Учитывая все это, отдавать предпочтение какой-то одной структуре, как мне кажется, не стоит».

В консервативных отраслях экономики гибридный подход к построению архитектуры практикуется повсеместно. Реализовать микросервисы удается и при наличии стандартного корпоративного решения, например, если у заказчика возникают какие-либо нестандартные, эксклюзивные требования. В банковском секторе, говорит Тарас СОРОКА, управляющий директор Уральского банка реконструкции и развития, основополагающие ИТ-системы банков – core banking – в большинстве случаев реализованы на монолитной архитектуре. Но в практике работы спикера есть кейс, когда перевод на микросервисы такого важного набора банковских процессов, как кредитный конвейер, позволил повысить производительность и управляемость последних.

Плюсы и минусыИллюстрация: Mikko Lemola/shutterstock.com

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

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

Для действительно эффективной работы микросервисов необходимо как минимум всё перечисленное. Микросервисы хороши там, где есть требования по быстрому масштабированию и распределенной нагрузке и при этом есть возможность привлекать экспертизу высокого уровня, причем не только в разработке, но и в DevOps, и в администрировании. В других случаях лучше использовать монолит: можно купить готовое решение, стоимость владения монолитом ниже. А для разработки ИТ-сервисов, нагруженных большим количеством пользователей (как правило, для бизнеса B2C), оптимальнее использовать микросервисную архитектуру, более гибкую и легко масштабируемую.

Антон КУЗНЕЦОВ («Динекс Русь»)«Важны такие факторы, как отказоустойчивость и надежность. Если “падает” решение на монолитной архитектуре, например ERP или управление холдингом, то, пока система полностью сама не восстановится, работать нельзя. Если же ошибку содержит один из типов микросервисов, то “упадет” только этот сервис, который можно быстро восстановить, тогда как остальные сервисы продолжат работать».

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

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

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

Тарас СОРОКА (Уральский банк реконструкции и развития)«Реальный кейс из опыта работы. В одном из телеком-операторов система на монолитной архитектуре, занимавшая ЦОД практически целиком, обновлялась лишь четыре раза в год, настолько процесс этот был продолжительным и сложным. Физической возможности что-то обновить, не остановив call-центр на пять дней, просто не было. И так продолжалось до тех пор, пока вендор не выпустил обновление, позволяющее обновлять монолитную архитектуру по частям и буквально на лету».

Но при этом процесс внесения изменений в монолит более трудоемкий и более сложный с точки зрения технологии. Правда, многое зависит от факторов, влияющих на принятие нового решения именно с точки зрения готовности ИТ и бизнеса и синхронности их взаимодействия, – прокомментировал Антон КУЗНЕЦОВ, ИТ-директор компании «Динекс Русь».

Архитектура – не определяющий критерий выбора

С каких шагов ИТ-компании стоит начать взаимодействие с заказчиком в вопросе выбора архитектуры? Как объяснить, какая именно архитектура более оптимальна для его проекта?

Спикеры, разделившиеся в ходе дискуссии на два лагеря – апологетов монолитной архитектуры и поклонников микросервисной, – сошлись во мнении, что, проводя переговоры с бизнес-заказчиком, с самого начала стоит акцентироваться не на архитектуре, а на более важных моментах. Например, на том, какое именно ИТ-решение и каким образом может удовлетворить ту или иную потребность клиента. Сама архитектура при этом является далеко не первым и даже не вторым критерием в подбираемом для заказчика решении.

Тарас СОРОКА (Уральский банк реконструкции и развития)«Как правило, на рынке ведется поиск готового функционала (решения), который бы отвечал определенным требованиям и критериям, а не какой-то определенной архитектуры. И заказчик принимает решение, скорее, руководствуясь критериями соответствия этого решения своим функциональным требованиям, цене, многим другим параметрам. Но я еще ни разу не сталкивался с тем, чтобы при выборе решения клиент ориентировался именно на его архитектуру».

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

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

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

Все спикеры сделали акцент на одной важной характеристике – скорости приведения приложения в соответствие с требованиями бизнеса, – резюмировал Максим КАРАНКЕВИЧ, директор департамента ИТ в ТД «БАЛТИЙСКИЙ БЕРЕГ», модератор круглого стола. – Но каждый говорил исходя из собственного опыта. Практика показала, что реализовать проекты на базе микросервисной архитектуры готовы крупные компании, которые могут позволить себе содержать несколько сотен ИТ-разработчиков в штате. Внедрять проекты на монолитах проще компаниям со скромными ИТ-отделами в 10-20 программистов.

Итак, к выбору архитектуры нужно подходить разумно – исходя из потребностей бизнеса, требований к скорости, надежности, ресурсам и квалификации разработчиков, резюмировал, подводя итоги круглого стола, Максим КАРАНКЕВИЧ.