Edge vs serverless vs свой VPS: что выбирать в 2026

Эта статья — не «обзор трёх модных слов». Она отвечает на вопрос, который задают реально при переезде: где должен исполняться мой код и где должна жить его база — и платит ли за это бизнес или читатель. Термины «edge» и «serverless» в разговоре склеивают в одно, хотя это две независимые оси. Разделение по осям и есть тот инструмент, который делает выбор архитектуры предсказуемым, а не «мне нравится Docker / мне нравится Vercel».

Цифры латентности здесь — физические оценки (скорость света в оптике + хвосты стека), а не SLA; тарифы и лимиты облаков сознательно не названы числами — они двигаются каждый квартал, берите актуальные с pricing-страниц. Внутрисерийные термины держим как в первой и третьей статьях серии: «воркер» — серверный обработчик Workers, а не браузерный Service Worker.

Часть I. Три модели на одном столе: чем они физически отличаются

1. Две оси вместо одной линейки

Главная ошибка при выборе — представлять edge, serverless и VPS как три точки на шкале «от старого к новому». Это не шкала, а две независимые координаты плюс третья, про контроль:

Где исполняется (география исполнения): у пользователя в PoP (edge) ↔ в одном регионе/ДЦ (serverless-функция, классический хостинг) ↔ на конкретной машине, которую вы выбрали (VPS).
Как вы за это платите и растёт ли процесс постоянно (модель ресурса): платите за факт вызова и процесс «просыпается» по событию (serverless) ↔ платите за машину, процесс живёт всё время (VPS). edge-платформы чаще всего одновременно и географически близко, и по-серверлесс-оплачиваемы.
Кому принадлежит окружение и состояние (контроль): платформа провайдера ↔ ваша ОС и ваша БД.

Поставим три варианта на эти оси — сразу видно, что это не линейка:

Модель	Где исполняется	Плата/процесс	Контроль
`edge`-вычисление (Workers, `Lambda@Edge`, `Fastly` Compute)	PoP рядом с пользователем, сотни точек	за запрос/секунды CPU, процесс не держат	окружение узкое, задаёт вендор
serverless-функция в регионе (`Lambda`, Cloud Functions, `Cloud Run`)	один/несколько дата-центров провайдера	за вызов + GB-s, холодный старт платишь латентностью	runtime-образ свой, но железо чужое
свой VPS (nginx + PHP-FPM + MySQL)	одна конкретная машина/ДЦ	flat-плата за машину, процесс живёт всегда	полный: ОС, версии, конфиг, данные

Отсюда и путаница: люди спорят «edge против serverless», хотя Workers = edge + serverless (обе координаты), Lambda = serverless, но не edge (региональный ДЦ), а VPS = ни то ни другое (постоянный процесс, одна машина, свой контроль). Правильный спор не «edge или serverless», а «на каждой из трёх осей — что мне нужно».

2. Что объединяет edge и serverless против VPS: холодный старт

edge и serverless платят общей ценой за «плати по вызову»: процесс, обслуживающий запрос, либо не держится постоянно, либо изолирован. Отсюда cold start — первый запрос после простоя ждёт поднятия контейнера/изолята (десятки…сотни миллисекунд для JVM/тяжёлых runtime; единицы…десятки для V8-изолятов, которые и держат edge-платформы короткими «тёплыми» блоками). На VPS холодного старта нет: PHP-FPM-воркер и MySQL уже живут, «прогрев» оплаты не касается. Это прямое продолжение физики из разбора архитектуры: изоляция и авто-масштаб покупаются ценой координационных накладных расходов.

Для выбора это значит простую вещь: если у вас редкий запрос на тяжёлый рантайм, «мгновенный serverless» даёт пользователю самый медленный ответ из всех трёх (платит cold start). Если запросов много и они тонкие — изолят прогрет, и edge вне конкуренции по латентности.

3. Что остаётся за кадром моды

