What cloud computing is

For most of its life, Ridgeline Coffee Roasters has run on a handful of machines in the back office: Anita's desktop, Theo's shipping PC, the network storage box that holds the nightly backups, and the point-of-sale tablets in the cafe. Its online shop already lives somewhere else, on a hosted e-commerce platform that Ridgeline rents by the month. Nobody at Ridgeline has ever seen the computers that run the shop, and nobody needs to. When the shop is busy in the weeks before the holidays, it keeps working; when it is quiet in January, Ridgeline pays the same modest fee. That arrangement is a small example of cloud computing, and it is the starting point for this course.

This spring Rosa Delgado, Ridgeline's owner, decided to grow the wholesale side of the business. A dozen cafes and two grocery stores now buy Ridgeline coffee in bulk, and they order by phone, by email and sometimes by text message to Theo's personal phone. Rosa wants a proper wholesale ordering site where those customers can sign in, see their prices, place orders and download invoices, and she wants Kai's roast logs to feed a dashboard that shows what is roasting this week. Jordan Reyes, the barista who writes Ridgeline's Python tools, will build the application. Sam Ortiz, the support technician who looks after Ridgeline's computers and taught Jordan the basics of IT support in NET-101, will help decide where it should run.

The obvious question is whether to buy a server for the back office or to run the application in the cloud. Answering it properly needs the ideas in this course: what the cloud is, what the main kinds of cloud service are, how cloud providers build their infrastructure, how compute, storage, networking and identity work in the cloud, what containers and serverless functions are, how cloud costs and responsibilities are divided, and how infrastructure can be described in code. The course ends with Jordan and Sam deploying the wholesale site, so every lesson adds one piece of that final design.

A working definition

The phrase cloud computing is used loosely in advertising, but there is a precise definition that the industry and most governments rely on. It was written by the United States National Institute of Standards and Technology, known as NIST, in its Special Publication 800-145, and the Government of Canada's cloud guidance uses the same ideas. In NIST's words, cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications and services, that can be rapidly provisioned and released with minimal management effort or service provider interaction.

That sentence is dense, so it is worth unpacking. On-demand means you get resources when you ask for them, not after a purchase order and a delivery truck. Network access means you reach those resources over a network, usually the internet. A shared pool means the provider's hardware serves many customers at once. Configurable means you choose sizes and settings. Rapidly provisioned and released means you can create resources in minutes and give them back just as quickly. And minimal management effort means the provider handles the physical work of running data centres, so you do not.

NIST then lists five essential characteristics. A service that lacks one of them may still be useful, but it is not cloud computing in the strict sense. The table below sets them out with an example from Ridgeline's world for each.

Two of those characteristics deserve extra attention, because they change how technicians and developers work. Self-service means the person who needs a server can usually create it in a few clicks or a single command, which is wonderful for speed and dangerous for budgets and security if nobody sets limits. Measured service means every resource has a meter running, which turns forgotten test servers into a monthly charge. Both points come back in lesson 10, on cost management.

How we got here

Cloud computing did not appear from nowhere. In the 1960s and 1970s, organizations rented time on large shared mainframe computers, paying for the processing they used. Personal computers and then local servers moved computing into every office in the 1980s and 1990s, and by 2000 a typical business owned a room of servers, each running one application. Most of those servers sat idle most of the time, because each had to be sized for its busiest day.

Virtualization changed the economics. A hypervisor is software that lets one physical server run several virtual machines, each behaving like a separate computer with its own operating system. Companies used virtualization to combine many lightly used servers onto a few busy ones. The next step was to offer virtual machines to outside customers on demand. Amazon Web Services launched its Simple Storage Service, S3, in March 2006 and its Elastic Compute Cloud, EC2, later that year, letting anyone rent storage and virtual servers by the hour with a credit card. Google App Engine followed in 2008 and Microsoft Azure became generally available in 2010. Today those three companies, usually called the hyperscalers because of their enormous scale, run the largest public clouds, alongside others such as Oracle Cloud Infrastructure, IBM Cloud and Alibaba Cloud.

This course stays vendor-neutral. When it names a service, it shows the equivalent at Amazon Web Services (AWS), Microsoft Azure and Google Cloud side by side, because the ideas are the same everywhere even when the product names differ. If you go on to a vendor certification, such as AWS Certified Cloud Practitioner, Microsoft Azure Fundamentals or Google Cloud Digital Leader, you will find that most of what those exams test is in this course under a general name.

On premises or in the cloud

The traditional alternative to the cloud is called on premises, often shortened to on-prem: you buy the hardware, install it in a room you control, and run it yourself. On-premises computing is not obsolete. It still makes sense for equipment that must sit next to machines on the shop floor, for very steady workloads that run flat out all year, and for organizations with strict rules about where data lives. But it carries costs that are easy to underestimate.

The cost comparison is subtle. A back-office server might cost a few thousand dollars, which sounds cheaper than years of monthly cloud bills. But the server also needs a battery backup, a backup system, power, cooling, a replacement in five years, and, most expensively, someone's time to patch, monitor and repair it. Cloud providers price those things into their services, and they buy hardware at a scale no small business can match. On the other hand, a cloud resource that runs every hour of every month for years can end up costing more than equivalent owned hardware. The honest answer is that it depends on the workload, and the skill is in working it out.

Accountants describe the difference as capital expenditure, or CapEx, against operating expenditure, or OpEx. Buying a server is CapEx: a large payment up front for an asset that loses value over its life. Paying a cloud bill is OpEx: an ongoing cost that rises and falls with use. Many small businesses prefer OpEx because it avoids large up-front payments and matches spending to activity. Larger organizations sometimes prefer CapEx for steady workloads because it can be cheaper over time.

