Монолитная vs Микросервисная архитектура в IT-продуктах для малого и среднего бизнеса

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

Зачем потенциальному заказчику IT-продукта разбираться в архитектуре ПО, если можно просто довериться разработчику? Но выбор подхода необходимо осуществлять до разработки, и от этого выбора зависят требования к подрядчику.

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

Монолитное ПО — это софт, представляющий собой сервис с единой базой кода, в котором реализована вся требуемая бизнес-логика. Да, в монолите может быть разделение на frontend и backend, однако это не превращает его в микросервис.

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

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

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

Простой пример:

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

• клиенты;
  
• счета.
  
  

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

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

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

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

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

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

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

Таблица сравнение монолита и микросервисной архитектуры:

Если хоть на один из вопросов ответ "Да", то выбирайте монолит:

• Вам кажется, что команда проекта будет меньше десяти разработчиков?
  
• Бюджет на первую версию проекта не превышает 10 миллионов рублей?
  
• Вы не хотите, чтобы проект был реализован на большом количестве разных технологий, а предпочитаете один технологический стек?
  
• Вы хотите поскорее начать пользоваться первой версией системы?