edge/serverless снимают с вас операционку (патчи ОС, апскейл под пик, резервирование по зонам), но переносят на вас модель (stateless-мышление, лимиты времени/памяти, привязка к провайдерским API). VPS снимает привязку и даёт полный контроль среды, но не снимает операционку — вы сами себе SRE (анатомия машины, слои конфигурации, защита периметра). Выбор — это обмен одного класса работы на другой, а не «правильно vs неправильно».

Часть II. Латентность: где `edge` выигрывает, а где проигрывает

1. Что именно режет `edge`

Сетевой ответ браузеру — это минимум RTT (round-trip) между клиентом и тем, кто отдаёт результат, плюс время обработки. RTT — это физика света в оптике и хвостов маршрутизации: внутри региона — единицы…десятки мс, через океан — десятки мс в одну сторону, и это не «оптимизируется» кодом. edge-вычисление переносит точку обработки близко к пользователю, то есть убирает из уравнения дальний RTT до origin. Глобальную картину доставки и кеширования разобрали отдельно в CDN и edge-вычислениях — здесь важна именно вычислительная часть.

Схематично (это порядок величин, а не замер конкретного вендора):

Запрос из Японии к origin во Франкфурте (свой VPS):
   пользователь → Франкфурт: RTT ~180–220 мс  (дальний путь + хвосты)
   → итог даже при мгновенной обработке: ~200 мс только на доставку

Тонкий edge-код в Tokyo PoP:
   пользователь → Tokyo: RTT ~5–15 мс
   → если ответ готов в PoP (кэш/вычисление на месте): ~10–20 мс суммарно

Выигрыш edge реален ровно в той мере, в какой ответ можно сформировать рядом с пользователем.

2. Когда выигрыш съедается полностью

Тот же RTT возвращается, как только edge-функция должна сходить за данными к origin (база, кэш, микросервис живут в одном регионе). Тогда вы платите и «клиент→PoP» (коротко), и «PoP→origin→PoP» (длинно) — и второй отрезок часто один:

edge-код требует запись из БД во Франкфурте:
   пользователь → Tokyo PoP:      ~10 мс   (выиграли)
   PoP → Франкфурт (БД) → PoP:    ~180 мс  (вернули весь дальний RTT)
   → итог ~190 мс, выигрыша почти нет

Практический вывод для архитектуры: edge хорош для того, что не требует обращения к одному источнику истины — кэш-ответ, A/B-переключение, редирект, авторизационная проверка по токену, склейка уже закэшированных кусков. Как только в обработчике появляется «а теперь сходи в одну конкретную базу» — geographic-выигрыш тает, и вы держите edge-слой поверх удалённого состояния, получая сложность без прибыли. Это ровно то разграничение, на котором живут KV/D1/R2 (распределённое managed-состояние) против «одна MySQL» — см. Часть III.

3. Где `edge` не помогает в принципе: CPU-bound

PoP оптимизированы под много маленьких коротких запросов, а не под долгую тяжёлую обработку. У каждого есть жёсткий wall-clock и лимит памяти на инвокацию. Если задача — обработать большой файл, собрать отчёт, прогнать ML-инференс, — вы упираетесь в лимит рантайма, а не в латентность сети, и edge тут не инструмент. Тяжёлое вычисление живёт либо на постоянной машине (VPS/GPU), либо в отдельных асинхронных воркерах через очередь (очереди сообщений, нагрузочное тестирование чтобы это измерить). «Перенесём всё на edge» для CPU-bound работы — антипаттерн, и в Части V он в списке «когда edge лишний».

4. Ось «география», которую никто не отменил

Важно не спутать две латентности: до пользователя и до источника данных. edge убирает первую, если ответ локален; вторую он убирает только если состояние тоже распределено (managed-хранилище с репликами или celld-флот с бакетом — №3). Простая установка edge-рантайма рядом с пользователем, при котором данные остаются в одном ДЦ, даёт сложность и двойную латентность вместо быстрой системы. Физика расстояния из CDN-статьи здесь остаётся законом.

