Где хостились приложения в проекте?

Ответ на вопрос о хостинге приложений в проектах

В моей практике в качестве IT Project Manager выбор хостинга для приложений всегда был критически важным архитектурным решением, напрямую влияющим на бюджет, масштабируемость, безопасность и производительность проекта. Стратегия хостинга зависела от типа приложения, его нагрузки, требований к доступности (SLA) и этапа жизненного цикла проекта.

Основные модели хостинга, применявшиеся в проектах

• Выделенные серверы (Bare Metal) и VPS/VDS: Использовались для legacy1. Выделенные серверы (Bare Metal) и VPS/VDS: Использовались для legacy-систем, корпоративных порталов с высокими требованиями к безопасности и изоляции, а также на начальных этапах проектов с предсказуемой и стабильной нагрузкой. Пример: внутренняя CRM для крупного ритейлера.

    *   **Провайдеры:** Hetzner, Selectel, Infobox.
    *   **Аргументы за:** Полный контроль, предсказуемая стоимость, совместимость со специфичным ПО.
    *   **Аргументы против:** Длительное время provisioning2. **Публичное облако (IaaS, PaaS):** Стало стандартом для новых проектов и проектов с переменной или растущей нагрузкой. Активно использовались модели **IaaS** (виртуальные машины) и **PaaS** (управляемые сервисы).
    *   **Платформы:** **Yandex Cloud** (для проектов с фокусом на РФ и СНГ), **AWS** (для международных и высоконагруженных проектов), реже **Google Cloud** и **Microsoft Azure**.
    *   **Ключевые сервисы:**
        *   **Вычислительные мощности:** Yandex Compute Cloud, AWS EC2.
        *   **Контейнеризация и оркестрация:** **Kubernetes** на базе Yandex Managed Kubernetes или AWS EKS. Для меньших нагрузок — AWS ECS.
        *   **Бессерверные вычисления (Serverless):** AWS Lambda, Yandex Cloud Functions — для event-driven3. **Гибридная и мультиоблачная модель (Hybrid/Multi-Cloud):** Применялась в крупных проектах для распределения рисков, соблюдения требований к резидентности данных или интеграции унаследованной инфраструктуры с облаком.
    *   **Пример архитектуры:** Frontend и API хостятся в **Yandex Cloud**, система аналитики и AI/ML-модели работают в **AWS** из-multicloud** (для высоконагруженных и глобальных проектов).

Пример декларации инфраструктуры как кода (IaC) для облачного хостинга

Определение среды хостинга через код было обязательной практикой. Вот упрощенный пример описания кластера Kubernetes и балансировщика в Yandex Cloud с помощью Terraform:

# main.tf - Пример конфигурации Terraform для Yandex Cloud
provider "yandex" {
  zone = "ru-central1-a"
}

resource "yandex_kubernetes_cluster" "my_app_cluster" {
  name        = "production-cluster"
  network_id = yandex_vpc_network.app_network.id

  master {
    regional {
      region = "ru-central1"
      location {
        zone      = "ru-central1-a"
        subnet_id = yandex_vpc_subnet.app_subnet.id
      }
    }
    version = "1.24"
    public_ip = true
  }

  service_account_id = yandex_iam_service_account.sa.id
  node_service_account_id = yandex_iam_service_account.sa.id
}

resource "yandex_kubernetes_node_group" "app_nodes" {
  cluster_id = yandex_kubernetes_cluster.my_app_cluster.id
  name       = "frontend-nodes"

  instance_template {
    platform_id = "standard-v2"
    resources {
      memory = 4
      cores  = whistleblowing"  # Сервис публикации статей и расследований с требованиями анонимности и устойчивости к DDoS. Использовался **On-premises** хостинг в дата-центре с повышенным уровнем защиты, комбинированный с Cloudflare для распределения трафика.
2.  **E-commerce Marketplace:** Высоконагруженная торговая площадка. Ядро на **AWS** (EKS, RDS, ElastiCache), CDN — Cloudfront, статика — S3, аналитика — отдельный кластер в **Yandex Cloud**.
3.  **Мобильное приложение для доставки:** Backend был построен на **бессерверной архитектуре** AWS (API Gateway + Lambda + DynamoDB) для экономии на этапе стартапа и автоматического масштабирования в часы пик.

### Критерии выбора хостинга в рамках управления проектом

Как PM, я не принимал техническое решение единолично, но обеспечивал процесс, в рамках которого архитекторы и DevOps-инженеры выбирали решение на основе согласованных критериев:

*   **Бюджетные ограничения:** CAPEX vs OPEX, анализ Total Cost of Ownership (TCO).
*   **Требования к производительности и SLA:** Целевые показатели времени отклика (RTT) и доступности (например, 99.95%).
*   **Вопросы безопасности и compliance:** Хранение персональных данных (152-ФЗ, GDPR), необходимость сертификации (ФСТЭК, PCI DSS).
*   **Навыки команды:** Готовность и способность DevOps.