Разделяй и властвуй: монолиты против микросервисов в разработке проектов

В 2021 году 85% респондентов опроса Statista из крупных организаций со штатом 5 000 и более сотрудников заявили, что уже используют микросервисы. Это говорит о том, что крупные организации с большей вероятностью получат выгоду от использования микросервисов в своей деятельности. Но действительно ли все так просто?

Возможно, в теме монолитов против микросервисов, вас интересует вопрос: Проектировать изначально или переходить по необходимости?

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

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

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

Интересно, что, согласно отчету Gartner, почти 74 % организаций в настоящее время используют архитектуру микросервисов. А 23% руководителей организаций еще не используют, но планируют переход на микросервисы. Многие организации (респонденты опроса) управляют менее чем 100 микросервисами - и довольны этим количеством.

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

Архитектура монолита

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

Вот некоторые ключевые характеристики монолитной архитектуры:

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

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

Преимущества монолитной архитектуры

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

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

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

Архитектура монолита позволяет одной кросс-функциональной команде владеть всей кодовой базой и нести за нее ответственность. Это также вносит ясность в процессы управления.

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

Трудности работы с монолитами

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

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

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

Архитектура микросервисов

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

То есть архитектуру микросервисов можно определить следующими характеристиками:

• Децентрализованное управление. Каждый микросервис управляется и контролируется независимо, что облегчает внесение изменений и обновлений в отдельные сервисы, не затрагивая остальную часть системы.
• Свободное соединение. Микросервисы слабо связаны между собой и взаимодействуют друг с другом через четко определенные интерфейсы. Это облегчает замену или модификацию отдельных сервисов, не затрагивая остальную систему, но может негативно повлиять на процесс отладки.
• Легкая масштабируемость. Архитектура микросервисов отличается высокой масштабируемостью, поскольку каждый сервис может быть масштабирован по отдельности в соответствии с требованиями приложения.

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

Особенности микросервисов

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

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

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

Эффективность использования ресурсов достигается за счет легкой масштабируемости: инфраструктура хостинга сервисов может самостоятельно увеличиваться/уменьшаться в зависимости от спроса на сервис.

Трудности работы с микросервисами

Однако не стоит считать, что микросервисы не имеют недостатков, поскольку любая архитектура имеет свои подводные камни:

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

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

Монолиты против микросервисов в процессе разработки

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

Кратко различия микросервисов и монолитных архитектур можно обозначить по некоторым процессам разработки программного обеспечения.

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

Когда нужно переходить от монолита к микросервисам?

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

• Необходимость разделения между разными серверами.

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

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

• Необходимость разделения на составные части по функциям.

Если требуется приложение разделить на составные части или небольшие приложения, то лучше использовать микросервисы. Например, Google Карты, Google Classroom и Google Диск не имеет смысла держать «в одной корзине».

• Повышение уровня безопасности.

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

• Отказоустойчивость.

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

• Упрощение поддержки.

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

• Упрощение разработки и тестирования.

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

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

Где размещать микросервисы?

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

Так, можно четко определить разные опции размещения микросервисов:

• Собственные мощности. Микросервисы можно размещать на собственных серверах или арендовать серверы. Такой вариант дает наибольший контроль над средой, но может быть более дорогим и сложным в управлении. Однако и эта проблема решается надежным хостинг-провайдером с гибкими тарифами.
• Публичное облако. Для размещения микросервисов можно использовать общедоступное облако, что может быть экономически эффективным и масштабируемым вариантом, но у вас будет меньше контроля над средой.
• Гибридное облако. Микросервисы можно размещать в гибридной облачной среде, которая сочетает в себе как локальные, так и публичные облачные ресурсы. Это может дать вам преимущества обеих сред, но также может быть более сложным в управлении.

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

Когда стоит развивать проект в архитектуре монолита?

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

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

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

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

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

Заключение

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

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

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

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