Serverless-архитектура: что это такое и когда она выгоднее монолита

Serverless давно стал обычной частью продакшена. По отчёту Datadog State of Serverless, бессерверные технологии используют 70% клиентов Datadog, работающих в AWS, 60% клиентов в Google Cloud и 49% в Azure. В России модель доступна в отечественных облаках: например, Yandex Cloud Functions принимает функции на популярных языках и выставляет счёт в рублях. Общее определение подхода есть в Википедии.

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

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

Что такое serverless-архитектура простыми словами

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

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

Что берёт на себя провайдер:

• выделение вычислительных ресурсов и запуск кода по событию;
• операционную систему, патчи безопасности и обновления среды выполнения;
• горизонтальное масштабирование: от нуля экземпляров до сотен и обратно;
• размещение в нескольких зонах доступности и перезапуск при сбоях;
• учёт потребления и выставление счёта по фактическому использованию.

Что остаётся на команде:

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

Откуда термин и чем serverless отличается от облачного хостинга

Serverless — следующая ступень абстракции в облаке после IaaS и PaaS. В модели IaaS (инфраструктура как сервис) вы арендуете виртуальную машину и сами настраиваете на ней всё — от ОС до веб-сервера. В PaaS (платформа как сервис) провайдер даёт готовую среду для приложения, но оно работает постоянно, и вы платите за выделенные мощности, даже когда запросов нет.

В FaaS (функции как сервис) единицей развёртывания становится отдельная функция. Она не работает, пока её не вызвали, и при отсутствии трафика счёт за вычисления равен нулю. Именно это отличает serverless от обычного облачного хостинга: вы платите не за «включённый сервер», а за конкретные вызовы и миллисекунды работы кода.

Как работает бессерверная архитектура

Бессерверная архитектура работает по событийной модели: каждая функция спит, пока не произойдёт событие, на которое она подписана. Жизненный цикл одного вызова выглядит так:

1. Событие (триггер). HTTP-запрос через API Gateway, сообщение в очереди, загрузка файла в объектное хранилище, запись в базу данных или срабатывание таймера (cron).
2. Подготовка среды. Провайдер находит свободный экземпляр функции или поднимает новую изолированную среду: контейнер или микро-виртуальную машину с нужной средой выполнения и вашим кодом.
3. Выполнение. Функция получает данные события и отрабатывает. Она stateless, то есть не хранит состояние между вызовами: всё, что нужно сохранить, уходит в базу, кэш или хранилище.
4. Ответ. Результат возвращается вызывающему сервису или пользователю, либо функция порождает новое событие: кладёт сообщение в очередь, пишет файл.
5. Простой или удаление. Экземпляр какое-то время остаётся «тёплым» на случай следующего запроса, а потом провайдер его удаляет.

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

FaaS — функции как сервис

FaaS (Function as a Service) — вычислительная часть serverless: вы загружаете код функции, указываете среду выполнения (Python, Node.js, Go, Java и другие), объём памяти и триггер. Типичные примеры — AWS Lambda, Yandex Cloud Functions, Google Cloud Functions и Azure Functions. По данным Datadog, больше половины вызовов Lambda приходится на Python и Node.js: лёгкие рантаймы быстро стартуют и хорошо подходят для коротких задач.

BaaS — готовые облачные сервисы

BaaS (Backend as a Service) — управляемые сервисы, которые закрывают типовые задачи бэкенда без собственного кода и серверов: базы данных, авторизация пользователей, объектное хранилище, очереди сообщений, push-уведомления. На практике serverless-приложение почти всегда комбинирует FaaS и BaaS: функции содержат бизнес-логику, а данные, файлы и авторизация живут в готовых облачных сервисах.

Холодный и тёплый старт

Холодный старт (cold start) — задержка при первом вызове функции, когда провайдеру нужно создать новую среду, загрузить код и инициализировать рантайм. Тёплый старт — повторный вызов уже подготовленного экземпляра, он проходит заметно быстрее. Длительность холодного старта зависит от языка и объёма зависимостей: по наблюдениям Datadog, у функций на Java он примерно в три раза дольше, чем у функций на Python.

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

Serverless vs сервер, контейнеры и микросервисы: сравнительная таблица

Serverless отличается от VPS и контейнеров прежде всего тем, кто управляет инфраструктурой и за что вы платите. В таблице сравниваем три модели развёртывания бэкенда по ключевым для бизнеса параметрам.