Часть III. Состояние — вот настоящая развилка

Если Части I–II про «где и как исполнять», то главный выбор — куда класть состояние. Он определяет и переносимость, и цену, и то, как вы масштабируетесь. Стратегий ровно три.

1. Без состояния (stateless) — родная стихия `edge` и serverless

Обработчик ничего не помнит между запросами: каждое решение выводится из запроса + внешнего хранилища/вызова. Тогда масштаб — «запусти N копий где угодно», холодный старт не портит корректность, балансировка тривиальна (балансировка нагрузки). Идеально для: рендеринга по шаблону, API поверх внешнего БД-сервиса, валидации/роутинга. Ограничение честное: всё «состояние» вынесено наружу, и вы платите латентностью и привязкой за каждый поход к нему.

2. Managed-состояние у вендора — простота ценой привязки

Провайдер даёт хранилище как часть платформы, с репликацией и «набором в одну строку конфига». Так живут KV (ключ/значение глобально), объектные бакеты (R2/S3), SQL над распределённым слоем (D1), динамические таблицы у AWS/GCP. Плюс: вы не админите кластер. Минус, названный своим именем: это язык провайдера, и переносимость — вопрос, а не свойство. Именно про эту точку и вся сделка из №1: рантайм переносим (workerd), но managed-состояние «улететь» с собой уже труднее, и celld №3 как раз про то, чтобы stateful-примитивы (Durable Objects, KV, D1, R2) тоже можно было исполнять на своём бакете. Это не делает привязку нулевой — но превращает её из «заперт» в «есть дверь, кирпич кладёте вы».

3. Своё постоянное состояние (MySQL на VPS) — контроль и ваша проблема шардинга

Одна база, живущая рядом с вашим приложением, принадлежит вам целиком: схема, индексы, миграции, резервные копии, юридическая локализация строк. Это модель, в которой живёт WordPress-читатель сайта (MariaDB на сервере, оптимизация БД). Цена: как только приложение выросло из одной машины, шардинг, репликация, failover — ваша инженерная задача, а не галочка в консоли облака (те же monolit vs микросервисы и контейнеры/оркестрация — про этот же сдвиг ответственности). Плюс — ровно то, чего нет у managed: резидентность данных и независимость от вендорского API.

4. Durable Objects: четвёртая точка, «stateful на edge»

Отдельно стоит абстракция Durable Object — именной адресуемый «маленький сервер со своей SQLite и живыми сокетами» (механику и celld-исполнение разбирает №3). Он интересен именно на этой оси: снимает вилку «или stateless-чистота, или тяжёлое состояние своими руками», давая состояние, привязанное к сущности (пользователь, комната, аккаунт), с однопоточным исполнением внутри неё. Заманчиво для реалтайма, совместного редактирования, чата — ровно того, что на LAMP-стеке приходится городить отдельным сокет-сервером + Redis-состоянием + шардингом (SSE/WebSocket). Но помните цену с Части II: выгоды по латентности нет, если ячейка далеко от пользователя, а переносимость требует того самого celld-флота, а не «просто workerd».

Часть IV. Где связка PHP + свой VPS честно сильнее `edge`

Здесь — ответ прямо на аудиторию codestack.space: в каких случаях выбор «постоянная машина + MySQL» не устаревшая привычка, а правильное инженерное решение. Их четыре, плюс экономический.

1. Узкая география

Если 90% ваших пользователей в одном регионе (локальный бизнес, RU/ЕС-аудитория), то «дальний RTT», который режет edge, у вас и так короткий. Вы платите за глобальность, которой не используете, а выигрыш — единицы миллисекунд, часто меньше погрешности. Свой ДЦ + один-два CDN-пути для статики дают те же блага дешевле.

2. Тяжёлое и long-running вычисление

