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

Способ 1. Виртуалка с ручной настройкой

Классический вариант: одна или несколько ВМ, на которых вручную установлены зависимости, база данных и само приложение. Подходит, если сервис небольшой, релизы редкие, а в команде есть человек, который понимает, что происходит на сервере.

  • Плюсы: полный контроль, предсказуемая стоимость, минимум абстракций.
  • Минусы: ручное обновление, отсутствие самовосстановления, риск «снежинки» — сервера, который никто не решается пересоздать.
  • Когда хватит: один-два разработчика, монолит, база на том же хосте, нет требований к горизонтальному масштабированию.

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

Способ 2. Docker Compose на одной машине

Приложение и база описываются в docker-compose.yml, запускаются одной командой. Это уже шаг к воспроизводимости: окружение одинаково на локальной машине и на сервере.

  • Плюсы: простота, декларативное описание, легко поднять staging, меньше «works on my machine».
  • Минусы: нет отказоустойчивости — упал хост, упало всё; масштабирование ограничено одной машиной; обновления требуют простоя или ручных манипуляций.
  • Когда хватит: небольшой продакшен, допустим короткий простой, нет требований к SLA выше 99%.

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

Способ 3. Managed-контейнеры (ECS, Cloud Run, App Runner)

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

  • Плюсы: меньше инфраструктурной работы, встроенное масштабирование, интеграция с балансировщиками и секретами.
  • Минусы: привязка к провайдеру, ограничения на кастомизацию, не всегда прозрачная стоимость при росте нагрузки.
  • Когда хватит: команда без выделенного DevOps, сервис с переменной нагрузкой, готовность жить в экосистеме одного облака.

Это часто оптимальная точка для сервиса с одной базой данных: вы получаете автоматический перезапуск и масштабирование без необходимости администрировать кластер.

Способ 4. Kubernetes

Kubernetes даёт декларативное управление, самовосстановление, горизонтальное масштабирование и единый способ запуска множества сервисов. Но платить за это приходится сложностью: нужно понимать pod'ы, deployment'ы, service'ы, ingress, persistent volume, RBAC и мониторинг.

  • Плюсы: стандартизация, отказоустойчивость, гибкое масштабирование, экосистема инструментов.
  • Минусы: высокий порог входа, операционные расходы, риск overengineering для маленького сервиса.
  • Когда оправдан: несколько сервисов и команд, частые релизы, требования к доступности, необходимость изоляции окружений, планы по мультиоблаку.

Кластер ради одного приложения с одной базой — почти всегда избыточен. Исключение — если вы уже используете managed Kubernetes и он для вас не дороже альтернатив, либо если Kubernetes нужен для будущего роста, который подтверждён планами, а не предположениями.

Как выбрать: критерии и типичные ошибки

Задайте себе несколько вопросов. Сколько сервисов вы планируете запускать в ближайший год? Как часто выкатываете обновления? Есть ли в команде человек, готовый отвечать за инфраструктуру? Какой простой допустим? Если ответы указывают на один сервис, редкие релизы и отсутствие выделенного DevOps — скорее всего, вам хватит managed-контейнеров или Compose.

  • Ошибка 1: выбирать Kubernetes «на вырост», не имея плана и ресурсов на его поддержку.
  • Ошибка 2: оставаться на ручной виртуалке, когда обновления уже делаются вручную и с риском.
  • Ошибка 3: путать контейнеризацию и оркестрацию — Docker сам по себе не даёт отказоустойчивости.
  • Ошибка 4: игнорировать стоимость: managed-сервисы удобны, но при росте нагрузки счёт может оказаться выше ожидаемого.

Практический шаг: начните с managed-контейнеров или Compose, зафиксируйте метрики — время простоя, скорость релизов, количество ручных операций. Когда эти показатели перестанут устраивать, переход на Kubernetes будет обоснованным, а не модным. Инфраструктура должна решать проблемы, а не создавать их.