Монолит и микросервисы: что лучше?

Development | Amber | Комментировать запись

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

Что такое монолит?

Монолитное приложение (такие также часто называют “монолит”) — это приложение, которое состоит из одной большой кодовой базы, которая включает в себя все компоненты: код фронтенда, код бэкенда и файлы конфигурации. Монолит часто рассматривается как более старый, традиционный метод создания приложений, но на самом деле многие компании по-прежнему разрабатывают приложения именно на основе этой архитектуры. Как правило, монолитные приложения быстрее разрабатываются и проще в управлении, чем приложения на микросервисной архитектуре. Однако монолитные приложения трудно масштабировать и со временем в них могут возникнуть проблемы с поддержкой кодовой базы.

Плюсы монолитных приложений:

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

Минусы монолитных приложений:

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

Что такое микросервисное приложение?

Приложение на микросервисной архитектуре разделено на независимые кодовые базы, и каждая из них выполняет конкретную задачу. Например, один микросервис управляет пользователями, а другой рассчитывает затраты. Каждый компонент можно развертывать и масштабировать независимо от других модулей. Для работы приложения эти модули взаимодействуют друг с другом через интерфейс прикладного программирования (API). По данным исследования компании O’Reilly в 2020 году, использование микросервисов в программировании выросло за последние несколько лет: 28% организаций респондентов использовали микросервисы в течение трех и более лет, а более 61% — в течение одного или нескольких лет. Несмотря на рост их популярности, у микросервисов есть недостатки, которые нужно учитывать.

Плюсы микросервисных приложений:

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

Минусы микросервисных приложений:

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

Микросервисы и контейнеры

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

Читайте также: Краткий обзор Kubernetes

Но микросервисы — это не то же самое, что контейнеры. Микросервисы часто развертываются в системе контейнеризации, поэтому эти два понятия регулярно объединяют. Контейнеры позволяют развертывать микросервисы в легкой и быстрой среде и поскольку контейнеры легко перемещаются, контейнерное приложение обладает чрезвычайной гибкостью. Для разработки микросервисного приложения следует изучить преимущества и недостатки контейнеров.

Как выбрать между монолитным и микросервисным приложением

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

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

Подводим итоги

Разработчики и компании, которые создают приложения, сталкиваются с разными вопросами, однако выбор архитектуры остается одним из главных уже много лет.  Например, Atom Learning (онлайн-платформа для обучения) столкнулись с проблемой масштабирования монолита с течением времени и в конечном итоге решили использовать Kubernetes для создания приложения на архитектуре микросервисов. С другой стороны, микросервисы требуют больше времени, навыков и могут быть слишком сложными для некоторых приложений.