Ключевым фактором при проектировании сложных IT-систем, в том числе микросервисных, является наличие множества одновременно действующих факторов и необходимость постоянной коммуникации с заказчиком.
Монолит или микросервисы? Как ИТ-сообщество в целом, так и отдельные компании, команды и заказчики пытаются найти ответ на вопрос, какой из подходов выбрать для очередного проекта. В зависимости от уровня и характера решаемых задач аргументы за и против приводятся с учетом времени вывода на рынок (time to market), расходов на разработку, удобства поддержки, требований к отказоустойчивости, производительности, масштабируемости и прочего.
Увы, каждый раз, если с проектом что-то пошло не так, звучит один и тот же вопрос: «Может быть имело смысл использовать монолит/микросервисы (нужное подчеркнуть)?» В итоге обсуждения уходят на очередной круг – часто с теми же аргументами и вновь приобретенным «болезненным» опытом применения того или иного подхода.
Мы в SimbirSoft тоже сталкивается с такими же вопросами, проблемами, накапливаем опыт применения монолитов и микросервисов. Все рассуждения будем вести, глядя на ситуацию из микросервисного и облачного мира, выстраивая параллели с тем, как похожие задачи решаются монолитами.
Эта статья – своего рода ретроспектива на тему разработки микросервисов и связанных с этим сложностей, прежде всего на этапе анализа и проектирования. Мы сделали акцент именно на этих этапах, поскольку принимаемые в рамках них решения имеют основополагающее значение.
Как найти баланс между ожиданиями пользователей, заказчика и возможностями архитектуры
Если упростить, то любой проект – это в первую очередь набор пожеланий и ожиданий бизнеса, будущего владельца продукта. Готовый ИТ-продукт с точки зрения его заказчика – набор решений, который автоматизирует бизнес, позволяет увеличить доходы и максимально удовлетворить конечных пользователей. И соответственно то, как ведет себя продукт после релиза, с точки зрения пользователя будет олицетворять заказчика. В свою очередь, ожидания пользователей и заказчиков влияют на то, какому архитектурному стилю будет отдано предпочтение.
Что важно пользователю
Если рассматривать ситуацию с точки зрения конечного пользователя (а именно от его лояльности в большинстве случаев зависит будущее разрабатываемых приложений), то важными факторами, помимо работоспособности всех ожидаемых бизнес-функций, являются следующие нефункциональные требования:
- Производительность
Видение пользователя: страницы загружаются быстро, время ожидания минимально.
Здесь важны размер приложения, число пользователей, количество ожидаемых запросов в секунду, т. е. степень нагруженности. Если приложение небольшое, выполняет ограниченный набор функций, не является нагруженным и по его дальнейшему масштабированию нет четких планов, достаточно использовать монолитную архитектуру. Дробление на микросервисы в угоду красоте подхода и эфемерным перспективам роста на будущее чревато усложнением архитектуры, появлением сетевых взаимодействий и проявлениями прочих недостатков микросервисов там, где этого можно было бы избежать.
Если планируемый размер приложения достаточно велик, то микросервисный подход дает больше пространства для маневра в контексте повышения производительности, в первую очередь обеспечивает гибкое горизонтальное масштабирование и балансировку. При этом компоненты системы взаимодействуют не в рамках одного сервера, а по сети, что сказывается на производительности в негативную сторону. Снизить эти риски позволяет корректная работа с нефункциональными требованиями и подход Design API First – прежде всего за счет выявления картины взаимодействий на ранних этапах и формирования технических концепций обмена данными.
Здесь крайне важна тесная совместная работа аналитика, архитектора и заказчика, в ходе которой можно не только разобрать текущие требования, но и сделать предположения о дальнейшем наиболее вероятном векторе эволюции системы.
- Отказоустойчивость
Видение пользователя: с одной стороны, это возможность в любое время работать с приложением, не наблюдая вместо этого страницу технических работ. С другой стороны, допустим частичный отказ, при котором часть функций недоступны, но в целом с приложением можно продолжать работать.
Отказоустойчивость – один из первых аргументов к использованию микросервисов. Они позволяют вводить необходимую избыточность (например, иметь резервные экземпляры...
