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

Предлагаем разобраться, почему тренд на микросервисы захватил мир IT и так ли все в нем просто. Мы подготовили небольшое практическое руководство по выбору архитектуры.

Сначала немного цифр. Согласно различным международным исследованиям, более 70% крупных компаний к 2025 году внедрили микросервисную архитектуру в своих проектах. Gartner к 2026 году прогнозирует использование микросервисов в сегменте enterprise на уровне 90%. Если посмотреть на новые проекты уже сейчас, то мы увидим, что 62% enterprise-проектов стартует с микросервисов, 28% компаний используют гибридный подход и лишь 10% – прежние монолиты. Предлагаем разобраться, почему тренд на микросервисы захватил мир IT и так ли все в нем просто.

Мы подготовили небольшое практическое руководство по выбору архитектуры. Чек-лист поможет определить, когда внедрение микросервисов действительно оправдано.

Что такое микросервисы: основные принципы архитектуры

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

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

Представьте себе IT-архитектуру современного банка (см. схему № 1), где распределение компонентов архитектуры по слоям наглядно демонстрирует требования, предъявляемые к этой архитектуре и к компонентам различных архитектурных слоев.

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

Схема № 1. Условный пример архитектуры современного банка

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

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

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

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

Таким образом, ключевые аспекты архитектуры микросервисов:

• четкие границы каждого сервиса (компонента);
• независимая работа команд разработки над сервисами;
• автономная работа сервисов;
• гибкий подход к разработке и гибридные сценарии развертывания сервисов.

Микросервисы: плюсы и минусы

Плюсы использования микросервисов:

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

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

• Повышение надежности системы. Использование распределенных сервисов, интегрированных в единую архитектуру, повышают надежность системы.

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

Микросервисный подход не лишен недостатков:

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

• Высокая стоимость. Стоимость разработки и внедрения микросервисов, как правило, проигрывает в стоимости монолитов.

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

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

• Необходимость новых компетенций в команде разработки. Для эффективной разработки решений в микросервисной архитектуре нужны специалисты, способные поддерживать новую инфраструктуру и управлять ею. Новые реалии потребовали отдельных DevOps-инженеров со специфическими компетенциями.

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

Когда пора внедрять микросервисную архитектуру

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

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

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

• Сроки разработки. На разработку монолитной архитектуры небольших проектов много времени не понадобится. Но если вы видите, что сроки разработки увеличиваются и время на интеграцию новых функций в существующий код растет, то есть повод задуматься. На это указывает и время поддержки системы, которое, по мнению экспертов, не должно превышать 30% времени, требующегося на разработку.

О всех преимуществах систем low-code на примере экосистемы Digital Q от Диасофт вы сможете подробнее узнать здесь.

Ключевые выводы

1. Для больших распределенных команд разработки микросервисная архитектура уже не выбор, а необходимость.

2. Монолитная архитектура предпочтительнее для небольших проектов, где важны скорость разработки и простота управления.

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

4. Для работы с микросервисами команде необходимы новые компетенции.

---

Читайте другие материалы:

Александр Сахаров, «Диасофт»: Экосистема low-code разработки Digital Q радикально ускоряет разработку микросервисных приложений

Digital Q: почему будущее разработки — за low-code платформами

Эксперт «Диасофт» рассказал об инструментах для разработки на форуме «Открытые инновации 2024»