Послуги з роботи з альтернативними хмарами та мультихмарою

Альтернативні хмарні платформи: Hetzner та DigitalOcean в production

Ми працюємо з альтернативними хмарними платформами — DigitalOcean, Hetzner Cloud, OVH, Selectel — і будуємо мультихмарні архітектури без vendor lock-in. Коли дані не прив'язані до юрисдикції РФ, вибір провайдерів розширюється. DigitalOcean та Hetzner — дві хмари, які стійко тримають аудиторію розробників за співвідношення ціни та передбачуваності. Hetzner при цьому — особливий випадок: вартість VDS там в 3–4 рази нижча за аналогічні конфігурації AWS або GCP, що робить його основним вибором, коли маржинальність інфраструктури критична.

Які альтернативні хмарні платформи обирають для production?

Ми віддаємо перевагу Hetzner та DigitalOcean — у кожного своя ніша. Hetzner — для compute-heavy задач, де важлива ціна гігабайта RAM та CPU-ядра. DigitalOcean — для managed-сервісів (Kubernetes, PostgreSQL, Redis), коли немає виділеного DevOps. Обидва провайдера підтримують Terraform, мають зрілі API та стабільні SLA. Нижче — розбір ключових рішень.

Hetzner: як витиснути максимум з дешевого заліза

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

Terraform-провайдер hetznercloud/hcloud зрілий та стабільний. Базова конфігурація кластера з трьома control-plane нодами та autoscaling worker pool:

resource "hcloud_server" "control_plane" { count = 3 name = "k8s-cp-${count.index}" image = "ubuntu-22.04" server_type = "cx31" location = "nbg1" ssh_keys = [hcloud_ssh_key.default.id] network { network_id = hcloud_network.k8s.id ip = "10.0.1.${count.index + 10}" } } resource "hcloud_load_balancer" "k8s_api" { name = "k8s-api-lb" load_balancer_type = "lb11" location = "nbg1" } 

Hetzner надає managed load balancer (lb11) з підтримкою TCP/HTTP балансування. Для K8s API-сервера оптимально: три control-plane ноди, Hetzner LB перед ними.

Kubernetes на Hetzner без managed-сервісу. Managed K8s (Hetzner Managed Kubernetes) поки в beta, тому більшість команд розгортають через k3s або kubeadm. k3s — бажаний варіант: менше пам'яті (control-plane живе в 512 MB), вбудований Traefik, SQLite або external etcd.

CSI для persistent volumes — hcloud-csi-driver. Він створює Hetzner Volumes (мережеві диски) як PersistentVolume. StorageClass за замовчуванням — hcloud-volumes. RWO, не RWX — якщо потрібен ReadWriteMany, використовуємо NFS або об'єктне сховище.

Мережа. Private Network обов'язкова для production. Публічні IP у кожного сервера за замовчуванням, але трафік між серверами всередині Private Network — безкоштовний та без лімітів. Трафік через публічний інтерфейс — з квотами та тарифами. Pod-to-pod через Flannel або Calico повинен ходити через private мережу, інакше при активній міжнодовій комунікації (Kafka, Cassandra) рахунок неприємно здивує.

Hetzner Object Storage — S3-сумісне сховище. Endpoint: https://fsn1.your-objectstorage.com. Значно дешевше за AWS S3. Velero backup з Hetzner S3 як backend:

# values.yaml для Velero configuration: provider: aws backupStorageLocation: bucket: k8s-backups config: region: fsn1 s3Url: https://fsn1.your-objectstorage.com s3ForcePathStyle: "true" 

Як уникнути vendor lock-in при роботі з альтернативними хмарами?

Мультихмарна стратегія — не про «запускаємо все всюди одночасно». Це про конкретне рішення: prod в Hetzner, CDN та DNS через Cloudflare, backups в S3 іншого провайдера, CI/CD на виділених раннерах в DigitalOcean.

Terraform workspace-підхід — зручний спосіб ізолювати середовища. Один модуль k8s-cluster з абстрактним інтерфейсом (input: node_count, node_size, region) і дві реалізації під різних провайдерів. terraform workspace select prod-hetzner && terraform apply — production, terraform workspace select staging-do && terraform apply — staging на DigitalOcean.

