Cloud Economics and Serverless

Paying for what you use

Cloud economics rests on one sentence. Cloud computing uses a consumption-based model in which customers pay for the IT resources they use. Instead of buying and maintaining datacenter infrastructure, a customer can rent compute power and storage, then release those resources when they are no longer needed.

Compare the two ways of obtaining the same capacity:

This approach avoids paying for idle capacity in the same way as a fixed hardware purchase.

Two abilities follow directly from that, and they are the ones scenarios are built on. A consumption-based model can avoid upfront hardware and datacenter costs. It also lets a customer add resources when demand rises and release resources when demand falls.

The financial effect follows actual resource use rather than a permanently installed capacity level. That is the difference worth carrying into the exam: spending tracks a curve of real usage, not a flat line drawn by a purchase order signed a year earlier.

A seasonal business shows it most clearly. Capacity goes up for the peak, comes down afterwards, and the bill follows the same shape.

Capital and operational expenditure

Traditional IT budgeting splits spending into two categories, and the cloud lands squarely in one of them.

Capital expenditure is upfront spending on physical infrastructure such as servers, network hardware, and datacenter space. Operational expenditure is ongoing spending on services over time.

Because cloud services are paid for as they are consumed, cloud computing is classified as an operational expense.

The test is when and for what, not who sends the invoice. An upfront purchase of physical infrastructure is capital expenditure even if it is financed over several years. A charge that accrues while a service is being used is operational expenditure even if it turns out to be large.

This is also why the classification does not change with size. A single virtual machine billed by the hour and an estate of thousands are both operational spending, because both follow consumption. And buying one server for a rack is capital spending, because the money went into physical infrastructure before anything ran on it.

The capacity-planning problem it solves

Traditional capacity planning requires an estimate of future resource needs, and an estimate can miss in either direction. Both misses cost money, but they cost it differently.

Overestimating creates spending on infrastructure that sits idle, while underestimating can cause degraded application performance.

The asymmetry is in the repair. Correcting an underestimate requires ordering, installing, and provisioning more hardware, power, and cooling — a sequence measured in weeks while the application keeps running slowly.

Cloud capacity removes the guess rather than improving it. Resources are added when demand rises and released when demand falls, so the estimate never has to be right in advance.

This is why "we sized it wrong" means something entirely different on each side. In a traditional datacenter it is a procurement project; in a consumption-based model it is an adjustment.

Pay-as-you-go pricing

Cloud providers use a pay-as-you-go pricing model. It is the commercial expression of everything above: you are billed for the services you consume rather than for a capacity level you declared in advance.

Paying for consumed services helps customers do three things:

• Manage operating costs, because spending follows the workload instead of a fixed asset.
• Use infrastructure more efficiently, because unused capacity can be released rather than absorbed.
• Scale when workload needs change, in either direction.

There is a matching obligation on the other side of the deal. The provider maintains the underlying power, cooling, hardware, and networking.

That is what the customer is really buying out of: not just the servers, but the facility around them and the work of keeping it running. A team that moves to pay-as-you-go stops budgeting for cooling capacity and starts budgeting for consumption.

Note the limit, because scenarios exploit it. Pay-as-you-go makes costs manageable and proportional; it does not make them disappear or remove the need to plan them.

Serverless execution with Azure Functions

Consumption-based thinking reaches its limit in compute. A virtual machine or a container has to be running for the application to work, so something is provisioned even at three in the morning when nothing is happening.

Azure Functions is an event-driven, serverless compute option that does not require maintaining virtual machines or containers. An event wakes a function, so resources do not need to remain provisioned while no events occur.

What counts as an event is specific. Common triggers include a REST request, a timer, or a message from another Azure service.

Azure Functions also scales automatically according to demand, which makes it a reasonable fit when that demand is variable rather than steady.

The billing follows the same shape as the execution. Azure Functions runs code when triggered and deallocates resources when the function finishes. In this model, the customer is charged for the CPU time used while the function runs — not for the hours in between.

One behavioral detail completes the picture. Stateless behavior is the default: a function acts as though it restarts on every event. When state is needed, Durable Functions passes context through the function to track prior activity.

When serverless is the right shape

Serverless is appropriate when the team wants to focus on code rather than the underlying platform or infrastructure, and the work responds to events.

Read that as two conditions that must both hold, not one:

The contrast is what makes it examinable. Serverless differs from a virtual machine or container design that must keep resources running for the application to function. If the answer to "what happens between events?" is "resources must stay up", the workload is not the serverless shape being described here.

The direction of the clue matters too. Triggers, variable demand, and short bursts of work all point towards Functions. A requirement to hold resources continuously, or to maintain and restart a container before each execution, points away from it.

Key takeaways

• Consumption-based cloud spending follows the resources used, so capacity can be rented and released instead of purchased and left idle.
• Capital expenditure is upfront infrastructure spending; operational expenditure is ongoing service spending — and cloud services paid for as they are consumed are an operating expense.
• Cloud capacity can be added as demand rises and released as demand falls, which removes the traditional planning risk: overestimating pays for idle infrastructure, and underestimating degrades performance until more hardware, power, and cooling are ordered, installed, and provisioned.
• Azure Functions runs code in response to events and deallocates resources when execution finishes, charging for the CPU time used, scaling automatically, and defaulting to stateless behavior unless Durable Functions carries context forward.