What Is Cloud Computing?

A plain definition

Cloud computing means using computing resources (servers, storage, databases, networks, software) that a provider runs in its data centers, over a network, when you need them, and paying for what you use. You do not buy the hardware, install it or replace it; you request capacity, use it, and give it back.

The reference definition comes from the US National Institute of Standards and Technology (NIST), in Special Publication (SP) 800-145 from 2011. It is short and still used by the certification exams:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

The same document defines three service models (infrastructure, platform and software as a service; see Service Models) and four deployment models (public, private, community and hybrid; see Deployment Models). The key word in the definition is model: the cloud is a way of delivering and consuming IT, not a particular technology or place.

The five essential characteristics

NIST lists five characteristics that a service must have to count as cloud computing. They are the most useful test when someone calls a product "cloud": a hosting company that needs a support ticket and three days to set up a server is not delivering cloud computing, even if its website says so.

On-demand self-service

On-demand self-service means you can provision resources yourself, whenever you want, without a person at the provider having to act. You click in a web console, run a command or call an application programming interface (API), and a few minutes later the virtual server exists. Compare it with a vending machine rather than a shop counter.

Broad network access

Resources are reachable over the network through standard mechanisms (web pages and APIs over HTTPS, Secure Shell (SSH), remote desktop) from many kinds of clients: laptops, phones, other servers. You manage a cloud server in Frankfurt from a browser in Rotterdam the same way you would from inside the data center.

Resource pooling

The provider's hardware is shared by many customers (a multi-tenant model). Your virtual server runs on a physical machine that also runs other customers' servers, isolated from each other by virtualization. You usually do not know which physical machine you are on, but you can choose the general location, such as a country or region. Pooling is what makes the economics work: a provider buys hardware for millions of customers whose peaks do not all happen at the same time.

Rapid elasticity

Rapid elasticity means capacity can grow and shrink quickly, often automatically, to match demand. A web shop can run four servers on a quiet Tuesday and forty during a sale, and return to four the day after. To the customer, the capacity appears unlimited, although in reality every provider has quotas and occasionally runs short of a particular server type in a particular location.

Measured service

Measured service means the provider meters usage (compute hours or seconds, gigabytes stored, requests handled, data transferred) and you can see that usage. Metering is the basis for pay-as-you-go billing, but it also serves monitoring and capacity planning. Think of a utility meter for electricity or water.

What is behind it

Behind every cloud service are ordinary computers: very large numbers of servers, storage systems and network switches in data centers, with redundant power, cooling and network connections. Three things turn those buildings into a cloud:

• Virtualization splits each physical server into many isolated virtual machines, so one machine can serve many customers safely. See Virtualization and Hypervisors.
• Automation and APIs. Every action a customer takes, from creating a server to deleting a database, is a call to an API that software carries out without human involvement. That is what makes self-service and elasticity possible.
• Scale. Providers buy hardware, power and network capacity in enormous volumes and spread the cost over many customers. Those economies of scale are a large part of why renting can be cheaper than owning.

The big providers

A hyperscaler is a cloud provider that operates at global scale, with many data center regions on several continents and hundreds of services. At the time of writing, three providers together hold most of the public cloud market:

Others include Oracle Cloud Infrastructure, IBM Cloud and Alibaba Cloud, and regional providers such as OVHcloud, Hetzner and Scaleway in Europe. The concepts on these pages apply to all of them; the service names differ, which is why the pages show a small mapping table where it helps.

Benefits

• Speed and agility. A new server takes minutes instead of weeks of ordering, delivery and installation. Teams can try an idea, measure it and throw it away cheaply.
• Scale when you need it. Capacity follows demand, so you no longer have to buy for the busiest day of the year and leave most of it idle the rest of the time.
• Global reach. You can run a copy of an application close to users on another continent without building anything there.
• No hardware to buy or maintain. Replacing failed disks, planning power and cooling, and refreshing servers every few years become the provider's job.
• Managed services. Databases, backups, load balancing and monitoring can be rented as ready-made services instead of built and operated in-house.
• Resilience options. Spreading a system over several data centers is a configuration choice rather than a construction project. See High Availability, Scaling and Disaster Recovery.

CapEx versus OpEx

Finance departments split spending into two kinds, and the cloud moves IT from the first to the second.

• Capital expenditure (CapEx) is money spent up front on assets that last for years, such as servers, storage arrays and data center buildings. The cost is paid at once and written off (depreciated) over the asset's life. You pay for the capacity whether you use it or not.
• Operational expenditure (OpEx) is ongoing spending on running the business, such as electricity, salaries, subscriptions and rent. Cloud usage is OpEx: you pay each month for what you used that month.

