Коли у 2019 році Кейлеб Ґрілло прийшов у Confluent як продакт-менеджер, Confluent Cloud уже мав помітну базу користувачів — але комерційно це був радше «хостинг брокерів Kafka», ніж сучасний хмарний сервіс. Сьогодні Ґрілло очолює продуктовий напрям Warpstream у Confluent, але саме його рання робота над білінгом стала одним із ключових кроків у перетворенні Confluent Cloud на повноцінну платформу зі споживчою (usage-based) моделлю оплати.
Ця історія — не про тарифні плани як такі. Вона про те, як побудувати білінгову систему, здатну одночасно працювати з різними типами кластерів, кількома продуктами, складними enterprise-контрактами й неточними в часі метриками використання — і при цьому залишатися зрозумілою для клієнтів та керованою для бізнесу.
Дві хмари в одній: як виглядала комерційна «шизофренія» Confluent Cloud
На момент приходу Ґрілло в травні 2019 року Confluent Cloud фактично складався з двох різних світів.
Перший світ — це «серйозний» хмарний бізнес із виділеними кластерами. Це були не self‑serve інстанси, а радше керовані, але по суті індивідуальні розгортання Kafka для великих клієнтів. Інфраструктура була виділеною, угоди — індивідуальними, а білінг — далеким від класичної моделі AWS, де ви натискаєте кнопку, запускаєте EC2‑інстанс, оплачуєте його погодинно й зупиняєте, коли він більше не потрібен.
Другий світ — окремий self‑serve продукт на мультиорендних (multi‑tenant) кластерах. Тут уже була споживча модель: користувач міг самостійно зареєструватися, додати картку, почати використовувати сервіс і платити за фактичне використання. Це було ближче до очікувань від сучасної хмари, але масштаб цього продукту та його архітектура не відповідали потребам великих enterprise‑клієнтів, які звикли до виділених ресурсів, контрактів і знижок.
Обидва світи жили паралельно, з різними очікуваннями щодо білінгу, різними внутрішніми системами й різною логікою комерційних відносин. Технічні передумови для об’єднання вже існували: Confluent мав досвід керування кластерами, мультиорендною інфраструктурою та базовим usage‑білінгом. Але об’єднати ці моделі без єдиної комерційної логіки було неможливо.
Саме це й стало завданням Ґрілло: побудувати єдину, consumption‑based білінгову систему, яка б охоплювала обидва світи й дозволила Confluent Cloud стати тим, чим його уявляють сьогодні — повноцінним хмарним сервісом із гнучкою моделлю оплати.
Від «хостингу брокерів» до платформи: навіщо потрібен єдиний usage‑білінг
Початковий «хостинговий» підхід до Confluent Cloud був логічним для раннього етапу: потрібно було перевірити, чи готові компанії довірити Kafka зовнішньому провайдеру. Цей proof‑of‑concept спрацював настільки добре, що бізнес виріс швидше, ніж встигла еволюціонувати модель монетизації.
Наступний крок був очевидним: перейти від «ми просто запускаємо вам брокери» до «ми надаємо повноцінну стримінгову платформу як сервіс». Але для цього недостатньо було лише технічно розвинути продукт. Потрібно було, щоб комерційна модель відповідала очікуванням клієнтів і дозволяла масштабувати бізнес.
Єдина, споживча модель оплати мала вирішити кілька задач одночасно.
По‑перше, зробити можливим справжній self‑serve для широкого кола користувачів — від стартапів до великих компаній, які хочуть почати з невеликих обсягів і масштабуватися без перемовин на кожен крок.
По‑друге, дати змогу enterprise‑клієнтам працювати з виділеними кластерами, складними контрактами, мінімальними зобов’язаннями й індивідуальними знижками, але при цьому залишатися в тій самій логіці usage‑білінгу, що й self‑serve користувачі.
По‑третє, створити основу для подальшого розвитку платформи: додавання нових сервісів поверх Kafka, нових типів кластерів, нових метрик використання. Без гнучкого білінгу кожен новий продукт перетворювався б на окрему комерційну «острівну» систему.
Саме тому ключовим блокером розвитку Confluent Cloud став не лише технічний стек, а й комерційна модель. І розв’язання цієї проблеми починалося з побудови нового білінгового ядра.
Білінг як платформа: кластери, продукти, трафік і сховище в одній моделі
Нова білінгова система Confluent Cloud мала бути не просто «лічильником байтів». Вона мала стати платформою, яка вміє описувати різні типи інфраструктури, різні продукти й різні способи використання.
По‑перше, потрібно було підтримати кілька рівнів кластерів. У Confluent Cloud співіснували виділені кластери для великих клієнтів і мультиорендні кластери для self‑serve користувачів. Кожен тип мав свої характеристики продуктивності, надійності, ізоляції та, відповідно, свою цінову модель. Білінгова система мала вміти однаково коректно рахувати використання для обох типів, не перетворюючи їх на два різні світи.
По‑друге, йшлося не лише про Kafka як таку. Уже тоді Confluent Cloud включав додаткові сервіси: Kafka Connect для інтеграцій і ksql (сьогодні ksqlDB) для потокової обробки даних. Кожен із цих продуктів споживає ресурси по‑своєму: Connect — через конектори, які можуть активно читати й писати дані, ksql — через безперервні запити, що постійно обробляють потоки. Єдина білінгова модель мала вміти відобразити всі ці патерни використання, не розвалюючись на окремі «субсистеми» для кожного продукту.
По‑третє, потрібно було одночасно враховувати два ключові виміри використання: пропускну здатність (throughput) і сховище (storage). Стримінгова платформа — це не лише скільки даних проходить через кластери, а й скільки з них зберігається, як довго й у якому вигляді. Клієнти можуть мати різні патерни: хтось тримає коротку ретенцію, але з високим трафіком, хтось — навпаки, менший потік, але довге зберігання. Білінг мав коректно відображати обидва сценарії.
Усе це вимагало не просто додати нові поля в таблицю тарифів, а спроєктувати модель, яка дозволяє:
- описувати різні типи кластерів як різні «рівні» сервісу з власними характеристиками;
- прив’язувати до них кілька продуктів (Kafka, Connect, ksql) з різними патернами використання;
- рахувати використання за кількома осями (трафік, сховище) й робити це узгоджено для всіх клієнтів.
Це й стало суттю першої версії нового білінгу, яку Ґрілло мав вивести в продакшн: не просто «рахувати байти», а створити гнучку платформу, на якій можна будувати комерційну еволюцію Confluent Cloud.
Enterprise‑реальність: мінімальні зобов’язання, знижки й контракти
Usage‑білінг у стилі «ось прайс, ось ваші метрики, платіть по факту» добре працює для self‑serve сегмента, але погано відображає реальність великих enterprise‑угод. Для Confluent, який працює з великими компаніями, цього було явно недостатньо.
Нова білінгова система мала вміти моделювати не лише «прайсову» частину, а й контрактну. Це означало кілька важливих речей.
По‑перше, підтримку мінімальних зобов’язань (commitments). Enterprise‑клієнти часто підписують контракти, де зобов’язуються витратити певний мінімальний обсяг коштів або використання за період — наприклад, за рік. Це дає їм кращі умови, а провайдеру — прогнозованість доходів. Білінгова система має вміти відобразити, як фактичне використання співвідноситься з цими зобов’язаннями, чи виконується commit, чи є недовикористання.
По‑друге, моделювання знижок. У великих угодах ціна рідко дорівнює прайсовій. Вона залежить від обсягу, тривалості контракту, набору продуктів і навіть історії відносин із клієнтом. Білінг має вміти застосовувати індивідуальні знижки до різних компонентів використання — наприклад, окремо до трафіку, окремо до сховища, окремо до певних сервісів.
По‑третє, узгодженість між цими контрактними умовами й фактичними usage‑метриками. Якщо білінгова система не розуміє структуру контракту, вона не може коректно показати клієнту, як його реальне використання співвідноситься з тим, що було погоджено на папері.
Усе це означало, що Confluent мав побудувати не просто «рахівницю» для usage‑даних, а повноцінну модель комерційних відносин, де usage‑метрики, ціни, знижки й commitments зводяться в єдину картину. Саме така модель дозволяє одночасно підтримувати self‑serve користувачів із прозорим прайсингом і великі enterprise‑угоди з індивідуальними умовами — без розриву між технічною та фінансовою реальністю.
Коли метрики запізнюються: чому білінг має збиратися по‑частинах
Ще одна малопомітна, але критично важлива частина нової білінгової системи Confluent — це те, як вона працює з usage‑метриками в часі. У реальних розподілених системах дані про використання рідко приходять миттєво й ідеально синхронно. Метрики можуть запізнюватися, приходити пачками, частково дублюватися або потребувати агрегації.
Замість того, щоб робити білінг на основі «моментального знімка» використання, Confluent побудував модель, де usage‑дані агрегуються з часом, а суми до сплати поступово збігаються до коректного значення. Це означає кілька важливих речей для клієнтів і для самої платформи.
По‑перше, зменшення ризику різких «стрибків» у рахунках через запізнілі метрики. Якщо система розраховувала б усе в один момент, будь‑яка затримка в надходженні usage‑даних могла б призвести до несподіваних корекцій. Натомість модель з агрегацією дозволяє поступово уточнювати суми, роблячи процес більш плавним і передбачуваним.
По‑друге, кращу стійкість до технічних збоїв. У розподіленій інфраструктурі завжди є ризик, що частина usage‑даних тимчасово недоступна або приходить із затримкою. Агрегаційна модель дозволяє системі «дотягувати» ці дані пізніше й коректно враховувати їх у підсумкових розрахунках, замість того щоб покладатися на один‑єдиний знімок.
По‑третє, можливість глибшої аналітики. Коли usage‑дані зберігаються й агрегуються з часом, їх можна аналізувати не лише для білінгу, а й для розуміння патернів використання, оптимізації інфраструктури, прогнозування навантаження.
Цей підхід до usage‑метрик добре узгоджується з тим, як Ґрілло сьогодні працює над Warpstream: усі дані про споживання й використання цього продукту також потрапляють у внутрішнє data warehouse Confluent, де їх можна аналізувати з тих самих позицій — як для білінгу, так і для продуктового розвитку.
Від білінгу до аналітики: як Warpstream наслідує data‑driven підхід
Сьогодні Кейлеб Ґрілло очолює продуктовий напрям Warpstream у Confluent — це BYOC‑продукт (bring your own cloud), де дата‑плейн працює у VPC або дата‑центрі клієнта, а Confluent керує контрольним рівнем. Технічно Warpstream радикально відрізняється від класичного Kafka‑розгортання, але в одному підході є пряма спадковість від роботи Ґрілло над білінгом Confluent Cloud: у ставленні до usage‑даних.
Усі дані про споживання та використання Warpstream потрапляють у внутрішнє data warehouse Confluent. Це означає, що до Warpstream застосовується той самий принцип, який колись ліг в основу нового білінгу Confluent Cloud: usage‑метрики — це не лише основа для виставлення рахунків, а й ключовий інструмент для розуміння продукту.
Такий підхід дозволяє:
- аналізувати тренди доходів і витрат, щоб переконатися, що маржа продукту відповідає очікуванням;
- бачити, як клієнти реально використовують сервіс: які патерни трафіку, які обсяги зберігання, які конфігурації кластерів;
- приймати продуктові рішення на основі даних, а не інтуїції — від пріоритизації фіч до корекції цінових моделей.
Фактично, те, що починалося як «великий білінговий проєкт» у 2019 році, сьогодні перетворилося на ширший data‑driven підхід до управління стримінговими продуктами в Confluent. Білінгова система стала не лише механізмом монетизації, а й фундаментом для аналітики, планування й розвитку нових сервісів — включно з Warpstream.
Висновок: білінг як стратегічна інфраструктура, а не післямова
Історія еволюції білінгу Confluent Cloud показує, наскільки глибоко комерційна модель вплітається в технічну архітектуру хмарного сервісу. Неможливо побудувати справжню платформу зі self‑serve досвідом, enterprise‑контрактами й кількома продуктами поверх одного ядра, якщо білінгова система залишиться набором «латок» навколо окремих компонентів.
Єдина consumption‑based модель, яку допоміг створити Кейлеб Ґрілло, вирішила одразу кілька задач: об’єднала виділені й мультиорендні кластери в одну комерційну реальність, дозволила підтримувати кілька продуктів і вимірів використання, навчилася працювати з enterprise‑зобов’язаннями та знижками й запровадила підхід до usage‑метрик як до даних, що агрегуються й аналізуються з часом.
Сьогодні цей підхід продовжує жити в нових продуктах Confluent, зокрема у Warpstream, де всі дані споживання також потрапляють у внутрішнє сховище для аналізу. У світі, де стримінг стає базовою інфраструктурою для бізнесу, білінг перестає бути «фінансовим додатком» і стає такою ж критичною частиною платформи, як брокери, конектори чи стримінгові рушії.
Для компаній, які будують власні хмарні сервіси, урок тут доволі прямий: якщо білінгова система не масштабується разом із продуктом, вона рано чи пізно стане головним блокером розвитку. І виправити це заднім числом набагато складніше, ніж закласти правильну модель з самого початку.
Джерело
Being Wrong in the Right Direction with Caleb Grillo | Ep. 29 | Confluent Developer Podcast