Параметр	VPS / выделенный сервер	Контейнеры (Kubernetes)	Serverless (FaaS)
Кто управляет инфраструктурой	Команда: ОС, обновления, резервирование	Команда управляет кластером (в managed-варианте провайдер берёт часть работы)	Провайдер полностью
Модель оплаты	Фиксированная аренда, в том числе за простой	За узлы кластера, в том числе за простой	За вызовы и время выполнения, простой бесплатен
Масштабирование	Вручную или скриптами, в пределах мощности сервера	Автоматическое, но нужно настроить и держать резерв узлов	Автоматическое, от нуля, в пределах квот
Время до продакшена	Среднее: нужно настроить окружение	Самое долгое: кластер, манифесты, сеть	Минимальное для небольших сервисов
Задержка	Стабильная, без холодного старта	Стабильная, если под уже запущен	Возможен холодный старт
Лимит времени выполнения	Нет	Нет	Есть: от минут до часа в зависимости от платформы
Состояние (state)	Можно держать в памяти	Можно, но обычно выносят	Только во внешних сервисах
Vendor lock-in	Низкий	Низкий: Kubernetes переносим	Высокий: триггеры и сервисы у каждого облака свои
Отладка	Привычная	Средней сложности	Сложная: распределённые вызовы, трассировка обязательна
Для каких задач	Небольшие стабильные проекты, legacy	Крупные системы с постоянной нагрузкой	Неравномерная нагрузка, события, API, MVP

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

Если вы только выбираете между монолитом и распределённой системой, начните с этого вопроса: подробный разбор есть в статье «Монолит или микросервисы для веб-приложения». Serverless имеет смысл обсуждать, когда понятно, какие части системы будут жить отдельно.

Преимущества serverless для бизнеса

Главное преимущество serverless для бизнеса — оплата только за фактическую работу кода и отсутствие расходов на обслуживание серверов. Вот что это даёт на практике:

• Нет оплаты простоя. Если сервисом пользуются днём, а ночью он простаивает, ночью вы не платите за вычисления. Для внутренних инструментов, B2B-сервисов с рабочим графиком и сезонных проектов это ощутимая экономия.
• Автомасштабирование. Всплеск трафика после рассылки или рекламной кампании обрабатывается параллельными экземплярами функции. Не нужно заранее покупать мощности «на пик», которые большую часть времени стоят без дела.
• Быстрый вывод в продакшен. Функцию можно развернуть за часы: не нужно настраивать серверы, балансировщики и мониторинг ОС. Для MVP и проверки гипотез это сокращает путь до первых пользователей.
• Меньше DevOps-рутины. Патчи операционной системы, обновления рантайма и замена упавших машин — зона провайдера. Инженеры тратят время на продукт, а не на администрирование.
• Встроенная отказоустойчивость. Провайдеры запускают функции в нескольких зонах доступности и автоматически перезапускают экземпляры при сбоях.
• Фокус команды на продукте. Небольшая команда может поддерживать систему, для которой при классическом подходе понадобился бы отдельный администратор.

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

Недостатки serverless — обратная сторона его преимуществ: вы отдаёте провайдеру контроль над инфраструктурой и принимаете его ограничения. Основные риски, с которыми мы сталкиваемся в проектах:

• Холодный старт. Первый вызов после простоя может занимать заметно больше времени. Для чувствительных к задержке API это нужно учитывать сразу.
• Лимиты платформы. У функций ограничены время выполнения, объём памяти, размер запроса и ответа, количество параллельных запусков. Долгая обработка видео или тяжёлый отчёт могут просто не уложиться.
• Vendor lock-in. Триггеры, форматы событий, сервисы данных и права доступа у каждого облака свои. Переезд к другому провайдеру означает переписывание обвязки, а иногда и части логики.
• Сложная отладка. Запрос проходит через API Gateway, несколько функций, очередь и базу данных. Без распределённой трассировки найти причину ошибки трудно, а локально воспроизвести облачное окружение целиком почти невозможно.
• Рост счёта при постоянной нагрузке. Когда функции работают круглосуточно под высокой нагрузкой, оплата за каждый вызов и гигабайт-секунду может превысить стоимость выделенного сервера.
• Stateless и соединения с базой. Сотни параллельных экземпляров открывают сотни соединений с базой данных и могут исчерпать её лимит. Нужны пулы соединений, прокси или serverless-базы.
• Безопасность и IAM. Много функций — большая поверхность атаки. Каждой функции нужны минимально необходимые права, а избыточные роли «на всякий случай» — частая уязвимость.

Сколько стоит serverless: расчёт на примере

Стоимость serverless складывается из двух частей: платы за количество вызовов и платы за вычислительное время, умноженное на объём памяти. Посчитаем на тарифах Yandex Cloud Functions по прайсу Yandex Cloud на сентябрь 2026 года:

