Монолит vs Микросервисы

Приветствую вас, друзья!

Меня зовут Альбина Гараева, я senior системный аналитик с 8-ми летним опытом работы, за это время я приняла участие в 24 проектах. Также являюсь автором и спикером курса “Системный аналитик”, поэтому обучение студентов — одно из моих основных направлений работы.

Эта статья посвящена насущному вопросу о монолитах и микросервисах. Что лучше? Что выбрать?

Рассмотрим плюсы и минусы каждой из архитектур по восьми параметрам:

1. Язык программирования и технологии

Монолит: Один язык программирования, что влечет за собой отсутствие гибкости в языке и технологиях.

Микросервисы: Много языков программирования.

Точнее правильнее сказать, что можно создавать микросервисы как на одном языке, так и каждый микросервис на разных языках.

Это и плюс, и минус одновременно. Плюс, потому что есть гибкость, а минус в том, что нужны сотрудники, знающие разные языки и технологии, т. е. если для монолита достаточно только разработчика, к примеру, на C#, то для микросервисов, которые написаны на C# и Java, нужно будет искать уже нескольких специалистов.

2. База данных (БД)

Монолит: Одна БД

Микросервисы: Много БД

Во-первых, каждый микросервис имеет свою БД.

Во-вторых, эти БД могут быть разные. Например, один микросервис имеет БД Oracle, другой PostgreSQL, а третий вообще нереляционную БД, например, MongoDB.

3. Проектирование

Монолит: Простое проектирование

Взаимодействие между компонентами происходит в рамках одного сервиса.

Микросервисы: Сложное проектирование

Необходимо правильно распределить зоны ответственности каждого сервиса (каждый сервис должен выполнять свой функционал, условно, в сервисе авторизации не должно быть функционала оплаты) .

4. Производительность/скорость

Монолит: Низкая производительность в высоконагруженных системах.

Микросервисы: Высокая производительность, высокая скорость разработки.

5. Отказоустойчивость/надежность

Монолит: Низкая отказоустойчивость/надежность.

Если разработчик выкатил фичу или изменения в существующую и что-то сделал не так, то весь сервис упадет и будет выдавать 500 ошибки.

Микросервисы: Высокая отказоустойчивость/надежность.

Если разработчик выкатил фичу или изменения в существующую и что-то сделал не так, 500 ошибку будет выдавать лишь один сервис из ста, остальные будут успешно работать.

6. Масштабируемость

Монолит: Сложная масштабируемость

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

Микросервисы: Легкая масштабируемость

7. Мониторинг/контроль

Монолит: Легкий мониторинг

Контролировать, как работает 1 сервис легче, чем несколько, а монолит — это 1 большой сервис.

Микросервисы: Сложный мониторинг

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

8. Тестирование

Монолит: Упрощенное тестирование

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

Микросервисы: Усложненное тестирование

Тестировщикам и QA-специалистам помимо тестирования сервиса, который был создан или в который были добавлены изменения, необходимо будет протестировать и смежные сервисы, с которыми взаимодействует новый/изменяемый сервис.

Итого, вывод следующий.

Если компания начинает стартап, дешевле начать с монолита. Также лучше использовать монолит, если компания понимает, что проект будет небольшим по функционалу и вряд ли будет серьезно масштабироваться.

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

Подписывайтесь на мой телеграм-канал «Системный аналитик с нуля», где я регулярно делюсь полезными материалами как для начинающих специалистов, так и для аналитиков с грейдом middle+.