Отчёты, генерация PDF, видео-аудио обработка, миграции, долгие вычисления по БД — всё, что не влезает в wall-clock-лимит инвокации и не хочет платить cold start. Постоянный PHP-FPM-пул с настраиваемым max_execution_time, воркеры на очереди, прямые индексы в MySQL — это то, для чего VPS и существует. Портировать это на edge = воевать с лимитами платформы, а не с задачей (нагрузочное тестирование — чтобы измерить заранее, а не после миграции).

3. Резидентность и контроль данных (jurisdiction)

Когда закон или политика требует, чтобы строки лежали в конкретной юрисдикции и не уходили в чужое managed-хранилище, — «данные в вашей машине, вы знаете адрес ДЦ» выигрывает у «данные у вендора, реплицируются по его регионам». Это часть того же разговора о приватности, что локальные модели вместо облачного инференса: если вы ушли от облачной модели ради того, чтобы данные не покидали периметр, то и хранилище логично держать там же. И в инциденте вы разбираетесь со своей логой, а не с чужой console-историей (реагирование на взлом).

4. Нужна конкретная среда

Проприетарные расширения, специфичные версии, нативные библиотеки, GPU-инференс локально, необычные системные утилиты — «узкий окружение» у edge/managed-рантаймов задаёт вендор. VPS = root, ставите что хотите, держите что хотите (systemd-сервисы). Если ваша задача упирается в «этого нет в рантайме платформы», спор окончен до начала.

5. Экономика на стабильном потоке

edge/serverless оплачиваются по вызову/секундам CPU. Для рваного трафика (ноль ночью, пик днём) это дешевле плоской машины — вы не платите за простой. Но для стабильно высокого постоянного потока flat-цена за VPS нередко выигрывает у «плати за каждый запрос»: на постоянном объёме per-request биллинг растёт линейно, а ваша машина одинакова круглосуточно. Считать надо на своём профиле трафика — поэтому тарифы здесь и не названы числами; но форма вывода устойчива: постоянный предсказуемый поток → VPS; редкий/взрывной/глобальный → edge/serverless.

6. Итог Части IV для WordPress-читателя

Если ваш прод — WordPress + PHP-FPM + MySQL на VPS, то по всем четырём осям вы уже в «правильной клетке» для своей аудитории: география узкая, состояние ваше, среда своя, экономика плоская. Доводить до глобальной вычислительной edge-модели такой сайт — это обычно второй self-host рядом с первым (формулировка №3): вы платите новой экосистемой (Node/bundler, бакет, приватная сеть флота) за то, чего у вас, скорее всего, просто нет в требовании. Полезная «edge-часть» для такого сайта — почти всегда CDN для статики и кэш, а не вычисления на краю.

Часть V. Матрица выбора: пять вопросов вместо вкусовщины

Собираем Части I–IV в инструмент. Пройдитесь по вопросам сверху вниз; первый жёсткий «нет/да» обычно сужает выбор сильнее любых аргументов «мне нравится X».

1. Пять вопросов

География пользователей — широкая или узкая? Широкая (несколько континентов) и ответ формируется локально → edge даёт реальную победу. Узкая → латентный аргумент edge гаснет, см. вопрос 5.
Код тонкий или тяжёлый? Тонкий (кэш, роутинг, склейка, проверка токена, единиц-мс CPU) → живёт на edge/serverless без боя. Тяжёлый/долгий (обработка файлов, отчёты, ML, долгие транзакции) → постоянная машина + очереди.
Какая модель состояния? Stateless → edge/serverless в своей стихии. «Нужна одна база, я контролирую строки и юрисдикцию» → VPS/managed-БД рядом. «Нужно привязанное к сущности состояние и реалтайм на глобальной географии» → Durable Objects (celld для self-host, №3) — осознанно покупая экосистему.
Резидентность/контроль — обязательны? Да (закон, приватность, конкретная среда/библиотеки/GPU) → контроль перевешивает managed-удобство: VPS или свой celld-флот. Нет → managed упрощает жизнь.
Профиль трафика и операционный бюджет? Взрывной/редкий, и вы не хотите SRE-нагрузку → serverless/edge (платите за факт, не за простой, операционку берёт вендор). Стабильно высокий постоянный поток, и у вас есть (или не боитесь) админку машины → VPS по flat-цене, часто дешевле и предсказуемее.