• бесплатно каждый месяц: 1 млн вызовов и 10 ГБ×час вычислений;
• сверх бесплатного объёма: 18,97 ₽ за 1 млн вызовов;
• 6,48 ₽ за 1 ГБ×час (объём памяти функции в гигабайтах, умноженный на время работы в часах);
• время выполнения округляется вверх до 100 мс.

Формула для месяца: ГБ×час = число вызовов × память (ГБ) × длительность (с) / 3600. Итог = (вызовы − 1 млн) × 18,97 ₽ / 1 млн + (ГБ×час − 10) × 6,48 ₽. Рассмотрим три типичных сценария.

Сценарий	Нагрузка	ГБ×час в месяц	Расчёт	Итого в месяц
A. Внутренний сервис, вебхуки CRM	300 тыс. вызовов, 256 МБ, 500 мс	300 000 × 0,25 × 0,5 / 3600 ≈ 10,4	вызовы в бесплатном объёме; (10,4 − 10) × 6,48 ≈ 3 ₽	≈ 3 ₽
B. API мобильного приложения	3 млн вызовов, 128 МБ, 200 мс	3 000 000 × 0,125 × 0,2 / 3600 ≈ 20,8	(20,8 − 10) × 6,48 ≈ 70 ₽ + 2 × 18,97 ≈ 38 ₽	≈ 108 ₽
C. Нагруженный сервис 24/7	30 млн вызовов, 512 МБ, 300 мс	30 000 000 × 0,5 × 0,3 / 3600 = 1 250	(1 250 − 10) × 6,48 ≈ 8 035 ₽ + 29 × 18,97 ≈ 550 ₽	≈ 8 585 ₽

Сценарии A и B показывают сильную сторону модели: пока нагрузка небольшая или неравномерная, вычисления обходятся в копейки, а сервер для той же задачи стоил бы несколько сотен или тысяч рублей в месяц. В сценарии C картина другая. При ровной высокой нагрузке счёт растёт линейно с трафиком, и его стоит сравнить с арендой VPS или узлов Kubernetes такой же мощности. Где-то между этими сценариями находится точка безубыточности, и для каждого проекта её нужно считать отдельно.

Обратите внимание на оговорки. В расчёт не входят API Gateway, база данных, объектное хранилище, очереди и исходящий трафик сверх бесплатных 100 ГБ: в реальном проекте эти строки счёта нередко больше, чем плата за сами функции. Цены приведены по прайсу Yandex Cloud на сентябрь 2026 года и могут меняться, поэтому перед запуском пересчитайте их на калькуляторе провайдера.

Популярные serverless-платформы и их лимиты

Serverless-платформы различаются лимитами на время выполнения и память, квотами на параллельные запуски, поддерживаемыми языками и тем, где физически хранятся данные. Ниже — сравнение основных вариантов. Для AWS Lambda и Yandex Cloud Functions приводим цифры из официальной документации, для остальных платформ — качественную характеристику: их лимиты зависят от поколения сервиса и тарифа, поэтому сверяйте их в документации перед выбором.

Платформа	Время выполнения	Память	Параллельные запуски	Особенности
AWS Lambda	до 900 с (15 мин)	128–10 240 МБ	1 000 по умолчанию	Синхронный запрос или ответ до 6 МБ, архив до 50 МБ в zip и 250 МБ в распакованном виде; при 1 769 МБ функции выделяется около 1 vCPU
Yandex Cloud Functions	до 1 часа	до 8 ГБ на экземпляр	квота по умолчанию — 10 на зону доступности, расширяется по запросу	Оплата в рублях, данные в российских дата-центрах
Google Cloud Functions / Cloud Run	Лимиты зависят от поколения сервиса и конфигурации			Cloud Run запускает в serverless-режиме целые контейнеры
Azure Functions	Лимиты зависят от плана размещения			Глубокая интеграция с экосистемой Microsoft
Cloudflare Workers, Vercel Functions	Жёсткие ограничения, рассчитаны на короткие запросы			Edge-функции: код выполняется ближе к пользователю

Источники цифр: квоты AWS Lambda и квоты и лимиты Yandex Cloud Functions. Обратите внимание на квоту Yandex Cloud: 10 одновременных вызовов на зону — это немного, и для продакшен-нагрузки её почти всегда приходится увеличивать заранее, до запуска.

