Боль: вы платите за пик, а живёте на средней нагрузке
Представьте отдел, который держит собственную серверную. Чтобы запустить новый сервис, нужно посчитать пиковую нагрузку, добавить запас, заказать железо, дождаться поставки, поставить в стойку, настроить питание и охлаждение. От решения до первого запроса проходят недели, иногда месяцы.
Дальше начинается неприятное. Купленной мощности хватает на пик — то есть почти всё время она простаивает. Если оценили щедро, деньги заморожены в железе, которое устареет за три года. Если поскупились, в чёрную пятницу сервис ляжет, а новый сервер приедет через шесть недель. Ошибка в обе стороны стоит дорого, и исправляется она медленно.
Отдельно больно то, что решение принимается один раз и надолго. Вы прогнозируете нагрузку на три года вперёд, не имея данных.
Решение: вычисления как коммунальная услуга
Облачные вычисления (cloud computing) — предоставление вычислительных ресурсов (серверов, хранилища, сетей, баз данных, приложений) как услуги через интернет, с оплатой за фактическое потребление.
Ключевое слово здесь не «через интернет». Хостинг тоже через интернет. Ключевое — набор свойств, которых у арендованного сервера нет:
- самообслуживание по требованию — ресурс создаётся за минуты, без переговоров с поставщиком;
- эластичность — количество ресурсов меняется вслед за нагрузкой, вверх и вниз;
- объединение ресурсов — вы делите огромный пул мощностей с другими клиентами, поэтому не платите за простой;
- измеряемость — потребление считается и показывается.
Аналогия: электричество. Никто не покупает генератор под пиковое потребление квартиры. Вы включаете чайник и платите за киловатт-часы, а мощность электростанции — не ваша забота. Облако продаёт вычисления так же.
Description
Рисунок из двух половин. Слева небольшой дом, во дворе которого стоит промышленный дизель-генератор в несколько раз больше самого дома, рядом бочки с топливом. В окне виден единственный включённый чайник. Хозяин стоит у машины с пустым кошельком. Это CapEx: мощность куплена под пик, почти всё время простаивает, а деньги уже потрачены. Справа тот же дом, двор пуст. От дома тонкий провод уходит к линии опор и большой электростанции на горизонте, к которой подключены и другие дома. На стене светится счётчик, хозяйка пьёт чай в кресле. Это модель на основе потребления: станция общая, платят по счётчику. Чего рисунок не показывает: на ровной круглосуточной нагрузке свой генератор может выйти дешевле сети, и счётчик крутится даже тогда, когда про включённый прибор забыли.
Две координатные плоскости рядом, горизонтальная ось — время (три года), вертикальная — деньги. Слева подпись CapEx: широкая ступенька уходит вверх в самом начале и держится на высоте плато; под плато волнистая линия реальной нагрузки, которая почти всё время идёт заметно ниже плато, а в двух местах коротким пиком пробивает его выше — эти два места отмечены восклицательными знаками. Пространство между плато и волнистой линией заштриховано и подписано «оплаченный простой». Справа подпись OpEx: та же волнистая линия нагрузки, и поверх неё сплошная линия расходов, которая повторяет её изгибы почти вплотную. Заштрихованной области справа нет. Файла у этого рисунка нет: нарисуйте график по описанию или перескажите его словами.
Как за это платят: модель на основе потребления
Consumption-based model (модель на основе потребления) — вы платите за использованные ресурсы: часы работы виртуальной машины, гигабайты в хранилище, число запросов, объём исходящего трафика. Не используете — не платите.
Это не единственная модель ценообразования в Azure, и экзамен требует их различать:
| Модель | Как считается | Когда выгодна |
|---|---|---|
| Consumption / pay-as-you-go | по факту потребления, посекундно или по единицам | непредсказуемая или переменная нагрузка, эксперименты |
| Reserved (резервирование) | обязательство на 1 или 3 года вперёд, скидка к тарифу | базовая нагрузка, которая точно будет работать всё это время |
| Spot | свободные мощности по бросовой цене | задачи, которые не жалко прервать |
| Fixed / per-user | фиксированная сумма за пользователя или экземпляр | типично для SaaS: лицензия на человека |
Description
Три ромба-вопроса сверху вниз. Первый: «Можно ли дать обязательство на 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 на время пика; или постепенная миграция, растянутая на годы; или запасная площадка для аварийного восстановления.
Гибрид — устойчивая архитектура, а не пересадочная станция. Многие организации живут в нём годами по совершенно рациональным причинам.
Description
Два ромба-вопроса. Первый: «Есть данные или системы, которые обязаны остаться на своей площадке?» Ответ «нет» ведёт к публичному облаку — максимум эластичности, минимум капитальных затрат. Ответ «да: регулятор, унаследованные системы» ведёт ко второму вопросу: «Нужна ли при этом эластичность или мощность сверх своей площадки?» Ответ «нет» — частное облако: пул ваш, но с самообслуживанием и измеряемым потреблением. Ответ «да» — гибридное облако: данные на площадке, пики и расчёты в Azure. К первому вопросу пунктиром привязана заметка со словами-сигналами: «обязаны», «регулятор», «в нашем ЦОДе» ведут по ветке «да», «минимизировать капитальные затраты» — по ветке «нет». Слова «безопаснее» среди сигналов нет намеренно: на нём выбор не строится.
Внимание, ловушка
- «Дешевле» в вопросе почти никогда не про модель развёртывания. Если в сценарии сказано «минимизировать капитальные затраты» — это публичное облако. Если сказано «данные обязаны оставаться в нашем ЦОДе, но нужна эластичность для расчётов» — это гибрид, и слово «обязаны» решает.
- Частное облако не «безопаснее по определению». Оно даёт контроль над размещением, а безопасность зависит от того, как настроено. Формулировка экзамена про частное облако обычно опирается на требование регулятора или на унаследованное оборудование, а не на слово «безопасность».
- Не путайте эластичность с масштабируемостью. Масштабируемость — способность вырасти. Эластичность — способность вырасти и вернуться обратно, автоматически. Именно возврат экономит деньги. Подробно в u03.
- CapEx против OpEx — вопрос про бухгалтерию, а не про сумму. Формулировка «избежать крупных первоначальных вложений» указывает на OpEx, даже если по трёхлетней сумме облако выйдет дороже.