Каковы плюсы и минусы монолитной и микросервисной архитектуры при разработке ИТ-продуктов?

Микросервисы

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

Плюсы микросервисов:

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

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

• Ассортимент технологических стеков. В виду того, что компоненты такой архитектуры могут быть написаны на разных языках программирования, для разработки и поддержки приложения необходима команда, обладающая более широким набором компетенций.
• Сложная стандартизация. Поскольку знания разделены между несколькими командами, и при этом каждая отвечает за свой сервис или набор сервисов, это приводит к отсутствию единого стандарта разработки и централизованного процесса обновления. С другой стороны, такой подход за счет наличия нескольких практик в разных командах позволяет выбрать лучший, и адаптировав его, распространить на остальных.
• Оркестрация и шардирование. Если мы имеем несколько экземпляров одного сервиса, то чтобы избежать простоя во время обновления, экземпляры сервисов можно обновлять по одному. При этом надо поддерживать старую версию API и настраивать структуру взаимодействия. Если у нас несколько экземпляров одного и того же сервиса, то получается, что у нас есть несколько потребителей сообщений, надо настраивать маршрутизацию таким образом, чтобы, например, все сообщения, относящиеся к одному заказу в интернет-магазине, попадали к одному и тому же экземпляру сервиса.

Монолит

«Монолит» — архитектурный стиль, в котором вся логика выполнения целевого действия выполняется в рамках одного процесса взаимодействия между клиентом, базой данных и сервером.

Плюсы монолита:

• Производительность. Правильно написанный монолит состоит из модулей, которые легко «распилить» на микросервисы. Сообщение между модулями происходит через память, поэтому оно быстрее, чем, например, через брокеры.
• Единый технологический стек. Для разработки и поддержки приложения достаточно иметь команду, обладающую схожим набором компетенций, при этом члены команды легко дополняют и заменяют друг друга. Процессы написания кода и код-ревью выполнять проще, поскольку выполняются они в рамках одного компонента.
• Единая среда данных. Это означает, что каждый компонент системы имеет физический доступ к данным из единого источника. При этом данные целостны, и нет потребности в их синхронизации. Архитектуру, состоящую из набора микросервисов, имеющих по одному экземпляру и обращающихся к одной централизованной БД, нельзя назвать эталоном микросервисной архитектуры, т.к. у приложения в целом появляется единая точка отказа — база данных.

Минусы монолита:

• Время простоя при обновлении. Даже при минимальных доработках необходима приостановка работы и пересборка всего монолита или как минимум его серверной части. Если сборка осуществляется в рамках CI/CD, то удастся существенно сократить это время.
• Масштабируемость. Речь идет не о том, что монолит нельзя масштабировать. Само масштабирование выполняется по вертикали, за счет увеличения ресурсов, используемых приложением в целом. Такой подход создает сложность при необходимости увеличить производительность одного процесса, т.к. далеко не все приложения позволяют это сделать.
• Зависимость компонентов плохо влияет на производительность. Отсутствие возможности выделить ресурсоемкую операцию в отдельный процесс создает проблемы при запуске такой операции у всех пользователей системы.

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

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

• нет уверенности в успешности гипотезы;
• задачи для команды разработки сформулированы расплывчато;
• существует строгое ограничение по ресурсам и этих ресурсов немного.

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

Сценарий 2. Корпоративные информационные системы. Крупные системы управления предприятием ERP (SAP или 1С) и пр. построены исходя из принципов монолитной архитектуры, либо стремятся к соответствию этим принципам. Внутри одного приложения возможно разделение на модули, каждый из которых выполняет свою бизнес-функцию, но при этом данные для таких систем привязаны к самому приложению и взаимозависимость модулей (один модуль потребляет данные другого и производит данные для третьего) не позволяет назвать такие модули микросервисами.

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

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

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