Для российских компаний выбор во многом определяет 152-ФЗ. Если функции обрабатывают персональные данные россиян, их первичные запись и хранение должны происходить в базах на территории России. На практике это означает выбор российского облака: Yandex Cloud, VK Cloud, Cloud.ru и других. Подробное сравнение провайдеров — в статье «Как выбрать облако: AWS, Azure, Yandex или VK Cloud».

Где применять serverless: 7 типовых сценариев

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

1. REST и GraphQL API, бэкенд для мобильных и веб-приложений. Функции за API Gateway обрабатывают запросы клиентов и масштабируются вместе с аудиторией. О том, зачем нужен шлюз и как он устроен, мы писали в статье «Что такое API Gateway и зачем он нужен».
2. Обработка файлов и изображений. Пользователь загрузил фото — функция создаёт превью, сжимает картинку, распознаёт текст или проверяет файл на вирусы.
3. Вебхуки и интеграции. Уведомления от платёжных систем, CRM, маркетплейсов и службы доставки приходят нерегулярно, и держать под них отдельный сервер невыгодно.
4. Чат-боты. Бот в Telegram получает обновления через вебхук, и функция отвечает на каждое сообщение. Нагрузка может быть почти нулевой ночью и резко расти после рассылки.
5. ETL, обработка потоков и логов. Функции подписываются на очередь или поток событий, очищают и преобразуют данные и складывают их в хранилище или аналитическую базу.
6. Задачи по расписанию. Ночные выгрузки, рассылки, очистка устаревших данных, генерация отчётов — всё, что раньше делал cron на сервере, который работал круглосуточно ради пяти минут в сутки.
7. IoT, MVP и пилоты. Датчики присылают события нерегулярно, а новому продукту важно быстро выйти к пользователям и не платить за инфраструктуру, пока аудитории нет.

Когда serverless НЕ подходит: кейс Prime Video

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

• сервис работает под постоянной высокой нагрузкой 24/7 — выделенные мощности будут дешевле;
• операции длятся дольше лимита платформы: рендеринг, обучение моделей, большие пакетные расчёты;
• критична минимальная и стабильная задержка: биржевые системы, игры реального времени;
• логика stateful: нужно держать состояние в памяти между запросами;
• нужны WebSocket и долгие соединения — в serverless это возможно только через дополнительные управляемые сервисы;
• данные по требованиям регулятора или заказчика должны оставаться в собственном контуре (on-premise).

Показательный пример — команда Prime Video из Amazon. Её сервис мониторинга качества видео и звука был построен на AWS Step Functions и Lambda: каждый этап анализа потока выполнялся отдельной функцией, а данные передавались между ними через хранилище. При масштабировании такая схема упёрлась в стоимость оркестрации и передачи данных. Команда собрала компоненты в один процесс, фактически монолит, и, по собственному отчёту, снизила затраты на инфраструктуру на 90%.

Вывод из этой истории не «serverless плох», а «архитектура должна соответствовать профилю нагрузки». Для старта и проверки идеи функции были удобны. Когда нагрузка стала постоянной и предсказуемой, монолит оказался выгоднее. Хорошая архитектура оставляет возможность такого перехода, а не делает выбор навсегда.

Как перевести проект на serverless: пошаговый план

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

1. Проведите аудит нагрузки и профиля трафика. Снимите метрики за 1–3 месяца: число запросов по часам, пики и провалы, длительность операций, потребление памяти. Serverless выигрывает там, где нагрузка неравномерная, и проигрывает при ровной высокой нагрузке 24/7.
2. Выберите кандидатов на перенос. Начинайте с периферии: фоновые задачи, обработка файлов, вебхуки, задачи по расписанию, API с пиковой нагрузкой. Ядро системы не трогайте, пока не отработаете подход, — это паттерн «душитель» (strangler pattern).
3. Выберите платформу. Сверьте лимиты по времени выполнения, памяти и параллельным запускам, цены и требования 152-ФЗ. Для персональных данных россиян выбирайте российские облака.
4. Опишите инфраструктуру кодом и настройте CI/CD. Функции, триггеры, права доступа и очереди описывайте в Terraform, Serverless Framework или AWS SAM и выкатывайте через пайплайн. По данным Datadog, Terraform чаще выбирают крупные организации, а Serverless Framework — небольшие команды. Ручные настройки в консоли облака через полгода никто не сможет воспроизвести. Если своей экспертизы не хватает, можно заказать настройку CI/CD и облачной инфраструктуры у команды, которая уже делала такие переносы.
5. Настройте наблюдаемость. Централизованные логи, распределённая трассировка (например, OpenTelemetry), метрики ошибок и длительности, а также алерты на стоимость — чтобы узнать о всплеске счёта в тот же день.
6. Проведите нагрузочное тестирование. Проверьте поведение при пиках, упор в квоты параллельных запусков, время холодного старта и нагрузку на базу данных от множества одновременных экземпляров функций.
7. Переносите поэтапно и сравнивайте счёт. Переключайте трафик частями, держите путь отката и через 1–2 месяца сравните фактические расходы и метрики с исходной архитектурой. Не сошлось — возвращайте компонент обратно.