2. Быстрая карта «профиль → модель»

Что у вас	Основная ставка	Почему
Глобальный контент-сайт, тонкие ответы	CDN + `edge`-доставка, compute минимальный	режете RTT там, где он реально большой
API с широкой географией, stateless	`edge`/serverless	платите по вызову, масштаб без шардинга
Глобальный stateful-реалтайм (комнаты, совместное редактирование, чат)	Durable Objects (облако) или `celld`-флот (self-host)	состояние привязано к сущности, переносимость — через `celld`
Тяжёлый бэкенд, свои версии/GPU/лицензии	свой VPS / выделенный	контроль среды, никаких лимитов платформы
Узкая география, стабильный поток, одна MySQL	свой VPS (+CDN для статики)	экономика и контроль бьют «модность»
WordPress + PHP + VPS, RU/ЕС-аудитория	VPS + CDN/кэш	вы уже в правильной клетке, edge-вычисления лишние

3. Гибрид — это норма, а не компромисс

В реальности большинство систем слоёные, и это не «не смог выбрать»: тонкий edge-слой перед origin делает доставку/редиректы/проверку токена близко к пользователю, а тяжёлое состояние и вычисление живут на VPS или managed-БД в своём регионе. Именно так устроен «WordPress + Cloudflare» у вашего читателя: edge доставляет (кэш статики, edge-кэш и персонализация — отдельная задача с ловушкой утечек через shared-cache), а думает PHP-FPM на машине. Граница слоя проводится по формуле Части II: то, что можно ответить локально, — на краю; то, что требует один источник истины, — у origin.

4. Антипаттерны, чтобы поймать себя

«Перенесём всё на edge.» Влетаете в wall-clock/память-лимиты на тяжёлых задачах и в двойную латентность там, где нужно сходить в одну базу.
«Serverless для stateful-монолита». Каждый «поход за состоянием» платит и сетью, и managed-счётом; вы получаете сложность распределённых вызовов ради того, что на VPS было одним соединением.
«VPS ради экономии — один узел для глобальных пользователей». Платите дальним RTT всем, кроме своего региона.
Путать оси (Часть I): «это же edge, значит serverless». Lambda не близок к пользователю; Workers — близок. Разное решение разных задач.
Игнорировать residency/контроль ради managed-удобства. Одна галочка в консоли, и ваши строки уже реплицируются по регионам, которые выбрали не вы.

Часть VI. Итог серии: что сдвинула сделка и чего не сдвинула

1. Что серия дала по порядку

Смысл пяти статей — один тезис, разложенный по шагам:

№1: Cloudflare купил не рантайм, а модель программирования и человека, который хотел исполнять её на чужом железе. Это поворот не «к Cloudflare», а «от Cloudflare» — к portable serverless.
№ 2: механически перенести Deno-приложение на Workers можно; почти всё, что ломается, — не язык, а способ достучаться до ресурсов (URL-import/npm: против bindings).
№3: дыра workerd была в распределении состояния (DO только single-instance); её закрывает celld (ячейка+флот+бакет, lease условной записью), а слияние celld→workerd — намерение в пути, не готовый прод.
№4 и №6 — примитивы платформы и кэш/персонализация без утечек — детали «как жить в модели».
Эта, №5: теперь у вас есть матрица, чтобы эти детали не превращались в религию.

2. Что сдвинула сделка — ровно одну ось

Вернёмся к трём координатам Части I. Сделка Cloudflare/Deno изменила одну из них — переносимость модели (третья ось, «кому принадлежит окружение и состояние»): у выхода из экосистемы появилась официально финансируемая дверь — workerd (Apache-2.0, прод-код) плюс celld (распределённые DO на вашем бакете, тоже Apache-2.0). Юридически и технически «унести и поставить у себя» перестало быть серой зоной.