Jordan sketched the comparison for the wholesale site as a short script. The prices are invented for the example and are not quotes from any provider, but the shape of the calculation is the one every cloud decision uses: total the costs over the same period on each side, including the costs that are easy to forget.

# Three-year cost sketch for the wholesale site (example prices, in dollars)
months = 36

onprem = {
    "server hardware": 4200,
    "battery backup and spare drive": 650,
    "backup software and storage": 30 * months,
    "power and cooling": 22 * months,
    "Sam's time for patching and repairs": 90 * months,
}
cloud = {
    "small virtual machine": 38 * months,
    "managed database": 29 * months,
    "storage and backups": 6 * months,
    "data transfer": 4 * months,
}

for name, costs in (("On premises", onprem), ("Cloud", cloud)):
    total = sum(costs.values())
    print(f"{name:<12} {total:>7,} dollars over {months} months, about {total / months:,.0f} a month")

difference = sum(onprem.values()) - sum(cloud.values())
print("Cloud saves" if difference > 0 else "On premises saves", f"{abs(difference):,} dollars")

On premises    9,962 dollars over 36 months, about 277 a month
Cloud          2,772 dollars over 36 months, about 77 a month
Cloud saves 7,190 dollars

Look at how much of the on-premises total is Sam's time rather than hardware. That is typical: labour, not equipment, is usually the largest cost of running servers yourself. Press Edit and run and try changing the hours or the prices to see how sensitive the answer is.

def total_cost(upfront, monthly, months):
    # up-front amount plus monthly amount for each month
    return 0

def cheaper(a, b):
    # a and b are (name, total) tuples
    return a[0]

onprem = ("on premises", total_cost(4850, 142, 36))
cloud = ("cloud", total_cost(0, 77, 36))
print(onprem, cloud, cheaper(onprem, cloud))

Elasticity and why it matters

Ridgeline's sales are not steady. The cafe is busiest from seven to ten in the morning, the online shop peaks on weekday evenings, and wholesale orders cluster on Monday mornings when cafes restock after the weekend. December is the busiest month of the year by far, because coffee is a popular gift. An on-premises server has to be big enough for the busiest hour of the busiest day, which means it is far too big for almost every other hour.

Elasticity is the cloud's answer. Instead of owning capacity for the peak, you rent capacity that follows demand: more servers when the orders pour in, fewer when they stop. Two related words are often confused. Scalability is the ability of a system to handle more load when you give it more resources. Elasticity is the ability to add and remove those resources quickly, ideally automatically, as demand changes. A system can be scalable without being elastic, if adding capacity takes a week. The cloud makes elasticity practical.

The difference is easy to see with numbers. Suppose one small server can handle forty orders an hour, and Ridgeline's wholesale site sees the demand below over a typical Monday. A fixed setup must run enough servers for the busiest hour all day. An elastic setup runs only as many as each hour needs.

import math

orders_per_hour = [5, 4, 3, 3, 6, 18, 64, 121, 96, 52, 30, 22,
                   20, 18, 15, 14, 16, 25, 34, 28, 17, 11, 8, 6]
per_server = 40

needed = [max(1, math.ceil(n / per_server)) for n in orders_per_hour]
fixed = max(needed) * len(needed)
elastic = sum(needed)

print("Servers needed each hour:", needed)
print("Fixed capacity:", fixed, "server-hours")
print("Elastic capacity:", elastic, "server-hours")
print(f"Elastic uses {elastic / fixed:.0%} of the fixed server-hours")

Servers needed each hour: [1, 1, 1, 1, 1, 1, 2, 4, 3, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
Fixed capacity: 96 server-hours
Elastic capacity: 31 server-hours
Elastic uses 32% of the fixed server-hours

Over this day, elastic capacity uses less than half the server-hours of fixed capacity. The saving is real money, but elasticity also protects the customer experience: if an unexpected promotion doubles the morning orders, an elastic system adds servers instead of slowing to a crawl.

import math

def servers_needed(demand, per_server):
    # one entry per hour, rounded up, at least 1
    return []

def savings(demand, per_server):
    needed = servers_needed(demand, per_server)
    # fixed = the busiest hour's servers for every hour; elastic = sum of needed
    return 0

print(servers_needed([10, 50, 120], 40), savings([10, 50, 120], 40))

What changes for IT staff

Moving work to the cloud does not remove the need for IT skills; it changes which skills matter. Nobody at Ridgeline will ever replace a disk in a cloud server, but somebody must decide who is allowed to create resources, set sensible sizes, watch the monthly bill, keep backups, apply updates to the parts the customer still manages, and respond when something goes wrong. Cloud providers publish this division of labour as the shared responsibility model, which lesson 10 covers in detail. The short version is that the provider is responsible for the security of the cloud, meaning the buildings, hardware and core software, while the customer is responsible for security in the cloud, meaning their data, their accounts and how they configure the services.

Most cloud incidents that make the news are not failures of the provider's hardware. They are misconfigurations by customers: a storage bucket left open to the public, an administrator password with no second factor, or a test server forgotten and left running for a year. This course spends as much time on identity, configuration and cost as it does on servers, because that is where cloud work actually happens.

There is a human side too. Cloud work rewards people who write things down, who automate repeated tasks instead of clicking through them, and who think about cost as a design constraint rather than an afterthought. Jordan already writes Python, which turns out to be an advantage: almost every cloud service can be controlled through an API, and the main providers publish Python libraries for their APIs.