Best practices разработки serverless-функций

Хорошая serverless-функция — маленькая, предсказуемая и безопасная для повторного запуска. Правила, которые экономят больше всего времени на поддержке:

• Одна функция — одна задача. Маленькие функции проще тестировать, быстрее стартуют и получают более узкие права доступа.
• Идемпотентность. Провайдеры могут повторно доставить событие, поэтому повторный вызов с теми же данными не должен дважды списывать деньги или отправлять письмо.
• Минимум зависимостей. Чем меньше пакет, тем короче холодный старт. Тяжёлые библиотеки выносите в отдельные сервисы или слои.
• Правильная работа с базой данных. Используйте пулы соединений, прокси вроде RDS Proxy или serverless-базы данных, чтобы сотни экземпляров не исчерпали лимит соединений.
• Секреты — в менеджере секретов. Не храните ключи и пароли в коде и переменных окружения в открытом виде.
• Лимиты параллелизма. Ограничивайте число одновременных экземпляров для функций, которые обращаются к хрупким внешним системам, чтобы всплеск трафика не уронил базу или API партнёра.

Будущее serverless: тренды 2026

Развитие serverless идёт в сторону стирания границ между функциями, контейнерами и edge-вычислениями. Направления, которые мы видим в проектах и в анонсах провайдеров:

• Serverless-контейнеры. Cloud Run, Knative и аналоги запускают в бессерверном режиме целые контейнеры, а не только функции. Это снимает часть ограничений по рантаймам и упрощает перенос существующих сервисов. По данным Datadog, 66% организаций, использующих serverless в Google Cloud, работают с контейнерным serverless.
• Edge-функции. Код выполняется в точках присутствия CDN, ближе к пользователю: персонализация, A/B-тесты, авторизация на границе сети с минимальной задержкой.
• ARM-процессоры. Провайдеры предлагают запуск функций на ARM (например, AWS Graviton) — это отдельная опция, которую стоит сравнить по цене и производительности для своей нагрузки.
• Durable и stateful-функции. Долгие процессы с сохранением состояния постепенно становятся частью платформ: в документации AWS Lambda уже появился отдельный раздел о durable functions.
• AI-инференс на serverless GPU. Модели запускаются по запросу без постоянной аренды видеокарт — это удобно для сервисов с неравномерной нагрузкой на ИИ.

Частые вопросы о serverless (FAQ)

Serverless — значит без серверов?

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

Чем serverless отличается от микросервисов?

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

Что такое холодный старт и как его сократить?

Холодный старт — задержка при вызове функции, для которой провайдеру нужно поднять новую среду выполнения и загрузить код. Сократить его помогают лёгкие рантаймы вроде Python и Node.js, минимум зависимостей, предварительно прогретые экземпляры (provisioned concurrency) и периодический прогрев функций.

Сколько стоит serverless и когда он дороже VPS?

Вы платите за число вызовов и за время выполнения, умноженное на объём памяти. В Yandex Cloud Functions каждый месяц бесплатно 1 млн вызовов и 10 ГБ×час, поэтому небольшие сервисы обходятся в десятки или сотни рублей. При постоянной высокой нагрузке 24/7 счёт растёт пропорционально трафику и может превысить стоимость VPS или узлов Kubernetes такой же мощности.

Можно ли использовать serverless в России с учётом 152-ФЗ?

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

Подходит ли serverless для MVP и стартапа?

Чаще всего да. Serverless позволяет быстро запустить продукт, не нанимать администратора и почти не платить за инфраструктуру, пока пользователей мало. Главное — сразу описывать инфраструктуру кодом и не завязывать логику на специфичные сервисы провайдера, чтобы при росте нагрузки перенести ядро в контейнеры без переписывания.

Как избежать привязки к одному облаку (vendor lock-in)?

Полностью избежать её сложно, но можно снизить: держите бизнес-логику отдельно от обработчиков событий, прячьте облачные SDK за собственными интерфейсами, описывайте инфраструктуру в Terraform и отдавайте предпочтение открытым стандартам. Для максимальной переносимости подойдут контейнерный serverless и открытые платформы вроде Knative и OpenFaaS.