Реалізація Cloud-Agnostic архітектури для уникнення vendor lock-in

Реалізація Cloud-Agnostic архітектури для уникнення vendor lock-in

Cloud-agnostic архітектура — це проектування системи так, щоб вона могла працювати на будь-якому хмарному провайдері без значної переробки. Не абстракція ради абстракції, а конкретні рішення, які зберігають можливість смміни провайдера або паралельного використання кількох.

Що таке vendor lock-in та коли він проблема

Vendor lock-in виникає при використанні proprietary-сервісів провайдера:

• AWS Lambda + API Gateway + DynamoDB + SQS — повна залежність від AWS
• GCP Firestore + Cloud Run + Pub/Sub — залежність від GCP

Lock-in — не завжди погано. Використання managed-сервісів прискорює розроблення та знижує операційне навантаження. Проблема виникає коли:

• Провайдер різко змінює ціноутворення (+200% за 3 місяці — реальні випадки)
• Провайдер недоступний у потрібній юрисдикції
• Потрібно розгорнути on-premise копію
• M&A активність вимагає смміни провайдера

Рівні cloud-agnostic рішень

Compute (контейнери). Docker + Kubernetes — de facto стандарт для cloud-agnostic compute. Один Kubernetes маніфест працює у EKS, GKE, AKS, k3s on-premise. Уникати: Fargate-specific анотації, GKE autopilot-specific конфігурації.

Хранилище об'єктів. S3 API став стандартом де-факто — MinIO, Ceph, Wasabi, Backblaze B2, GCS (через compatibility layer) всі підтримують S3 API. Писати код через S3-сумісний клієнт:

import boto3

s3 = boto3.client(
    's3',
    endpoint_url=os.environ['STORAGE_ENDPOINT'],  # може бути S3, MinIO, або будь-який S3-сумісний
    aws_access_key_id=os.environ['STORAGE_KEY'],
    aws_secret_access_key=os.environ['STORAGE_SECRET'],
)

База даних. PostgreSQL доступна везде: AWS RDS/Aurora, GCP Cloud SQL, Azure Database, Railway, Supabase, self-hosted. Уникати: Oracle-specific функції, SQL Server proprietary синтаксис.

Очереди повідомлень. RabbitMQ або Kafka — працюють везде. NATS — cloud-native, self-hosted легко. Уникати SQS/Pub/Sub як primary messaging layer якщо потрібна переносимість.

DNS та CDN. Cloudflare працює поверх будь-якого провайдера та не створює lock-in.

Terraform як інструмент абстракції IaC

Terraform провайдери для AWS, GCP, Azure, Cloudflare — один інструмент для всього. Але переиспользуємі модулі потрібно писати акуратно:

# Модуль kubernetes_cluster — абстракція над EKS/GKE/AKS
module "k8s" {
  source         = "./modules/kubernetes"
  provider_type  = var.cloud_provider  # "aws" | "gcp" | "azure"
  node_count     = 3
  node_size      = "standard-4cpu-16gb"
}

# Всередину модуля — conditional resources за provider_type
resource "aws_eks_cluster" "this" {
  count = var.provider_type == "aws" ? 1 : 0
  ...
}
resource "google_container_cluster" "this" {
  count = var.provider_type == "gcp" ? 1 : 0
  ...
}

OpenTofu замість Terraform

HashiCorp змінила ліцензію Terraform на BSL у 2023 році. OpenTofu — community fork під MPL-2.0, повністю сумісний. Для cloud-agnostic стратегії — OpenTofu переважніший: без ліцензійних ризиків.

Service Mesh як абстракція над мережею

Istio або Linkerd створюють єдину service mesh поверх будь-якого Kubernetes. Трафік-політики, mutual TLS, circuit breaking — працюють однаково у EKS та GKE.

Observability: OpenTelemetry

OpenTelemetry — vendor-neutral стандарт для метрик, трейсів та логів. Інструментувати додаток один раз, відправляти у будь-який backend (Grafana, Datadog, Jaeger, Zipkin):

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint=os.environ['OTEL_EXPORTER_ENDPOINT']))
)
trace.set_tracer_provider(provider)

Конфігурація через змінні оточення

Twelve-Factor App принцип: конфігурація через env vars, не захардкодені endpoint'и. Це саме по собі забезпечує переносимість.

Що не можна зробити cloud-agnostic

Деякі речі мають сенс тільки у конкретній хмарі:

• AWS Lambda@Edge — тільки AWS
• GCP BigQuery — унікальний за можливостями, аналоги існують (ClickHouse), але з витратами
• Azure Active Directory інтеграція — якщо клієнти використовують O365

Прагматичний підхід: ізолювати такі залежності у окремих сервісах з чітким API. Решта системи cloud-agnostic, а ці компоненти — замінювані адаптери.

Терміни реалізації

• Аудит поточних залежностей від провайдера — 2-3 дні
• Міграція на cloud-agnostic storage (S3 API) — 2-5 днів
• Kubernetes-based compute (якщо ще нема) — 5-10 днів
• Terraform модулі для абстракції — 5-10 днів
• OpenTelemetry instrumentation — 3-7 днів