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

Compute Engine

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

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

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

Google Kubernetes Engine (GKE)

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

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

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

Cloud Run

Cloud Run — золотая середина и визитная карточка serverless в GCP: вы упаковываете сервис в контейнер, а облако само запускает его по запросу и масштабирует, вплоть до нуля при отсутствии обращений. Кластер держать не нужно. Ближе всего к нише ECS/Fargate из AWS, но проще: отдал контейнер — получил работающий HTTP-сервис.

Когда брать: есть контейнер (или даже просто код — Cloud Run умеет собрать образ сам), поднимать ради него полноценный GKE не хочется, нагрузка неравномерная. Платите за фактическое потребление.

Чего не снимает: сервис должен быстро стартовать и переживать пересоздание (stateless).

Cloud Functions

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

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

App Engine

Отдельно стоит App Engine — исторически первая PaaS-платформа Google для веб-приложений: отдаёте код, а Google держит веб-сервер, масштабирование и обновления. Сегодня для новых проектов чаще выбирают Cloud Run (гибче и на контейнерах), но App Engine всё ещё встречается.

Как выбрать

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

  • Cloud Functions — событийная склейка, редкие или нерегулярные вызовы, минимум забот.
  • Cloud Run — есть контейнер или код, нужен HTTP-сервис без возни с кластером; в GCP это выбор по умолчанию для большинства сервисов.
  • GKE — много сервисов, нужна оркестрация и единый выкат, команда знает k8s.
  • Compute Engine — нужен полный контроль или перенос «как есть».

Частая ошибка новичка — начинать с GKE «потому что так делают все». Для одного-двух сервисов Cloud Run проще, дешевле и надёжнее.

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

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

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