Microservices или serverless: какую архитектуру выбрать?

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

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

Что такое microservices

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

Что такое serverless

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

Организация против выполнения

Ключ к тому, чтобы не запутаться, — понять, что они сравнивают разные вещи. Microservices отвечают на вопрос, как я разделяю своё приложение; serverless отвечает, где и как я выполняю свой код. На деле они не взаимоисключающи: можно иметь microservices, выполняемые в serverless, microservices в контейнерах или простое приложение в serverless без microservices. Правильный вопрос не «то или другое», а какая структура нужна моей системе и какая модель выполнения подходит каждой её части.

Ключевые различия

Подводя итог, вот факторы, в которых разница между обоими понятиями заметна сильнее всего:

• Природа: microservices организуют; serverless выполняет.
• Контроль: больше в microservices (особенно в контейнерах).
• Эксплуатация: serverless почти не требует управления инфраструктурой.
• Стоимость: serverless выигрывает при переменных нагрузках; постоянная благоприятствует другим моделям.
• Сложность: высокая в microservices; низкая на старте в serverless.
• Совместимость: их можно использовать вместе без проблем.

Ошибка слишком ранней переусложнённости

Самая дорогая ошибка с этими двумя понятиями — внедрять их до того, как они понадобятся, привлекаясь их репутацией современных. Разделение небольшого приложения на множество microservices с первого дня умножает сложность (коммуникацию, развёртывания, мониторинг), не давая преимуществ, которые появляются только при определённом масштабе. Точно так же навязывание всего в serverless может натолкнуться на его пределы при тяжёлых и постоянных нагрузках. Повторяющийся опыт в отрасли ясен: начать просто, измерять и разделять или менять модель только тогда, когда реальная боль это оправдывает, гораздо рентабельнее, чем переусложнять в начале. Архитектура проще, чем вам кажется, что понадобится, обычно оказывается правильным решением, потому что вы всегда можете развить её, когда появятся конкретные проблемы.

Как выбрать

Для большинства начинающихся проектов разумнее всего начать просто: хорошо организованное приложение, часто в serverless или в управляемых контейнерах, не бросаясь в microservices до того, как они понадобятся. Внедряйте microservices, когда система действительно растёт: много команд, части с очень разными потребностями масштабирования или компоненты, которые стоит разворачивать по отдельности. И используйте serverless для переменных или event-driven нагрузок, сочетая его с контейнерами для постоянных. Проектируйте под реальную проблему, а не под модный ярлык.

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