Статья основана на реальном опыте разработки и эксплуатации системы в течение 28 месяцев: от MVP до попытки миграции.

Ни один сервис не был вымышленным. Ни одна цифра — не придумана.

1. Бессерверный MVP на AWS: $0.5/мес за DNS

В 2020 году мы начали разработку мобильного приложения (iOS/Android), веб-панели администраторов и IoT-устройств, управляющихся через облако.

Цель: минимизировать затраты при низкой активности.

Стек AWS:

• API Gateway — точка входа, роутинг

• Lambda — бизнес-логика

• DynamoDB — NoSQL база

• S3 — статические файлы

• Cognito — аутентификация

• IoT Core — связь с устройствами

• Step Functions — оркестрация

• SQS — очереди

• CloudFront — CDN

• Route 53 — DNS

• CloudWatch — логи и метрики

• SES, Pinpoint — рассылки

Результаты:

• Пиковая нагрузка: $21/мес. (DynamoDB ~ $14, API Gateway ~$0.3, остальное ~0).

• Минимальная нагрузка: $0.5/мес. (только Route 53 за DNS).

• Всего за 28 месяцев: добавлено 4 домена — итого $2.5/мес.

• Пользователи: ~10 000 уникальных (Cognito), из них 1 217 зарегистрированых.

• Время на MVP: 6 месяцев.

Это был настоящий бессерверный MVP: минимальная цена, масштабируемость, ноль инфраструктурной головной боли.

2. Переезд в 2022: AWS → Яндекс.Облако? Нет, не получилось

Летом 2022 года мы начали планировать миграцию: политика, контроль, цена.

Проблема: AWS — это не просто облако, это экосистема. И никто не может её полностью заменить.

Мы проверили Serverless Containers в Яндекс.Облаке — но они не поддерживают длительные сессии IoT. Yandex Cloud Functions не поддерживает Step Functions-оркестрацию. Поэтому для нашей нагрузки (постоянные соединения, сложные workflow) Kubernetes был единственным вариантом — и он оказался в 5–6 раз дороже AWS Lambda + Step Functions.

Попытка перенести всё в Docker и запустить в Managed Service for Kubernetes (MSK) от Яндекса:

• Только за "управляемость": от 6 336₽/мес.

• Плюс ноды: от 2 131₽/мес.

• Итого: >8 500₽/мес против $21 (~1 500₽/мес) на AWS.

Вывод: бессерверная модель — не про "облако", а про отсутствие инфраструктуры. В Kubernetes мы теряли этот эффект.

3. Абстракция над облаками

Решение: не писать код под каждое облако, а описать логику в файлах конфигурации, которые можно транслировать в CloudFormation, YAML для Яндекс.Облака, docker-compose.yml, k8s manifests.

Архитектурные принципы:

• Конфигурация, а не код

  • Интерфейсы описываются в .yaml (свои форматы).

  • API — на базе OpenAPI 3.0 с расширениями под конкретное облако.

  • Сервисы — собственный формат, который транслируется в AWS CloudFormation, Yandex Cloud YAML, Kubernetes, Docker Compose.

• Слоёная архитектура («слоёный пирог»)

• Плагинный API Gateway

  • Написан на Go (внутренняя разработка).

  • Поддерживает Cognito, Keycloak и другие провайдеры аутентификации как плагины.

  • Интерфейс не привязан к конкретному бэкенду — можно переключаться без пересборки.

• Генератор UI

  • Читает конфигурацию API и генерирует интерфейс.

  • Плагинная архитектура позволяет подключать разные бэкенды.

Примеры конфигов (условные):

API (на базе OpenAPI с расширениями):

openapi: 3.0.0
info:
  title: My API
x-amazon-apigateway-integration: # AWS
  type: aws_proxy
  uri: ...
x-yandex-cloud-integration: # YC
  serverless:
    function: ...
paths:
  /users:
    get:
      x-amazon-apigateway-integration: ...
      x-yandex-cloud-integration: ...

используем расширения OpenAPI 3.0 — пользовательские поля с префиксом x-, которые игнорируются стандартными инструментами, но читаются нашим генератором

Сервис (собственный формат):

name: auth-service
type: cognito | keycloak | custom
config:
  region: us-east-1 # for AWS
  bucket: auth-bucket

Интерфейс (собственный формат):

name: UserList
component: Table
source:
  api: my-api
  path: /users

Преимущества:

• Единая точка описания логики приложения.

• Возможность деплоя в AWS, YC, Docker, Kubernetes — без изменения кода.

• Нет vendor lock-in — можно мигрировать, меняя конфигурацию.

• Zero-cost при простоях — если использовать бессерверные платформы.

4. Что дальше: визуальный no-code редактор

Следующий шаг — визуальный редактор конфигураций, наподобие Bubble или Directual, но для инженеров.

Цель: описывать API, интерфейсы, сервисы — без написания YAML. Просто перетаскивать блоки, настраивать и генерировать готовые конфигурации.

5. Или поручить это LLM?

Мы экспериментируем с LLM-агентом, который переводит техническое описание (например, «создай API для регистрации с Cognito и отправкой писем через SES») в корректные конфиги. Цель — не заменить инженера, а перевести его с написания YAML на формулирование бизнес-логики

Вывод: vendor lock-in — не в облаке. Он в том, что вы пишете код под API, а не под бизнес-логику.

AWS — мощная платформа. Но если вы используете boto3, @aws-sdk, serverless framework — вы не используете облако. Вы служите ему.

Наше решение — не миграция, не multi-cloud. Это возврат контроля: описать, что нужно — и позволить системе выбрать, как это сделать.

Пиши один раз. Запускай везде. Управляй из любого облака.