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

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

Разница между монолитами, микросервисами и бессерверной архитектурой

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

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

• Монолитная архитектура часто является хорошим вариантом для относительно небольшого или простого приложения с предсказуемой нагрузкой. Это, например, MVP (минимально жизнеспособный продукт) или веб-сайт, обслуживающий статический контент.
• Микросервисы лучше подходят для более крупных и сложных решений, работающих в том числе и в облаке.
• Бессерверная архитектура идеальна для небольших и средних облачных приложений с непредсказуемыми нагрузками.

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

• Технологический стек, включающий, например, языки программирования, базы данных, фреймворки и среды (серверная, клиентская и выполнения), которые вы будете использовать в разработке.
• Архитектурный шаблон, к которому будет применяться стек технологий. Выбор архитектурного решения будет влиять на такие аспекты, как требования к инженерам DevOps, масштабируемость, производительность, затраты на разработку и обслуживание, в том числе стоимость хостинга и облачных вычислений.

Теперь подробно рассмотрим сами архитектурные решения и их плюсы и минусы.

Монолиты

Традиционный подход к созданию приложений путем объединения всех функций в единую сущность, объединяющую интерфейс и серверную часть, по-прежнему актуален. Дело в том, что не всегда есть смысл в усложнении архитектуры. Если требования к сервису (например, к веб-сайту) включают только скорость, доступность и возможность обслуживания статического контента, который находится в свободном доступе, монолитная архитектура для таких целей — вполне естественный выбор. А всё остальное было бы чрезмерным усложнением.

Плюсы монолитов

• Скорость, простота и низкая стоимость создания. Приложения, основанные на монолитной архитектуре, как правило, быстрее, проще и дешевле создавать, поскольку они не требуют синхронизации и объединения сложных частей. Поэтому, если монолитное приложение будет делать то, что от него требуется, без ущерба для продвижения, то можно использовать монолитную архитектуру.
• Удобное тестирование. Протестировать монолитное приложение гораздо проще, чем микросервисы или бессерверное. Можно запустить и протестировать приложение на сервере разработчика или в промежуточной среде, а также применить стандартный процесс развертывания для проверки изменений перед запуском приложения в продакшн.
• Простая инфраструктура. Монолитные приложения используют один сервер для внешнего интерфейса, серверной части и базы данных, что упрощает требования к инфраструктуре. А ​​для повышения скорости, масштабируемости, доступности и безопасности монолитных веб-приложений можно добавить сеть доставки контента (например, Cloudflare).
• Снижение затрат на поддержку. При монолите вам нужно поддерживать только один репозиторий. Вам также понадобится только один конвейер тестирования и развертывания, что может значительно снизить затраты, поскольку создание, настройка и обслуживание нескольких конвейеров выйдет дороже, ведь нужно будет обеспечить согласованность между ними. Все данные, используемые приложением, также могут храниться в единой базе данных.
• Мониторинг. Простая инфраструктура обеспечивает дополнительное преимущество в виде упрощения мониторинга.
• Легкое управление транзакциями и поддержка целостности данных. Тот факт, что монолитные приложения обычно используют одну базу данных, означает, что здесь проще управлять транзакциями и поддерживать целостность данных.

Минусы монолитов

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

Примеры монолитов

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

Микросервисы

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

Плюсы микросервисов

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

Минусы микросервисов

• Сложность синхронизации. Распределенная система, такая как микросервисы, неизбежно создает дополнительную сложность, поскольку ее части необходимо синхронизировать таким образом, чтобы они могли работать как единая программная система. И если службы разделены между серверами, вам придется подготовить инфраструктуру для взаимодействия микросервисов.
• Сложность тестирования. С одной стороны, тестировать отдельные микросервисы проще, с другой, необходимость тестировать каждый сервис по отдельности может значительно усложнить приложение по мере его масштабирования. А необходимость тестировать и поддерживать связь между службами создает дополнительную сложность.
• Более высокие первоначальные затраты. Хотя попытки значительно масштабировать монолитное приложение могут оказаться сущим кошмаром, который приводит к резкому росту прямых затрат на разработку, архитектура микросервисов требует более высоких первоначальных затрат. Для каждого микросервиса требуется своя команда разработчиков (хотя одна команда может отвечать и за несколько). Кроме того, придется наладить и процесс автоматического тестирования и развертывания (CI/CD). Всё это приводит к более высоким первоначальным затратам.
• Потребность в DevOps. Распределенная система, такая как микросервисы, требует квалифицированной оркестровки, обычно с использованием Kubernetes и других инструментов и процессов DevOps. Это означает, что вам нанять хотя бы одного инженера DevOps, что также увеличит расходы.

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

Примеры микросервисов

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

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

Бессерверная архитектура

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

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

• Гибкость. Разделение приложений с помощью облачных функций дает такие же преимущества гибкости, как и микросервисы.
• Экономия на ресурсах. Бессерверные функции запускаются только тогда, когда они необходимы, что потенциально позволяет сэкономить значительные ресурсы. Ведь служба в микросерверной архитектуре доступна постоянно, тогда как у функции есть жизненный цикл — она вызывается, выполняется и «убивается», как только выполняет свою работу.
• Экономия на инфраструктуре. Всю инфраструктуру выделяет облачный провайдер, что означает, что разработчики могут полностью сосредоточиться на коде. А еще функции, размещенные на бессерверной платформе, можно использовать и в нескольких приложениях. Например, если у компании есть несколько приложений, каждое из которых содержит профили пользователей, для которых загружаются изображения этих профилей, то для них можно использовать одну и ту же функцию.
• Масштабируемость. Как и в случае с микросервисами, модульная организация бессерверных приложений упрощает разработчикам масштабирование приложений. В облаке над новыми функциями можно работать независимо, а затем постепенно добавлять их в работающее приложение.
• Надежность и доступность. Опять же, как и в случае с микросервисами, приложение, разбитое на слабо связанные функции, создает гораздо меньше зависимостей между ними, чем в монолитной архитектуре. Поэтому, если одна функция дает сбой, приложение продолжит работу. А провайдер, заботящийся о своей инфраструктуре, обеспечивает дополнительное снижение потенциальных точек отказа.

Минусы бессерверной архитектуры

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

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

Видов приложений, которые можно полностью создавать в облаке, довольно много. Поэтому сосредоточимся на конкретных службах, которые предлагаются облачными провайдерами в качестве бессерверных функций или FaaS (Function as a Service). Вот одни из самых популярных:

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

Стоит добавить, что есть и такие платформы, которые предлагают пользователям писать и запускать свои функции в облаке. Это, например, AWS Lambda, Google Cloud или Microsoft Azure.

Микросервисы или бессерверная архитектура? Микросервисы И бессерверная архитектура!

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

И хотя традиционная монолитная архитектура является достаточно эффективным решением для относительно простых приложений (таких, как веб-сайты, обслуживающие статический контент), полный переход на микросервисы и бессерверные облачные функции большинства разработчиков — вопрос ближайших нескольких лет. Так, согласно данным Яндекса, к 2025 году от использования монолитов полностью откажутся уже около 85% компаний, хотя еще в 2020 году их доля составляла менее 30%.

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