Serverless-розробка: AWS Lambda, Vercel Functions, Cloudflare Workers, Edge
Serverless не означає "без сервера". Серверу є — ви просто не управляєте ними. Правильніше читати це як "без менеджменту серверів": немає патчинга ОС, немає настройки nginx, немає моніторингу дискового простору. Функція отримує подію, обробляє, повертає відповідь. Провайдер сам вирішує, на чому це запустити.
AWS Lambda: потужність та операційна складність
Lambda — найзріліша платформа з найбільшим набором триггерів: API Gateway, SQS, SNS, S3, DynamoDB Streams, EventBridge. Це важливо для складних event-driven архітектур.
Cold start — головна біль Lambda на Node.js: від 200ms до 1.5s в залежності від розміру бандла та VPC. У VPC холодний старт був до 10 секунд до 2019 року, тепер покращили, але він все ще довший. Для production-функцій з latency-вимогами: Provisioned Concurrency (тримає інстанси прогрітими), SnapStart для Java, мінімізація бандла через tree-shaking.
Практичний кейс: функція обробки завантажених зображень (ресайз, WebP-конвертація, загрузка в S3). Бандл з sharp важив 40MB через нативні бінарники. Рішення — Lambda Layer з sharp, основна функція 800KB. Cold start впав з 3.2s до 400ms.
Lambda Layers — загальні залежності між функціями. До 5 шарів на функцію, кожен до 250MB. Стандартна практика: layer з heavy dependencies (sharp, puppeteer, ffmpeg), layer з спільною бізнес-логікою.
Інфраструктура Lambda через AWS CDK або Terraform. SAM — для тих, хто тільки починає, CDK — для серйозних проектів з типобезпекою.
Vercel Functions та Edge Runtime
Vercel Functions — це Lambda під капотом (us-east-1 за замовчуванням), але з мінімальним порогом входу для Next.js-проектів. API Routes та Route Handlers деплоятся автоматично. Serverless функції на Node.js runtime з лімітом у 300 секунд на Vercel Pro.
Edge Runtime принципово іншій: функція запускається на V8 isolate у ближайшій до користувача точці CDN-мережі Vercel (120+ регіонів). Немає cold start як такого — isolate стартує за ~0ms. Але жорсткі обмеження: немає Node.js API (fs, crypto через Web API), немає доступу до баз даних через TCP (тільки через HTTP API), розмір бандла до 4MB.
Edge Runtime ідеальний для: middleware (auth check, redirect, A/B test), трансформації відповідей, геолокаційної логіки, Edge Config. Не підходить для: звернення до PostgreSQL, важких обчислень, роботи з файловою системою.
Cloudflare Workers: справжній Edge
Workers запускаються на V8 isolates у 300+ точках присутності Cloudflare. Latency для користувача — буквально ближайший дата-центр. Cold start < 1ms.
Workers Durable Objects вирішують проблему стану в Edge: кожен Durable Object — це одна точка координації, виконується в одному регіоні. Ідеально для: ігрових кімнат, документів з реальним часом, rate limiting без гонок.
Workers KV — eventually consistent сховище. Запис розповсюджується по всіх регіонах за ~60 секунд. Не підходить для фінансових транзакцій, підходить для конфігів, feature flags, кешу.
D1 — SQLite на Edge. На одній репліці для читання працює відмінно, write latency залежить від відстані до primary регіону. Для глобальних write-heavy додатків — не найкращий вибір.
Екосистема: Hono.js — мінімалістичний роутер, працює на Workers, Deno, Bun, Node.js. Якщо потрібен єдиний код для Edge та сервера — хороший вибір.
Коли serverless не підходить
Довгі обчислення (>15 хвилин на Lambda, >30 секунд на Vercel) — потрібен Fargate або звичайний сервер. WebSocket-сервер з станом — нема постійного процесу. Задачи з частим звертанням до диску — еphemeral storage, /tmp на Lambda 512MB–10GB. Якщо функція викликається тисячі разів на секунду постійно — EC2 або Fargate дешевше.
Vendor lock-in — реальна проблема. Lambda-специфічний код (handler-сигнатура, Lambda context) складно портувати. Hono.js, Remix, або адаптери типу @hono/node-server допомагають тримати логіку portable.
Observability
Без нормального observability serverless — чорна скринька. Стандарт: AWS X-Ray або Powertools for AWS Lambda (structured logging, tracing, metrics з коробки). Для мультиоблачного стеку — OpenTelemetry з експортом у Grafana Cloud або Honeycomb.
Distributed tracing критичний коли функція А викликає функцію Б через SQS — без trace ID неможливо зв'язати логи.
Процес роботи
Починаємо з аналізу паттерну нагрузки: якщо трафік непередбачуваний або рідкий — serverless дасть економію. Якщо стабільно високий — може виявитись дорожче. Проектуємо границі функцій по принципу single responsibility. Розробляємо локально через SST, Wrangler або LocalStack. CI/CD з preview deployments обов'язково.
Графік
Serverless API для стартапу (10–20 функцій): 2–5 тижнів. Міграція монолітного Laravel/Node API на Lambda: 4–10 тижнів в залежності від обсягу. Edge Middleware + Workers для глобального продукту: 2–4 тижні.