Спитайте десять інфраструктурних команд, чи є в них стратегія виходу з cloud, і дев'ять скажуть «так». Спитайте, з чого вона складається, і зазвичай почуєте про сторінку вікі, написану під час vendor review, зі списком того, які сервіси пропрієтарні, а які - портативні. Це інвентаризація, а не стратегія. Справжній тест менш комфортний: якщо ваш провайдер подвоїть ціни, змінить юрисдикцію чи призупинить ваш акаунт у вівторок вранці - скільки тижнів пройде, перш ніж ви обслуговуватимете трафік десь в іншому місці, і хто у вашій команді може відповісти на це, не відкриваючи Excel?
Регуляторний тиск тут реальний, але це не найцікавіша частина. Data Act прибирає плату за перемикання провайдера, а разом з нею - і виправдання для фінансового відділу. Schrems II та CLOUD Act прибрали юридичне виправдання ще роки тому. Що залишається - це інженерна реальність, і жодна директива її не виправить. Регулятор може зробити вихід дешевшим на папері; він не може змусити ваш deployment pipeline, вашу модель ідентичності, ваші DNS-записи й ваш шлях відновлення запрацювати у другого провайдера. Ця робота - ваша, і саме вона й становить всю вартість.
Що таке стратегія виходу з cloud насправді
Стратегія виходу - це вимірювана властивість вашої архітектури, а не документ. Вимірювання пряме: яку частку вашої робочої інфраструктури ви змогли б підняти в іншого провайдера, використовуючи інструменти, якими вже вмієте користуватися, не написавши жодного нового рядка коду? Для більшості команд чесна відповідь лежить десь між сорока й сімдесятьма відсотками, і розрив ніколи не там, де вони очікували. Рідко це застосунок. Це managed-база даних, черга, семантика object storage і з десяток дрібних операційних звичок, які ніхто ніколи не записав.
Помилка - вірити, що наявність двох провайдерів щось доводить. Багато компаній тримають продакшн в одного hyperscaler'а й забутий тестовий проєкт десь ще - а потім називають це multi-cloud. Опціональність - це не наявність другого акаунта, а здатність нею скористатись. Поки хоча б один реальний workload - з моніторингом, бекапами, on-call-графіком і реально виконаним відновленням - не працює десь окрім вашого основного провайдера, у вас є другий рахунок, а не друга опція.
Три речі, які роблять вихід складним
По-перше, data gravity - нудна, але вирішальна річ. Байти дешево копіювати, але дорого узгоджено переносити, поки система працює наживо. У той момент, коли ваші дані опиняються всередині пропрієтарного managed-сервісу, вихід перестає бути копіюванням і стає переписуванням усього, що з цими даними взаємодіє. Саме тому команди, які тримають свій стан у чомусь, що вони могли б запустити самі - навіть якщо сьогодні вони цього не роблять, - зберігають опції, які команди на повністю managed-стеках тихо втрачають за кілька років.
По-друге, операційна м'язова пам'ять. Ваша команда знає модель ідентичності одного провайдера, одну абстракцію файрволу, один спосіб іменувати мережі, розкладку однієї консолі о третій ночі. Перейдіть до другого провайдера - і кожна з цих речей стає незнайомою саме під тиском. Ціна - не вихідні на міграцію; це наступні шість місяців інцидентів, які люди, що вгадують, обробляють трохи повільніше. Ніхто не закладає це в оцінку міграції, а зазвичай саме це найбільший рядок у цій оцінці.
По-третє, атрибуція витрат. Більшість команд не можуть сказати вам, скільки коштує окремий workload сьогодні, а це робить порівняння провайдерів принципово неможливим. Якщо ваш рахунок - це одне число на провайдера, а ваша архітектура - сорок сервісів, розмова про вихід вироджується у здогадки на відчуття. Перш ніж оцінити вартість виходу, вам потрібні витрати, розбиті по сервісу, проєкту й середовищу, по кожному провайдеру, яким ви користуєтесь, включно з дрібними, про які ви забули. Це непоказна підготовча робота, і вона - передумова для будь-якого іншого рішення тут.
Як уникнути прив'язки до cloud-провайдера в ЄС
Якщо ви хочете уникнути прив'язки до одного cloud-провайдера (vendor lock-in), ринок ЄС має кращу форму, ніж припускає більшість команд. Співвідношення ціни й продуктивності Hetzner робить рахунки hyperscaler'ів схожими на похибку округлення - причому не на вашу користь. OVHcloud має власні дата-центри та оптоволоконну мережу по всій Європі. Scaleway пропонує по-справжньому сучасний developer experience з Франції. UpCloud надає надійний compute з Фінляндії. Жоден з них не замінює всі сервіси hyperscaler'а - але для compute, block storage і мережі, куди йде більшість інфраструктурних витрат, вони цілком спроможні й підпорядковуються лише праву ЄС.
Чесна межа - це managed-сервіси. Якщо ваш продукт побудований на пропрієтарній serverless-базі даних, конкретній event bus або платформі machine learning без аналогів деінде, жоден європейський ентузіазм не змінить цього за квартал. Корисний крок - не героїчна міграція «все або нічого». Це - точно знати, які навантаження портативні вже сьогодні, запускати частину з них там, де вам підходять юрисдикція та ціна, а решту трактувати як усвідомлене, задокументоване рішення, а не випадковість історії.
Що насправді включає репетиція виходу
Ставтеся до цього як до навчання з відновлення (restore drill) - бо це воно і є. Виберіть реальне навантаження - не маркетинговий сайт, а щось зі станом і runbook'ом. Розгорніть його у другого провайдера. Спрямуйте туди частину реального трафіку. Навмисно зламайте його і подивіться, чи працюють там же ваш моніторинг, модель доступу та графік чергувань (on-call). Потім запишіть астрономічний час виконання і все, що вас здивувало. Репетиція без жодних несподіванок зазвичай означає, що ви обрали щось надто просте.
Причина, чому більшість команд ніколи не репетирують це, - не лінь, а інструментарій. Кожен додатковий провайдер означає ще одну консоль, ще одну модель облікових даних, ще один експорт білінгу, ще один набір особливостей, які треба вивчити - а маленька команда платформи не може засвоювати це щоразу для кожної хмари. Це операційний податок, який тихо перетворює розмову про суверенітет на проблему наступного року - і так щороку. І це саме та проблема, яку control plane і має зняти з вашого столу.
Саме таким ми й побудували Sencai. Один control plane для одинадцяти провайдерів - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode від Akamai та Oracle Cloud - плюс ваші власні сервери через host-агент. Мережі, firewall'и та DNS керуються там, де вони фактично живуть - у провайдера, тож другий провайдер стає лише плиткою в тому самому інтерфейсі, а не другою командою платформи. Витрати відстежуються по кожній організації з лімітами, тож розмова про вихід має під собою конкретні цифри.
Ви можете працювати на власних акаунтах у провайдерів або купити потужність через нас і мати один рахунок - підтримується і те, і те, і цей вибір можна змінити пізніше. У будь-якому разі результат один, і це єдина цифра, яку варто доповідати наверх: скільки часу знадобиться, щоб запуститися десь-інде. Виміряйте це одного разу - і страх зникає. Вимірюйте це щокварталу - і це стає важелем: на переговорах, під час перевірки закупівель і в той день, коли хтось поставить це питання по-справжньому.