OpEx is not automatically cheaper. It is flexible: no large purchase before you know whether a project will succeed, and costs that fall when usage falls. The example below compares buying a server with renting comparable capacity for three years. All numbers are fictitious round figures in an unnamed currency, chosen to show the shape of the comparison, not real prices.

# Fictitious round numbers for illustration only, not real prices.
MONTHS = 36
HOURS_PER_MONTH = 730           # average hours in a month

SERVER_PRICE = 9_000            # bought once, paid up front (CapEx)
SERVER_MONTHLY = 150            # power, cooling, rack space, support (OpEx)
CLOUD_PER_HOUR = 0.60           # renting comparable capacity (OpEx)


def buy(months):
    return SERVER_PRICE + SERVER_MONTHLY * months


def rent(months, hours_per_month):
    return CLOUD_PER_HOUR * hours_per_month * months


print(f"{'After':<8}{'Buy':>9}{'Rent 24/7':>12}{'Rent office hours':>20}")
for month in (1, 12, 24, 36):
    print(
        f"{month:>2} mo   {buy(month):>9,.0f}"
        f"{rent(month, HOURS_PER_MONTH):>12,.0f}"
        f"{rent(month, 220):>20,.0f}"
    )

for month in range(1, MONTHS + 1):
    if rent(month, HOURS_PER_MONTH) > buy(month):
        print(f"Renting 24/7 costs more than buying from month {month}.")
        break

After         Buy   Rent 24/7   Rent office hours
 1 mo       9,150         438                 132
12 mo      10,800       5,256               1,584
24 mo      12,600      10,512               3,168
36 mo      14,400      15,768               4,752
Renting 24/7 costs more than buying from month 32.

Two lessons hide in these numbers. A workload that runs day and night for years can be cheaper on owned hardware, although this comparison leaves out staff time, spare parts, the hardware refresh after the third year and the discounts providers give for committed use. A workload that only runs during office hours (220 hours a month here) costs a fraction in the cloud, because switched-off capacity costs nothing. Pricing models and discounts are covered in Cloud Costs and FinOps.

Drawbacks and risks

The cloud solves some problems and introduces others. Knowing them is part of using it well.

• Cost surprises. Pay-as-you-go also means pay-as-you-forget: a test server left running, a misconfigured autoscaling rule or large amounts of data leaving the provider (egress) can produce a bill far higher than expected. Budgets and alerts are essential from day one; see Cloud Costs and FinOps.
• Lock-in. The more you use a provider's own managed services, the harder and more expensive it becomes to move. See Deployment Models.
• Dependence on the provider and the network. When a provider has a regional outage, or your internet connection fails, your systems or your access to them fail too. Providers publish availability commitments, but no provider is never down.
• Skills. Cloud platforms have hundreds of services and their own ways of handling networking, identity and cost. Misconfiguration, not hacking of the provider, is behind most cloud security incidents. See Identity and Access Management and Cloud Security and Compliance.
• Data location and law. Where data is stored, and which country's law can reach it, matters for privacy regulations such as the European General Data Protection Regulation (GDPR). See Regions and Availability Zones.
• Less control. You cannot choose the hardware, the maintenance windows or the exact moment a service changes.

When to stay on-premises, or come back

On-premises means running your own hardware in your own building or a rented data center rack. It remains a sound choice in several situations:

• Steady, predictable workloads that run at high utilization for years, where owned hardware can cost less (as the example above suggests).
• Very large volumes of data that are read or moved often, where transfer fees and bandwidth make the cloud expensive.
• Strict latency needs close to machines, such as factory control systems, or sites with unreliable internet connections.
• Legal or contractual requirements about where data is stored and who may access it that a provider cannot meet.
• Existing, recently bought hardware and a team that runs it well.

Moving workloads from the cloud back to owned hardware is called cloud repatriation. Some companies have publicly described doing so for steady workloads, the software maker 37signals being a well-known example in 2022 and 2023. How common repatriation really is remains debated; most organizations end up with a mix, placing each workload where it fits best (a hybrid approach, see Deployment Models).

"The cloud is just someone else's computer"

The popular sticker is half right. Physically, your workload does run on someone else's computer, in someone else's building, and that has consequences: you depend on them, you trust them with your data, and you follow their rules. Remembering that keeps expectations realistic.

What the slogan leaves out is the model around the computer: self-service in minutes, capacity that grows and shrinks on request, pay-per-use metering, and managed services that someone else patches and operates. Renting a single server from a hosting company is someone else's computer; getting forty servers for one afternoon through an API, and paying only for that afternoon, is cloud computing.