Біль: ви платите за пік, а живете на середньому навантаженні
Уявіть відділ, який тримає власну серверну. Щоб запустити новий сервіс, треба порахувати пікове навантаження, додати запас, замовити залізо, дочекатися постачання, поставити в стійку, налаштувати живлення та охолодження. Від рішення до першого запиту минають тижні, іноді місяці.
Далі починається неприємне. Купленої потужності вистачає на пік — тобто майже весь час вона простоює. Якщо оцінили щедро, гроші заморожені в залізі, яке застаріє за три роки. Якщо поскупилися, у чорну п'ятницю сервіс ляже, а новий сервер приїде за шість тижнів. Помилка в будь-який бік коштує дорого, і виправляється вона повільно.
Окремо болить те, що рішення ухвалюється один раз і надовго. Ви прогнозуєте навантаження на три роки вперед, не маючи даних.
Рішення: обчислення як комунальна послуга
Хмарні обчислення (cloud computing) — надання обчислювальних ресурсів (серверів, сховища, мереж, баз даних, застосунків) як послуги через інтернет з оплатою за фактичне споживання.
Ключове слово тут не «через інтернет». Хостинг теж через інтернет. Ключове — набір властивостей, яких в орендованого сервера немає:
- самообслуговування на вимогу — ресурс створюється за хвилини, без перемовин із постачальником;
- еластичність — кількість ресурсів змінюється слідом за навантаженням, угору й униз;
- об'єднання ресурсів — ви ділите величезний пул потужностей з іншими клієнтами, тому не платите за простій;
- вимірюваність — споживання рахується й показується.
Аналогія: електрика. Ніхто не купує генератор під пікове споживання квартири. Ви вмикаєте чайник і платите за кіловат-години, а потужність електростанції — не ваш клопіт. Хмара продає обчислення так само.
Опис
Рисунок из двух половин. Слева небольшой дом, во дворе которого стоит промышленный дизель-генератор в несколько раз больше самого дома, рядом бочки с топливом. В окне виден единственный включённый чайник. Хозяин стоит у машины с пустым кошельком. Это CapEx: мощность куплена под пик, почти всё время простаивает, а деньги уже потрачены. Справа тот же дом, двор пуст. От дома тонкий провод уходит к линии опор и большой электростанции на горизонте, к которой подключены и другие дома. На стене светится счётчик, хозяйка пьёт чай в кресле. Это модель на основе потребления: станция общая, платят по счётчику. Чего рисунок не показывает: на ровной круглосуточной нагрузке свой генератор может выйти дешевле сети, и счётчик крутится даже тогда, когда про включённый прибор забыли.
Две координатные плоскости рядом, горизонтальная ось — время (три года), вертикальная — деньги. Слева подпись CapEx: широкая ступенька уходит вверх в самом начале и держится на высоте плато; под плато волнистая линия реальной нагрузки, которая почти всё время идёт заметно ниже плато, а в двух местах коротким пиком пробивает его выше — эти два места отмечены восклицательными знаками. Пространство между плато и волнистой линией заштриховано и подписано «оплаченный простой». Справа подпись OpEx: та же волнистая линия нагрузки, и поверх неё сплошная линия расходов, которая повторяет её изгибы почти вплотную. Заштрихованной области справа нет. Файла у этого рисунка нет: нарисуйте график по описанию или перескажите его словами.
Як за це платять: модель на основі споживання
Consumption-based model (модель на основі споживання) — ви платите за використані ресурси: години роботи віртуальної машини, гігабайти в сховищі, кількість запитів, обсяг вихідного трафіку. Не використовуєте — не платите.
Це не єдина модель ціноутворення в Azure, і іспит вимагає їх розрізняти:
| Модель | Як рахується | Коли вигідна |
|---|---|---|
| Consumption / pay-as-you-go | за фактом споживання, посекундно або за одиницями | непередбачуване або змінне навантаження, експерименти |
| Reserved (резервування) | зобов'язання на 1 або 3 роки вперед, знижка до тарифу | базове навантаження, яке точно працюватиме весь цей час |
| Spot | вільні потужності за безцінь | завдання, які не шкода перервати |
| Fixed / per-user | фіксована сума за користувача або екземпляр | типово для SaaS: ліцензія на людину |
Опис
Три ромба-вопроса сверху вниз. Первый: «Можно ли дать обязательство на 1–3 года вперёд?» Ответ «да: нагрузка ровная и точно будет» ведёт к Reserved — скидка за обязательство. Ответ «нет» ведёт ко второму вопросу: «Страшно ли, если работу прервут в любой момент?» Ответ «не страшно: можно запустить заново» ведёт к Spot — свободные мощности дёшево, но их могут забрать. Ответ «страшно» ведёт к третьему вопросу: «Счёт зависит от потребления или от числа пользователей?» От потребления — Pay-as-you-go, платите по факту без обязательств; от пользователей — Fixed / per-user, типично для SaaS. Порядок вопросов не случаен: сначала проверяется самое выгодное при выполнении условия, и каждое «нет» стоит денег. Подробно инструменты экономии разобраны в юните 14.
CapEx і OpEx
CapEx (capital expenditure, капітальні витрати) — велика разова купівля активу: сервери, ліцензії, будівля ЦОДу. Гроші йдуть одразу, списуються поступово через амортизацію, актив стоїть на балансі.
OpEx (operational expenditure, операційні витрати) — регулярні витрати на поточну діяльність: рахунок за хмару, електрику, підписки. Списуються в тому самому періоді, активу не створюють.
Перехід у хмару зсуває витрати з CapEx в OpEx. Що це змінює по суті: не треба захищати великий бюджет заздалегідь, експеримент коштує стільки, скільки триває, а невдалий проєкт закривається разом із рахунком.
Ціна
Рахунок стає змінним — і росте непомітно. Забута тестова ВМ у світі CapEx просто стоїть у стійці; у хмарі вона щомісяця виставляє рахунок. Дисципліна витрат із разового завдання закупівлі перетворюється на постійну роботу (про це u13 і u14).
На довгому стабільному навантаженні хмара дорожча за власне залізо. Цілодобовий сервіс із рівним профілем і без сплесків — той випадок, де порахований на три роки власний сервер зазвичай виграє за грошима. Хмара продає не дешевизну, а відсутність зобов'язання.
Ви втрачаєте частину контролю. Версії платформи, вікна обслуговування, доступні регіони й терміни виведення служб визначає постачальник. Azure Blueprints, наприклад, іде у відставку 31 січня 2027 — і це не ваше рішення.
З'являється прив'язка до постачальника. Що глибше використовуються специфічні служби, то дорожчий переїзд.
Три моделі розгортання
Публічна хмара (public cloud). Інфраструктура належить постачальнику, ресурси діляться між клієнтами, вхід — за кредитною карткою. Максимум еластичності, мінімум контролю над фізичним шаром. Підходить: стартап без власного ЦОДу, сезонне навантаження, тестові середовища, публічний вебсервіс.
Приватна хмара (private cloud). Ті самі хмарні властивості — самообслуговування, еластичність, вимірюваність — але пул потужностей ваш і використовується однією організацією. Може стояти у вашому ЦОДі або в провайдера. Підходить: жорстке регулювання, вимога зберігати дані всередині периметра, успадковані системи, які не переносяться.
Важлива відмінність: приватна хмара — не синонім серверної. Серверна стає приватною хмарою, лише коли поверх неї з'являються самообслуговування й вимірюване споживання. Інакше це просто віртуалізація.
Гібридна хмара (hybrid cloud). Публічна й приватна працюють разом як одне середовище, між ними ходять дані й навантаження. Підходить: база даних лишається на майданчику на вимогу регулятора, а розрахунки виносяться в Azure на час піку; або поступова міграція, розтягнута на роки; або запасний майданчик для аварійного відновлення.
Гібрид — стійка архітектура, а не пересадкова станція. Багато організацій живуть у ньому роками з цілком раціональних причин.
Опис
Два ромба-вопроса. Первый: «Есть данные или системы, которые обязаны остаться на своей площадке?» Ответ «нет» ведёт к публичному облаку — максимум эластичности, минимум капитальных затрат. Ответ «да: регулятор, унаследованные системы» ведёт ко второму вопросу: «Нужна ли при этом эластичность или мощность сверх своей площадки?» Ответ «нет» — частное облако: пул ваш, но с самообслуживанием и измеряемым потреблением. Ответ «да» — гибридное облако: данные на площадке, пики и расчёты в Azure. К первому вопросу пунктиром привязана заметка со словами-сигналами: «обязаны», «регулятор», «в нашем ЦОДе» ведут по ветке «да», «минимизировать капитальные затраты» — по ветке «нет». Слова «безопаснее» среди сигналов нет намеренно: на нём выбор не строится.
Увага, пастка
- «Дешевше» в питанні майже ніколи не про модель розгортання. Якщо в сценарії сказано «мінімізувати капітальні витрати» — це публічна хмара. Якщо сказано «дані зобов'язані залишатися в нашому ЦОДі, але потрібна еластичність для розрахунків» — це гібрид, і слово «зобов'язані» вирішує.
- Приватна хмара не «безпечніша за визначенням». Вона дає контроль над розміщенням, а безпека залежить від того, як налаштовано. Формулювання іспиту про приватну хмару зазвичай спирається на вимогу регулятора або на успадковане обладнання, а не на слово «безпека».
- Не плутайте еластичність із масштабованістю. Масштабованість — здатність вирости. Еластичність — здатність вирости й повернутися назад, автоматично. Саме повернення економить гроші. Детально в u03.
- CapEx проти OpEx — питання про бухгалтерію, а не про суму. Формулювання «уникнути великих початкових вкладень» вказує на OpEx, навіть якщо за трирічною сумою хмара вийде дорожчою.