Почему пришло время переходить с монолита на микросервисы

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

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

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

Однако и минусы такой архитектуры проистекают из тех же самых особенностей:

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

Именно этими недостатками монолита компании руководствуются при принятии решения о переходе на микросервисную архитектуру:

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

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

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

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

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

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

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

Для разработчиков преимущества микросервисов очевидны — это на самом деле удобно (особенно, если написано универсально). Не случайно сегодня мы наблюдаем явный тренд на микросервисную архитектуру. Уверен, что рано или поздно большинство крупных корпоративных систем будет разбито на отдельные модули.