Є два способи дозволити комусь іншому керувати вашою інфраструктурою. У першому ви купуєте cloud у них: вони тримають акаунти провайдера, вони отримують рахунок, а ви - рахунок з націнкою та адресу підтримки. У другому - bring your own cloud, зазвичай скорочують до BYOC - ви залишаєте собі власні акаунти в Hetzner, AWS чи OVHcloud, власний контракт, власний рахунок, і надаєте платформі управління обмежені за scope облікові дані, щоб вона діяла від вашого імені. Ці дві моделі виглядають схоже на демо і поводяться абсолютно по-різному в той день, коли ви захочете вийти.
Модель перепродажу - не афера; це легітимний бізнес із реальними перевагами, здебільшого навколо одного рахунка й одного місця, куди можна поскаржитися. Те, чим ви жертвуєте, менш очевидне. Ваші договірні відносини - з реселером, а не з провайдером, тож SLA, який ви можете реально примусово виконати, - це SLA реселера. Знижки за committed use, стартап-кредити й узгоджене ціноутворення - все проходить через них. І ідентичність ресурсу, акаунт, у якому насправді живуть сервери, належить комусь іншому, а це означає, що вихід - це міграція, а не просто скасування.
Що ви зберігаєте, коли зберігаєте контракт
При BYOC відносини з провайдером залишаються саме там, де їх і очікував би побачити юрист. Інстанси - у вашому акаунті. Тікети підтримки відкриваєте ви. Рахунок приходить у форматі, який ваша фінансова команда вже вміє звіряти, від компанії, щодо якої ви вже провели due diligence, у юрисдикції, яку ви вже проаналізували. Якщо ваша compliance-позиція залежить від того, хто юридично оперує сервісом - а це, після Schrems II, і є цікаве питання, а не те, де фізично стоять сервери, - впровадження control plane не додає жодної нової ланки в цей ланцюг.
Тест на вихід робить різницю конкретною. Що станеться, якщо платформа управління зникне за одну ніч? При перепродажі ваші сервери - в акаунті, який ви не контролюєте, і відповідь включатиме юристів. При BYOC сервери продовжують працювати точно так само; ви втратили консоль, інвентаризацію й трохи автоматизації - це прикро, але не екзистенційно. Ця асиметрія варта більше, ніж будь-який список фіч, і це перше, що варто перевірити, перш ніж щось підписувати.
Що BYOC вимагає від платформи
Ціна цієї моделі в тому, що платформа тепер тримає справжні продакшн-облікові дані для акаунтів, якими не володіє. До цього обов'язку треба ставитися буквально. Облікові дані шифруються at rest за допомогою AES-256-GCM, обмежені за scope однією організацією, ніколи не діляться між тенантами і ніколи не повертаються у відповіді API - поля приховані і на виході, і зашифровані на вході. Кожна з цих вимог виглядає нудною рівно до того моменту, коли звичайний list-ендпоінт вперше просять серіалізувати запис з обліковими даними.
А ще є режим відмови, який ніхто не планує. Задача provisioning'у приходить без прикріпленого credential'а: баг, race condition, повідомлення зі старішої версії сервісу. Спокуслива поведінка - відкотитися на власний токен провайдера платформи, щоб задача все ж виконалась. Ми одного разу випустили таку поведінку в продакшн, і вона зробила саме те, що й мала зробити - створила реальну машину на власному акаунті платформи, виставила рахунок не тій стороні, і зробила це невидимим в інвентаризації клієнта. Тепер за замовчуванням - fail-closed. Задача без credential'а відхиляється, а увімкнення fallback вимагає явного environment-флагу.
Де multi-provider BYOC стає складним
Один провайдер - це інтеграція; одинадцять - це вже проблема таксономії. Наразі Sencai керує Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode від Akamai та Oracle Cloud, плюс локальними та bare-metal серверами через host-агента. У кожного з них своя модель автентифікації, своя система квот, свій словник і своя думка про те, чи належить файрвол машині, мережі, чи проєкту. Нормалізувати це, не збрехавши при цьому, - і є більша частина інженерної роботи.
Межа, яку ми намагаємось тримати, - control plane керує самим провайдером, а не його копією. Коли ви створюєте мережу, правило файрволу чи DNS-зону в Sencai, виклик іде до API провайдера, і об'єкт існує саме там - видимий у їхній консолі, видаляється їхнім CLI, реальний для будь-кого, хто про нас навіть не чув. Платформа, яка лише фіксує намір у власній базі даних, видає дуже переконливу інвентаризацію речей, яких, можливо, взагалі не існує.
Білінг слідує тій самій логіці. Оскільки рахунок залишається у провайдера, робота платформи - не виставляти вам рахунок. Це атрибуція та контроль. Витрати відстежуються по організації й проєкту в кожному підключеному акаунті, з лімітами, які встановлюєте ви, тож питання «скільки коштував batch-пайплайн минулого місяця» має одну відповідь замість чотирьох вивантажень у чотирьох форматах. Це також та частина, яку BYOC робить справді складнішою за перепродаж, бо немає єдиного реєстру, з якого можна читати; цифри доводиться діставати й звіряти окремо по кожному провайдеру.
Кому підходить bring your own cloud
BYOC підходить командам, у яких вже є наявна інфраструктура і вже реальні обмеження: кілька сотень машин, накопичених за три роки, вимога щодо юрисдикції від закупівельної команди клієнта, мікс провайдерів, який просто так склався, а не був спроєктований. Він гірше підходить, якщо ви починаєте з нуля, хочете рівно один рахунок і вам байдуже, де що працює. Реселер чи один hyperscaler буде простішим, і вам варто обрати простіше. Нікому не потрібен multi-cloud control plane для одного акаунта й одинадцяти серверів.
При BYOC дві речі загострюються і заслуговують на свідомий дизайн, а не просто добрі наміри. Перша - ізоляція: облікові дані належать організації, членство відбувається за запрошенням, а ролі визначають, хто може витрачати гроші чи чіпати файрвол - бо blast radius тут це реальний продакшн-акаунт, а не пісочниця. Друга - журнал аудиту. Кожна дія, яку платформа виконує від вашого імені, має записуватись append-only, з actor'ом, ресурсом та correlation ID, у форматі, який можна експортувати. Ви делегуєте операції, тож запис цих операцій - це те, що у вас залишається замість того, щоб виконати їх самостійно.
Отже, питання, які варто поставити будь-кому, хто продає вам bring your own cloud. Чиє ім'я стоїть у контракті з провайдером? Що саме може зробити credential, який ви передали, і чи можна звузити його scope? Що станеться з інфраструктурою, що працює, якщо ви завтра перестанете їм платити? Чи можете ви експортувати журнал усього, що вони робили у ваших акаунтах, і перевірити його незалежно? Хороші відповіді на ці чотири питання - це те, що відрізняє аутсорсинг операцій від аутсорсингу інфраструктури. І лише одне з цього можна скасувати у вівторок.