Один и тот же backend в Yandex Cloud можно запустить четырьмя разными способами — от «дайте мне голую виртуальную машину, дальше я сам» до «вот функция, вызывайте её на событие». Выбор влияет на то, сколько эксплуатации ляжет на вас и сколько вы заплатите. Разберём все четыре и как выбирать. Сеть и доступ, на которых всё это стоит, — в основах Yandex Cloud.

Compute Cloud: виртуальные машины

Compute Cloud — это виртуальные машины: вы получаете сервер с операционной системой и делаете с ним что хотите. Аналог EC2 в AWS.

Максимум контроля и максимум ответственности: вы сами ставите софт, накатываете обновления, настраиваете автозапуск сервиса, следите за диском. Облако отвечает только за «железо» под машиной и за то, чтобы её можно было пересоздать.

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

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

Managed Service for Kubernetes

Managed Kubernetes — это Kubernetes, у которого управляющую часть (control plane) обслуживает Yandex Cloud, а вы работаете с рабочими узлами и деплоите на них контейнеры. Аналог EKS в AWS.

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

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

Чего не снимает: сам Kubernetes — это отдельная система, которую надо уметь готовить: манифесты, сеть кластера, обновления узлов. Managed-вариант снимает эксплуатацию control plane, но не знание Kubernetes.

Serverless Containers

Serverless Containers — золотая середина: вы упаковываете сервис в контейнер (Docker-образ), а облако само его запускает по запросу и масштабирует, вплоть до нуля, когда обращений нет. Кластер держать не нужно. Это ближе всего к нише ECS/Fargate из AWS.

Когда брать: у вас есть контейнер, но поднимать ради него Kubernetes не хочется, а нагрузка неравномерная — то густо, то пусто. Платите только за фактические вызовы, а не за постоянно включённую машину.

Чего не снимает: подход требует, чтобы сервис умел быстро стартовать и был готов к тому, что его в любой момент могут погасить и поднять заново (stateless). Долгие фоновые процессы и состояние в памяти сюда не ложатся.

Cloud Functions

Cloud Functions — это код без сервера: вы загружаете функцию (кусок кода на Python, Node.js, Go и т.д.), а облако вызывает её на событие — HTTP-запрос, сообщение в очереди, файл в хранилище. Аналог AWS Lambda.

Самый «лёгкий» способ: ни машины, ни контейнера — только функция. Идеален для склеек и обработчиков: реакция на загрузку файла, обработчик вебхука, периодическая задача. Подробно — в отдельной статье про serverless.

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

Чего не снимает: у функций есть ограничения по времени работы и памяти, а также «холодный старт» — задержка первого вызова после простоя. Для тяжёлых и долгих задач это не инструмент.

Как выбрать

Простое правило по возрастанию контроля и эксплуатации:

  • Cloud Functions — событийная склейка, редкие или нерегулярные вызовы, минимум забот.
  • Serverless Containers — есть контейнер, нагрузка неравномерная, кластер держать не хочется.
  • Managed Kubernetes — много сервисов, нужна оркестрация и единый выкат, команда знает k8s.
  • Compute Cloud — нужен полный контроль над машиной или перенос «как есть».

Частая ошибка новичка — начинать с Kubernetes «потому что так делают все». Для одного-двух сервисов Serverless Containers или обычная виртуальная машина проще, дешевле и надёжнее в эксплуатации. Оркестратор оправдывает себя, когда сервисов и команд становится много.

Где это применяется

Выбор способа запуска — одно из первых архитектурных решений в облаке, и оно тянет за собой остальное: масштабирование, доступ, сеть. Куда бы ни поехал сервис, он опирается на сеть (внутренние адреса, группы безопасности) и IAM (привязанный сервисный аккаунт вместо ключей).

Что учить дальше: как из выбранного варианта собрать устойчивую к нагрузке и сбоям систему — в масштабировании и доступности; событийную модель — в serverless; а чтобы поднимать всё это кодом, а не кликами, — Terraform в Yandex Cloud. Тот же набор вариантов есть и в AWS — сравните с разбором, где запускать сервис в AWS.