Монолитное приложение — единый общий модуль, в то время как микросервисная архитектура представляет собой набор небольших независимо развертываемых сервисов. Обсудим, какой вариант лучше выбрать конкретному бизнесу.
Монолитная архитектура: плюсы и минусы
Главный плюс монолитной архитектуры — упрощенный процесс разработки. По сей день существует довольно большое количество инженеров-программистов, привыкших работать в парадигме единой кодовой базы. Проекты с монолитом, как правило, требуют низкого порога входа для новых участников. В таком случае разработчикам гораздо легче проводить отладку кода, тестировщикам — писать интеграционные тесты, а инженерам эксплуатации — деплоить приложения на тестовые и продакшн-окружения.
Еще одним важным преимуществом монолитных приложений является производительность: так как все части единой кодовой базы имеют общую память, взаимодействие между ними происходит очень быстро, без расходов на сетевые издержки и операции ввода-вывода. Также в монолитной архитектуре проще интегрировать единые подходы по внедрению сквозных системных сервисов: логирование, безопасность, трекинг производительности приложения и др.
Недостатками монолита является тот факт, что в процессе развития проект на нем становится сложным для понимания: с ростом кодовой базы увеличивается количество классов, методов и функций, цепочки вызовов удлиняются. Скорость разработки замедляется, программистам требуется все больше времени для понимания работы и взаимодействия с частями монолита.
Также появляются проблемы с масштабированием — монолитные приложения имеют ограниченные возможности по расширению функционала, и при росте числа пользователей, особенно объемном, задача поддержания сервиса на высоком уровне качества становится трудновыполнимой — растет время выполнения запросов и число ошибок.
Единая точка отказа — еще один весомый минус монолита, так как все его части критично связаны между собой. Деградация в одной из них обычно приводит к полному отказу в обслуживании всей системы. Также имеет место повышенная подверженность внешним угрозам, например, уязвимость к кибератакам, которая является следствием предыдущего недостатка из-за того, что монолит обычно представляет собой единую точку отказа.
Отсутствие гибких возможностей изменений в логике работы приложений при поступлении принципиально новых требований от заказчиков по причине большого размера сильно связанной кодовой базы — еще один минус монолита. Зачастую именно он делает новые бизнес-требования невыполнимыми в реализации.
Наверное, самое неудобное в использовании монолита — сложности с обновлением технического стека. При необходимости расширения функциональности приложения (даже в случае добавления самой простой опции) и для новой задачи лучше подходит новый язык программирования или фреймворк, требуется трудоемкая переработка всего монолитного приложения, что для бизнеса зачастую оказывается неприемлемым. Разработчики ограничены в выборе новых библиотек, фреймворков и языков программирования, так как в монолитных приложениях подобные изменения внедрять очень трудно. Это становится серьезной проблемой, когда используемый в настоящее время на проекте фреймворк программирования устаревает и на рынке трудно найти специалистов по вышедшим из трендов технологиям.
Микросервисы: плюсы и минусы
Альтернативой монолиту выступают микросервисные разработки, где каждый сервис может масштабироваться и обновляться независимо от остальных, что делает процесс разработки быстрым и предсказуемым. Используя микросервисы, приложение можно расширять горизонтально, в этом случае размер каждого микросервиса может увеличиваться независимо от других по мере изменения потребностей заказчика. Как правило, горизонтальное масштабирование сервисов является для бизнеса менее затратным, чем вертикальное, которое характерно для проектов на монолите. При вертикальном масштабировании приложение развивается за счет наращивания мощности аппаратных ресурсов, и довольно часто проекты упираются в потолок по дальнейшему масштабированию.
Усиленная гибкость микросервисов позволяет команде ИТ-специалистов с большей легкостью вносить изменения в работу сервисов, меняя архитектуру и технологический стек в каждом из нем. В частности, любой из сервисов может быть написан на своем языке программирования без какого-либо влияния на другие. Это позволяет разработчикам основывать свой выбор стека технологий на том, что наиболее подходит для конкретного сервиса и задач, которые он выполняет. Это все вместо того, чтобы зацикливаться с самого начала проекта на одном единственном языке или фреймворке, который часто может не подходить для некоторых других частей по мере развития бизнеса.
Возможность независимых обновлений частей приложения позволяет внедрять лучшие практики DevOps для улучшения качества доставки программного обеспечения — непрерывную интеграцию (continuous integration, CI) и непрерывное развертывание (continuous deployment, CD), что также позволяет микросервисной архитектуре заработать дополнительные баллы. Улучшенная устойчивость и стабильность проектов на ней обусловлена тем, что при правильном проектировании отсутствуют единые точки отказа. Сбой в одном из сервисов не влечет за собой отказ в обслуживании системы в целом. Также разработчики получают возможность быстрее находить ошибки в изолированных сервисах, что позволяет быстро восстанавливать системы после сбоев.
При этом у микросервисов тоже есть свои минусы, например, в начале развития проекта их использование будет неэффективно. В состоявшихся проектах количество микросервисов может исчисляться десятками и сотнями, но поддерживать такую систему и процессы разработки становится сложной задачей, которая включает в себя построение идеальных процессов взаимодействия между командами инженеров разработки, эксплуатации и тестирования.
Также процессы тестирования и поиска ошибок в распределенных системах усложняются. Зачастую в проектах с большим количеством сервисов не очевидно, в каком именно из них локализуется основная ошибка. Она может быть даже на стыке между несколькими сервисами. Быстрому поиску причины ошибки способствует внедрение инструментов динамического распределенного трейсинга, что требует времени и усилий.
Рост расходов на поддержку и эксплуатацию также является недостатком микросервисов. Так как каждому сервису требуется, как правило, своя база данных и другие компоненты, это все влечет за собой рост расходов на аппаратные и кадровые ресурсы. При развертывании в облаке расходы на содержание часто бывают выше. В проектах с микросервисной архитектурой с большим количеством сервисов бывают высокие расходы на взаимодействие между сервисами, установку сетевых соединений и прочих операций, что влияет на перфоманс системы в целом.
Как бизнесу и инженерам определиться?
К сожалению, не существует универсального совета, все зависит от проекта, функциональных и нефункциональных требований. Очень важны параметры бюджета, возможности по найму команды разработчиков, прогнозы по росту количества фич и числа пользователей в проекте.
Если коротко, то монолитная архитектура приложений подходит для:
- простых приложений с ограниченной функциональностью;
- стартапов и бизнесов, работающих с небольшой командой разработчиков без планов по росту их числа;
- когда требуется очень быстрый запуск продукта;
- для быстрого тестирования гипотез и создания mvp-версий продуктов.
Микросервисная архитектура эффективна там, где:
- цифровой продукт имеет сложную бизнес-логику с несколькими доменами и постоянно развивается;
- бизнес-концепция проекта стабильна, верифицирована и дает стабильный прирост клиентов и трафика.
Подводя итоги можно сказать, что если проект только стартует и с предметной областью инженерная команда не очень хорошо знакома, правильным решением будет начать с монолитной архитектуры, но при этом сохранить модульность компонентов. Это облегчит задачу, если впоследствии будет принято решение разделить монолит на несколько сервисов.
Команда разработки «Детского мира» — крупнейшего интернет-магазина (топ-6 в России по количеству онлайн-заказов в 2021 году и топ-4 по трафику в мире в сегменте «уход за детьми») пошла именно по этому пути. Начав с модульного монолита на базе решения SAP Hybris в 2016 году, мы пришли к микросервисной архитектуре, основанной на десятке отдельных сервисов, составляющих единую e-commerce-платформу собственной разработки. Сейчас мы среди мировых лидеров (согласно методике DORA для оценки производительности доставки ПО) индустрии и по количеству релизов на сайте и в приложениях: почти каждую неделю там появляются новые фичи, при этом имеем низкий процент ошибок при изменениях и быстрое время восстановления после сбоев.
