Снижение vendor lock: реализация cloud-agnostic архитектуры

Это не значит что нужно отказаться от managed-сервисов провайдера везде. Managed PostgreSQL — используем. Просто документируем SQL extensions и специфичные параметры, которые нужно будет сконфигурировать у другого провайдера.

Terraform с провайдерной абстракцией

Паттерн — общий интерфейс через variables + переключение реализации через workspace или var.

# modules/kubernetes-cluster/variables.tf
variable "provider_type" {
  type = string
  # "aws" | "gcp" | "azure"
}

variable "cluster_name" {
  type = string
}

variable "node_pools" {
  type = list(object({
    name          = string
    instance_type = string
    min_size      = number
    max_size      = number
  }))
}

Реализации под каждый провайдер — в отдельных файлах:

modules/kubernetes-cluster/
  variables.tf # общий интерфейс
  outputs.tf # общие outputs
  aws.tf # EKS ресурсы (only if var.provider_type == "aws")
  gcp.tf # GKE ресурсы
  azure.tf # AKS ресурсы

Условная логика через count = var.provider_type == "aws" ? 1 : 0 для каждого блока ресурсов.

Helm charts без провайдерных аннотаций

Пример values.yaml структуры для cloud-agnostic деплоя:

ingress:
  enabled: true
  className: nginx # не "alb", не "gce"
  annotations: {} # пустые по умолчанию, переопределяются в values-aws.yaml
persistence:
  storageClass: "" # default StorageClass кластера
  size: 10Gi
serviceAccount:
  annotations: {} # IRSA / Workload Identity — в overlay, не в base

В values-aws.yaml — добавляем AWS-специфику, в values-gcp.yaml — GCP. Base chart остаётся чистым.

External Secrets Operator как универсальный слой секретов

ESO работает как мост между Kubernetes и любым secrets backend. Приложение читает стандартный Kubernetes Secret, ESO синхронизирует его из нужного backend:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
---
# Для GCP — меняем только spec.provider:
# provider:
#   gcpsm:
#     projectID: my-project

ExternalSecret объекты — одинаковые для обоих провайдеров. Меняется только SecretStore. Приложения не знают, откуда пришли секреты.

Практика: что делать с Object Storage

S3-compatible API — стандарт. GCS, MinIO, Backblaze B2, Cloudflare R2 — все поддерживают его. Код приложения пишем через boto3 или AWS SDK с endpoint_url:

import boto3
s3 = boto3.client(
    's3',
    endpoint_url=os.environ['STORAGE_ENDPOINT'],  # https://storage.googleapis.com
    aws_access_key_id=os.environ['STORAGE_ACCESS_KEY'],
    aws_secret_access_key=os.environ['STORAGE_SECRET_KEY'],
)

STORAGE_ENDPOINT — единственное, что меняется при смене провайдера.

Почему cloud-agnostic не решает всё?

Не стоит ожидать, что cloud-agnostic архитектура даст возможность переехать за день. Некоторые вещи останутся провайдер-специфичными в любом случае: мониторинг, логирование, ценообразование на трафик, support-модель. Цель — сократить scope переезда до infrastructure-as-code слоя и нескольких конфигурационных файлов, а не до переписывания приложений. Мультиоблачная стратегия эффективна только при грамотной абстракции.

Что входит в работу

Мы предоставляем гарантию на результаты аудита: вы получите документ с полным списком точек vendor lock и рекомендациями. У нас есть сертифицированные специалисты по Kubernetes и Terraform. При внедрении cloud-agnostic архитектуры мы выполняем:

• Аудит текущего стека с выявлением точек vendor lock.
• Дорожную карту миграции с оценкой трудозатрат.
• Разработку провайдер-нейтральных модулей Terraform и Helm charts.
• Настройку External Secrets Operator и S3-совместимого хранилища.
• Документацию по процессу миграции для каждого провайдера.
• Обучение вашей команды работе с cloud-agnostic подходом.
• Поддержку на этапе переезда (2-4 недели после завершения).

Мы предлагаем комплексный DevOps консалтинг по внедрению cloud-agnostic архитектуры. Получите консультацию инженера — оценим ваш проект за 2 дня.

Ориентиры по срокам

Стоимость рассчитывается индивидуально после аудита текущего стека и оценки степени привязки к провайдеру. Свяжитесь с нами — оценим за 2 дня и предложим оптимальное решение.