Но сделка не отменила физики и экономики Части II и Части IV. Глобальность PoP по-прежнему сервис того, кто держит сеть (это число машин, которое вы ставите, а не свойство формата). Латентность до источника данных никуда не делась. Cold start, wall-clock-лимиты edge-рантайма и «постоянный поток дешевле на flat-VPS» остались на своих местах. Аргумент выбора стал чище («чья модель», а не «чьё облако»), но список физических ограничений не сократился ни на пункт.

3. Честный вердикт: «что выбрать» — не про рантайм

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

Не выбирайте рантайм до того, как выберете модель состояния (Часть III). «Edge vs serverless vs VPS» решается осью «где живёт база и кому она принадлежит», а не любовью к V8.
edge покупайте за латентность широкой географии и тонкий код — и только (Часть II). Всё остальное он даёт ценой сложности.
VPS не «устарел» — он выигрывает на узкой географии, тяжёлом вычислении, residency и стабильном потоке (Часть IV). Для WordPress-аудитории это почти всегда правильный ответ, а edge-часть для них = CDN/кэш, не вычисления.
Сделка — это дверь, а не готовый дом. Переносимость выросла, вендор сам её финансирует, но self-hosting «первосортным» ещё строится; кладите кирпич в план, не в предположение.
Гибрид — это норма. Тонкий край + origin-состояние. Проводите границу по формуле: локально отвечает — на краю, нужен один источник — у origin.

Если из всей серии запомнить одно: выбирайте по осям (география · тяжесть кода · модель состояния · резидентность · экономика), а не по ярлыку. Тогда и сделка 2026 года перестает быть новостью «кого купили», и становится просто ещё одним аргументом в вашей собственной матрице.

Инструменты под задачу

Разобрать вашу конкретную развилку «edge / serverless / VPS» по коду — AI-ассистент для кода на codestack.space: вставьте обработчик или фрагмент wrangler.json/конфиг nginx и попросите пройтись по пяти вопросам матрицы Части V — где у вас тонкий ответ на краю, а где схождение к одному источнику, которое edge не отменит.

Чек-лист граблей

Сравнивать «edge против serverless» как одну линейку. Это разные оси: Lambda = serverless, но не edge; Workers = и то и другое; VPS = ни то ни другое. Спор без разделения по осям — разговор в никуда.
Ждать, что edge ускорит всё. Он режет только сетевой RTT «клиент↔точка обработки». Тяжёлое вычисление (edge wall-clock-лимит) и поход за данными к одному origin (RTT возвращается) выигрыш съедают полностью.
Ставить edge-вычисления там, где нужен один источник истины. Двойная латентность + managed-счёт за каждый вызов к базе. Правильная граница: локально отвечает — на краю; требует одну базу — у origin.
Игнорировать cold start на редких запросах. Самый медленный ответ из трёх моделей у «мгновенного serverless» — когда процесс надо поднимать после простоя на тяжёлом рантайме.
Путать выбор рантайма с выбором модели состояния. Настоящая развилка — stateless / managed-состояние у вендора / своё постоянное (MySQL). Она определяет переносимость и цену сильнее, чем язык.
Переносить stateful-монолит на serverless. Каждый «поход за состоянием» платит сетью и биллингом; вы получаете распределённую сложность ради того, что на VPS было одним соединением.
Ставить на «один узел для глобальной аудитории ради экономии». Платите дальним RTT всем, кроме вашего региона; глобальность = число регионов, которое вы держите, а не свойство формата.
Забыть residency и контроль среды. Одна галочка managed-хранилища — и строки реплицируются по чужим регионам; а «узкое окружение» платформы не пустит нужную версию/библиотеку/GPU, где VPS их даёт.
Читать сделку Cloudflare/Deno как «теперь edge для всего». Сдвинулась ось переносимости модели; физика (PoP-география, cold start, лимиты) и экономика (flat-VPS на стабильном потоке) не отменены.

👤 Зарегистрируйтесь, чтобы добавить материал в закладки.