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

Virtual Machines

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

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

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

Azure Kubernetes Service (AKS)

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

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

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

Azure Container Apps

Container Apps — золотая середина: вы упаковываете сервис в контейнер, а облако само запускает его и масштабирует, вплоть до нуля при отсутствии обращений. Кластер держать не нужно. Ближе всего к нише ECS/Fargate из AWS; под капотом — управляемый Kubernetes, но вы его не видите.

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

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

Azure Functions

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

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

App Service

Отдельно стоит App Service — платформа для веб-приложений и API (PaaS): вы отдаёте код или контейнер, а Azure сам держит веб-сервер, масштабирование и обновления. Удобно для классических веб-приложений, где не нужен ни полный контроль машины, ни событийная модель функций.

Как выбрать

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

  • Azure Functions — событийная склейка, редкие или нерегулярные вызовы, минимум забот.
  • App Service — обычное веб-приложение или API без возни с инфраструктурой.
  • Container Apps — есть контейнер, нагрузка неравномерная, кластер держать не хочется.
  • AKS — много сервисов, нужна оркестрация и единый выкат, команда знает k8s.
  • Virtual Machines — нужен полный контроль или перенос «как есть».

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

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

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

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