Pain: you pay for the peak but live on average load
Imagine a department that runs its own server room. To launch a new service, you have to estimate the peak load, add headroom, order hardware, wait for delivery, rack it, and set up power and cooling. Weeks, sometimes months, pass between the decision and the first request.
Then the unpleasant part begins. The purchased capacity is enough for the peak — which means it sits idle almost all the time. If you estimated generously, the money is frozen in hardware that will be obsolete in three years. If you skimped, the service goes down on Black Friday, and a new server arrives in six weeks. An error in either direction is expensive, and it is slow to fix.
A separate pain is that the decision is made once and for a long time. You forecast load three years ahead without having data.
Solution: computing as a utility
Cloud computing is the delivery of computing resources (servers, storage, networks, databases, applications) as a service over the internet, paid for by actual consumption.
The key phrase here is not "over the internet". Hosting is over the internet too. The key is a set of properties that a rented server does not have:
- on-demand self-service — a resource is created in minutes, without negotiating with the provider;
- elasticity — the amount of resources follows the load, up and down;
- resource pooling — you share a huge pool of capacity with other customers, so you don't pay for idle time;
- measured service — consumption is metered and shown.
Analogy: electricity. Nobody buys a generator sized for an apartment's peak consumption. You switch on the kettle and pay for kilowatt-hours, and the power plant's capacity is not your concern. The cloud sells computing the same way.
Description
Рисунок из двух половин. Слева небольшой дом, во дворе которого стоит промышленный дизель-генератор в несколько раз больше самого дома, рядом бочки с топливом. В окне виден единственный включённый чайник. Хозяин стоит у машины с пустым кошельком. Это CapEx: мощность куплена под пик, почти всё время простаивает, а деньги уже потрачены. Справа тот же дом, двор пуст. От дома тонкий провод уходит к линии опор и большой электростанции на горизонте, к которой подключены и другие дома. На стене светится счётчик, хозяйка пьёт чай в кресле. Это модель на основе потребления: станция общая, платят по счётчику. Чего рисунок не показывает: на ровной круглосуточной нагрузке свой генератор может выйти дешевле сети, и счётчик крутится даже тогда, когда про включённый прибор забыли.
Две координатные плоскости рядом, горизонтальная ось — время (три года), вертикальная — деньги. Слева подпись CapEx: широкая ступенька уходит вверх в самом начале и держится на высоте плато; под плато волнистая линия реальной нагрузки, которая почти всё время идёт заметно ниже плато, а в двух местах коротким пиком пробивает его выше — эти два места отмечены восклицательными знаками. Пространство между плато и волнистой линией заштриховано и подписано «оплаченный простой». Справа подпись OpEx: та же волнистая линия нагрузки, и поверх неё сплошная линия расходов, которая повторяет её изгибы почти вплотную. Заштрихованной области справа нет. Файла у этого рисунка нет: нарисуйте график по описанию или перескажите его словами.
How you pay for it: the consumption-based model
Consumption-based model — you pay for the resources you used: hours a virtual machine ran, gigabytes in storage, number of requests, volume of outbound traffic. Don't use it — don't pay.
This is not the only pricing model in Azure, and the exam requires you to tell them apart:
| Model | How it is charged | When it pays off |
|---|---|---|
| Consumption / pay-as-you-go | by actual consumption, per second or per unit | unpredictable or variable load, experiments |
| Reserved | a commitment 1 or 3 years ahead, discount off the rate | baseline load that will definitely run all that time |
| Spot | spare capacity at a rock-bottom price | jobs you don't mind being interrupted |
| Fixed / per-user | a fixed amount per user or instance | typical of SaaS: a license per person |
Description
Три ромба-вопроса сверху вниз. Первый: «Можно ли дать обязательство на 1–3 года вперёд?» Ответ «да: нагрузка ровная и точно будет» ведёт к Reserved — скидка за обязательство. Ответ «нет» ведёт ко второму вопросу: «Страшно ли, если работу прервут в любой момент?» Ответ «не страшно: можно запустить заново» ведёт к Spot — свободные мощности дёшево, но их могут забрать. Ответ «страшно» ведёт к третьему вопросу: «Счёт зависит от потребления или от числа пользователей?» От потребления — Pay-as-you-go, платите по факту без обязательств; от пользователей — Fixed / per-user, типично для SaaS. Порядок вопросов не случаен: сначала проверяется самое выгодное при выполнении условия, и каждое «нет» стоит денег. Подробно инструменты экономии разобраны в юните 14.
CapEx and OpEx
CapEx (capital expenditure) is a large one-off purchase of an asset: servers, licenses, a datacenter building. The money goes out at once, is written off gradually through depreciation, and the asset sits on the balance sheet.
OpEx (operational expenditure) is regular spending on ongoing operations: the cloud bill, electricity, subscriptions. It is expensed in the same period and creates no asset.
Moving to the cloud shifts spending from CapEx to OpEx. What this changes in substance: you don't need to defend a large budget in advance, an experiment costs as much as it lasts, and a failed project is closed together with its bill.
Cost
The bill becomes variable — and grows unnoticed. In the CapEx world a forgotten test VM just sits in a rack; in the cloud it sends a bill every month. Cost discipline turns from a one-off procurement task into ongoing work (see u13 and u14).
On long, steady load the cloud is more expensive than your own hardware. A 24/7 service with a flat profile and no spikes is the case where your own server, costed over three years, usually wins on money. The cloud sells not cheapness but the absence of commitment.
You lose some control. Platform versions, maintenance windows, available regions and service retirement dates are set by the provider. Azure Blueprints, for example, is being retired on 31 January 2027 — and that is not your decision.
Vendor lock-in appears. The more deeply you use provider-specific services, the more expensive it is to move.
Three deployment models
Public cloud. The infrastructure belongs to the provider, resources are shared among customers, entry is by credit card. Maximum elasticity, minimum control over the physical layer. Suits: a startup without its own datacenter, seasonal load, test environments, a public web service.
Private cloud. The same cloud properties — self-service, elasticity, measured consumption — but the pool of capacity is yours and is used by a single organization. It can sit in your datacenter or at a provider. Suits: strict regulation, a requirement to keep data inside the perimeter, legacy systems that cannot be moved.
An important distinction: a private cloud is not a synonym for a server room. A server room becomes a private cloud only when self-service and measured consumption appear on top of it. Otherwise it is just virtualization.
Hybrid cloud. Public and private work together as one environment, with data and workloads moving between them. Suits: the database stays on premises as the regulator requires, while computations move to Azure for the duration of the peak; or a gradual migration stretched over years; or a standby site for disaster recovery.
Hybrid is a stable architecture, not a transfer station. Many organizations live in it for years for perfectly rational reasons.
Description
Два ромба-вопроса. Первый: «Есть данные или системы, которые обязаны остаться на своей площадке?» Ответ «нет» ведёт к публичному облаку — максимум эластичности, минимум капитальных затрат. Ответ «да: регулятор, унаследованные системы» ведёт ко второму вопросу: «Нужна ли при этом эластичность или мощность сверх своей площадки?» Ответ «нет» — частное облако: пул ваш, но с самообслуживанием и измеряемым потреблением. Ответ «да» — гибридное облако: данные на площадке, пики и расчёты в Azure. К первому вопросу пунктиром привязана заметка со словами-сигналами: «обязаны», «регулятор», «в нашем ЦОДе» ведут по ветке «да», «минимизировать капитальные затраты» — по ветке «нет». Слова «безопаснее» среди сигналов нет намеренно: на нём выбор не строится.
Watch out: a trap
- "Cheaper" in a question is almost never about the deployment model. If the scenario says "minimize capital expenditure", that is public cloud. If it says "data must stay in our datacenter, but elasticity is needed for computations", that is hybrid, and the word "must" decides it.
- A private cloud is not "more secure by definition". It gives control over placement, and security depends on how it is configured. An exam question about private cloud usually rests on a regulatory requirement or on legacy hardware, not on the word "security".
- Don't confuse elasticity with scalability. Scalability is the ability to grow. Elasticity is the ability to grow and come back down, automatically. It is the coming back down that saves money. More in u03.
- CapEx versus OpEx is a question about accounting, not about the amount. The phrase "avoid large upfront investment" points to OpEx, even if over three years the cloud comes out more expensive.