Vercel, свой сервер или большое облако: где держать ранний продукт

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

Платформы: Vercel, Netlify и похожие

Ты отдаёшь репозиторий, платформа собирает и выкладывает. Превью для каждой ветки, HTTPS, CDN и откат в один клик — из коробки. Для фронтенда и лёгкого API это почти всегда лучший старт: ноль администрирования и быстрый цикл.

Ограничения появляются, когда продукт перестаёт быть «страница плюс короткий запрос»:

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

Свой сервер

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

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

Часть забот снимают контейнерные платформы — промежуточный вариант между VPS и Vercel: ты отдаёшь Docker-образ, они его запускают и перезапускают.

Большое облако

AWS, Google Cloud, Azure. Здесь есть всё, что может понадобиться, и ещё много того, что не понадобится. Это разумный выбор, когда есть конкретная причина:

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

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

Где на самом деле привязка

Привязка к поставщику редко возникает из-за того, где запущен контейнер. Она возникает из-за собственных API платформы, на которые завязан код:

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

Чтобы переезд оставался возможным, держись стандартного: Postgres, хранилище с S3-совместимым API, конфигурация через переменные окружения, сборка, которая работает на любой машине. Пользоваться удобствами платформы можно, просто стоит знать, какие из них потом придётся переписать.

Как думать о расходах

Точные цены меняются, а принципы — нет:

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

Смешанный вариант

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

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