Serverless-розробка: AWS Lambda, Vercel Functions, Cloudflare Workers, Edge — досвід 7+ років
Ми займаємося serverless-розробкою — проєктуємо, реалізуємо та оптимізуємо рішення на AWS Lambda, Vercel Functions та Cloudflare Workers. Маємо сертифікати AWS та досвід масштабування до 1 млн запитів на день. Оцінимо ваш проєкт безкоштовно — зв’яжіться з нами.
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 секунд, зараз покращено, але він все ще довший. Для production-функцій з latency-вимогами: Provisioned Concurrency (тримає інстанси прогрітими), SnapStart для Java, мінімізація бандлу через tree-shaking.
Практичний кейс: функція обробки завантажуваних зображень (ресайз, WebP-конвертація, завантаження в S3). Бандл з sharp важив 40MB через нативні бінарники. Рішення — Lambda Layer з sharp, основна функція 800KB. Cold start впав з 3.2s до 400ms — економія становить 87%.
Lambda Layers — спільні залежності між функціями. До 5 шарів на функцію, кожен до 250MB. Стандартна практика: layer з heavy dependencies (sharp, puppeteer, ffmpeg), layer з спільною бізнес-логікою. Інфраструктура Lambda через AWS CDK або Terraform.
| Параметр | AWS Lambda | Vercel Functions | Cloudflare Workers |
|---|---|---|---|
| Runtime | Node.js, Python, Go, Java, .NET (up to 15 min) | Node.js (up to 300s) | V8 Isolates (no Node.js API) |
| Cold start | 200ms–1.5s (Node.js) | ~200ms (Node.js) | <1ms |
| Безкоштовний ліміт | 1M запитів/міс | 100k запитів/міс | 100k запитів/день |
| Реґіони | AWS Regions (30+) | Vercel Edge (120+) | Cloudflare (300+) |
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 додатків — не найкращий вибір.
Ecosystem: Hono.js — мінімалістичний роутер, що працює на Workers, Deno, Bun, Node.js. Якщо потрібен єдиний код для Edge і сервера — хороший вибір.
Коли serverless не підходить
Тривалі обчислення (>15 хвилин на Lambda, >30 секунд на Vercel) — потрібен Fargate або звичайний сервер. WebSocket-сервер зі станом — немає постійного процесу. Завдання з частим зверненням до диску — ефемерне 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 неможливо зчепити логи.
Що входить у роботу
| Deliverable | Опис |
|---|---|
| Дизайн архітектури | Границі функцій, event-маршрути, вибір провайдера, схеми даних |
| Реалізація та деплой | Код на Python/Node.js/Go, CI/CD (GitHub Actions, Terraform), preview deployments |
| Оптимізація холодного старту | Provisioned Concurrency, Lambda Layers, tree-shaking, ARM |
| Тестування та моніторинг | Unit/integration тести, X-Ray, alarms (CloudWatch), SLA |
| Документація та навчання | README, архітектурні діаграми, інструкції для вашої команди |
Процес роботи
Починаємо з аналізу патерну навантаження: якщо трафік непередбачуваний або рідкий — serverless дасть економію; якщо стабільно високий — може виявитися дорожчим. Проєктуємо межі функцій за принципом single responsibility. Розробляємо локально через SST, Wrangler або LocalStack. CI/CD з preview deployments обов’язково.
Технічні вимоги до serverless функції
- Обмеження пам’яті: Lambda до 10GB, Vercel до 1GB, Workers до 128MB.
- Диск: /tmp до 10GB (Lambda), відсутній на Edge.
- Час виконання: Lambda макс 15 хв, Vercel 300 с, Workers 30 с.
- Бандл: Lambda — до 250MB (зі шарами), Vercel — до 50MB, Workers — до 4MB.
Як оптимізувати cold start в AWS Lambda?
Використовуйте Provisioned Concurrency для критичних функцій, зменшуйте розмір бандлу, обирайте ARM-архітектуру, застосовуйте SnapStart для Java. Для edge-функцій без cold start розгляньте Cloudflare Workers.
Що обрати: Cloudflare Workers чи Vercel Functions?
Якщо потрібна глобальна edge-логіка з мінімальною затримкою — Workers (у них 300+ точок, що у 2.5 рази більше ніж Vercel). Якщо використовуєте Next.js і потребуєте повноцінного Node.js runtime — Vercel Functions. Комбінуйте обидва підходи для складних проєктів.
Терміни
Serverless API для стартапу (10–20 функцій): 2–5 тижнів. Міграція монолітного Laravel/Node API на Lambda: 4–10 тижнів залежно від обсягу. Edge Middleware + Workers для глобального продукту: 2–4 тижні. Ми гарантуємо якість на основі 7+ років досвіду та 20+ реалізованих проєктів. Замовте консультацію — отримайте технічну оцінку вашого сценарію.