State locking критичний при командній роботі. Без нього паралельний terraform apply від двох інженерів гарантовано розвалює state:

Error: Error acquiring the state lock Error message: ConditionalCheckFailedException: The conditional request failed 

Після такого — terraform force-unlock <lock-id> з ручною перевіркою state на консистентність.

Crossplane — альтернатива Terraform для управління хмарними ресурсами з Kubernetes. Провайдери для Hetzner та DigitalOcean доступні. XRD описує абстракцію «кластер» або «база даних», конкретна реалізація — в Composition. Для команд, які вже живуть в Kubernetes, цікавий варіант: kubectl apply -f postgres-claim.yaml створює managed PostgreSQL у провайдера.

DigitalOcean: managed-сервіси без головного болю

DigitalOcean позиціонує себе як «хмара для розробників» — і це не маркетинг. DOKS (DigitalOcean Kubernetes Service) підіймається за 5 хвилин через UI або Terraform, DigitalOcean Managed PostgreSQL та Redis — ще 10 хвилин. Для невеликих production-сервісів без виділеного DevOps — розумний компроміс.

doctl — CLI, який реально використовується поруч з kubectl:

doctl kubernetes cluster create prod \ --region fra1 \ --node-pool "name=workers;size=s-4vcpu-8gb;count=3;auto-scale=true;min-nodes=2;max-nodes=8" \ --version 1.29 

DOKS підтримує cluster-autoscaler з коробки. Container Registry інтегрований через doctl registry kubernetes-manifest | kubectl apply -f -.

Слабке місце DigitalOcean — розмір інстансів. Найпотужніший Droplet без dedicated CPU — 32 vCPU, 192 GB RAM. Для GPU-задач або heavy compute потрібен інший провайдер. Для типового web+API стеку — вистачає з запасом.

Порівняння ключових характеристик:

Гібридні сценарії

Гібридна інфраструктура — не рідкість: частина сервісів на bare-metal (latency-critical або великі обсяги даних), частина в хмарі (публічні API, frontend, CDN). Зв'язка через VPN-тунель або Wireguard.

Wireguard між Hetzner VPS та on-premise сервером:

# /etc/wireguard/wg0.conf на хмарній стороні [Interface] PrivateKey = <cloud-private-key> Address = 10.100.0.1/24 ListenPort = 51820 [Peer] PublicKey = <onprem-public-key> AllowedIPs = 10.100.0.2/32, 192.168.1.0/24 Endpoint = <onprem-ip>:51820 PersistentKeepalive = 25 

Через цей тунель Kubernetes pods в Hetzner можуть звертатися до on-premise PostgreSQL або NFS. Latency тунелю — 10–30 ms залежно від відстані. Для синхронних read-запитів до БД допустимо, для real-time — ні.

Процес роботи і що входить

Наш підхід — аналітика → проєктування → реалізація → тест → деплой.

1. Аудит поточної інфраструктури (3–5 днів): оцінка навантаження, ліцензій, залежностей. Визначаємо, який провайдер підходить під конкретні задачі.
2. Проєктування (1–2 тижні): Terraform-модулі, схеми мережі, CI/CD пайплайни.
3. Реалізація (1–4 тижні залежно від складності): розгортання Kubernetes, бази даних, об'єктного сховища.
4. Тестування (3–5 днів): навантажувальне тестування, перевірка відмовостійкості.
5. Деплой та документація: здача інфраструктури, runbook для експлуатації, навчання команди.

Що входить в роботу:

• Terraform-конфігурації для всіх оточень
• Код Kubernetes маніфестів та Helm-чартів
• Налаштування observability (Prometheus + Grafana, логи в Loki)
• Документація по мережі, резервному копіюванню, disaster recovery
• Навчання вашої команди роботі з новою інфраструктурою

Орієнтовні терміни

Вартість розраховується після аудиту — зв'яжіться з нами, оцінимо проєкт за 1 день.

Ми працюємо з альтернативними хмарами більше 5 років, виконали 30+ проєктів з міграції та побудови мультихмарних архітектур. Сертифіковані Kubernetes адміністратори (CKA) та Terraform асоціати. Гарантуємо документацію та підтримку після здачі.