Cloud Fundamentals

Traditional IT and Cloud Compared

On premises, colocation, managed hosting and cloud are four different deals. Comparing them on cost, lead time, control and responsibility makes the choice concrete instead of ideological.

On this page (17)

Concept

People say "on premises versus cloud" as if there were two options. There are at least four, and they differ in who owns the building, who owns the hardware, and who is woken up when a disk fails.

The four models

Model	You own	Provider owns	Typical lead time for a new server
On premises	Building, power, cooling, hardware, everything	Nothing	Weeks to months
Colocation	The hardware	Building, power, cooling, network connectivity	Days to weeks
Managed hosting	The operating system and above, usually	Building and hardware, sometimes the OS	Hours to days
Cloud	Your workload and configuration	Everything below your chosen layer	Seconds to minutes

Architecture

                 ON PREM   COLO   MANAGED HOSTING   CLOUD
Application        you      you        you           you
Runtime and OS     you      you      shared          you*
Virtualisation     you      you     provider      provider
Servers            you      you     provider      provider
Storage, network   you      you     provider      provider
Building, power    you    provider  provider      provider

* on the compute services in this note. Higher level services
  move the runtime and OS to the provider as well.

Compared on what actually matters

Dimension	Owned hardware	Cloud
Payment shape	Large amount up front, then small running costs	Nothing up front, continuous usage based charges
Capacity decision	Made years ahead, hard to reverse	Made today, reversible in minutes
Idle capacity	You paid for it either way	You can switch it off and stop paying
Failure handling	Spares on a shelf, an engineer on site	Terminate and recreate, ideally automatically
Control	Total, including hardware choice	Bounded by what the provider exposes
Expertise needed	Hardware, facilities, networking	Identity, networking, automation, cost management
Where it wins	Steady, predictable, long lived load; strict residency	Variable, uncertain, short lived or globally spread load

Important terminology

Term	Meaning
On premises	Infrastructure in a building your organisation controls. Often shortened to on prem.
Colocation	Your hardware in someone else building, using their power, cooling and connectivity.
Bare metal	A physical server with no virtualisation layer between you and the hardware.
Utilisation	The fraction of purchased capacity actually doing work. Owned hardware often runs below twenty per cent.
Refresh cycle	The interval at which hardware is replaced, commonly three to five years.
Total cost of ownership	Every cost over the life of the system, not just the purchase price.

Real world example

Two teams need a server for an internal reporting tool used by forty people during office hours.

Team A buys hardware. Purchase approval takes five weeks, delivery three, installation and configuration one. The tool is live in nine weeks. It runs at about eight per cent utilisation for four years.
Team B uses cloud. A small instance exists in two minutes. A schedule stops it at 20:00 and starts it at 07:00 on weekdays, so it bills for roughly a third of the hours in a week.

Team A owns an asset and has predictable costs. Team B was useful eight weeks earlier and can resize the instance the day the report set grows. Neither is wrong - but only one of them can change its mind cheaply.

Commands

Before comparing anything, measure what you already have. These run on any Linux server.

# CPU count and model
nproc
lscpu | head -20

# Memory in human readable units
free -h

# Disk usage per mounted filesystem
df -h

# Current load average and uptime
uptime

# Sustained CPU and memory use, refreshing every 5 seconds, 12 samples
vmstat 5 12

Command options worth knowing

Option	Effect
`free -h`	Human readable sizes instead of raw kilobytes.
`df -h`	Same, per filesystem. Add `-i` to show inode usage instead of bytes.
`vmstat 5 12`	Twelve samples five seconds apart - one minute of real behaviour rather than one instant.
`uptime`	Load averages over 1, 5 and 15 minutes. Compare them to `nproc`, not to each other.

Hands on lab

On any Linux machine you have, record nproc, total memory from free -h, and total disk from df -h.
Run vmstat 5 12 while you use the machine normally.
Look at the id column, which is idle CPU percentage. Average it roughly.
Calculate utilisation as 100 minus average idle. Write down the number.
Ask yourself what size of cloud instance that workload actually needs. It is almost always smaller than the machine it is running on.

Expected output

$ nproc
4

$ free -h
               total        used        free      available
Mem:            7.6Gi       2.1Gi       3.9Gi          5.2Gi

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       78G    31G   44G  42% /

$ vmstat 5 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0      0 4071232 210444 2118392    0    0     6    22  310  602  7  2 91  0
 0  0      0 4068104 210444 2118392    0    0     0     8  288  554  5  1 94  0
 0  0      0 4069880 210444 2118392    0    0     0    14  301  571  6  2 92  0

Idle sits around 92 per cent, so this four core machine is doing roughly one third of one core of real work. That is the gap that makes right sizing worth doing.

Common mistakes

Comparing purchase price to a monthly bill. Include power, cooling, space, network, spares, staff time and the useful life of the hardware.
Ignoring utilisation. Paying for four cores to use one third of one is the real cost of owned hardware, and it never appears on an invoice.
Assuming a like for like instance size. Migrating a 2019 server specification into 2026 hardware usually means paying for capacity you no longer need.
Forgetting the exit. Owned hardware has disposal and data destruction costs. Cloud has egress and re-architecture costs. Both have an ending.

Troubleshooting a comparison that looks wrong

Symptom	Likely cause	Check
Cloud looks absurdly expensive	Sized from the old hardware, not the measured load	Utilisation from `vmstat`
On prem looks free	Staff time and facilities excluded	Ask who replaces a failed disk at 02:00, and what that costs
Numbers swing wildly	Different retention or redundancy assumptions on each side	Write both options against the same availability target

Security considerations

Owned hardware gives physical control and puts physical security entirely on you.
Cloud removes physical risk and adds identity and configuration risk. A single over permissive policy can expose more than a locked server room ever did.
Data destruction differs: on hardware you shred a disk, in cloud you delete and rely on the provider mechanism. Know which applies before storing regulated data.

Best practices

Compare on total cost of ownership across the same time period, usually three years.
Size from measurements, never from the specification of the machine you are replacing.
State the availability target first. It changes both sides of the comparison more than any price does.
Keep the decision reversible where it is cheap to do so.

Interview questions

Name four infrastructure models and state who owns what in each.
When is owning hardware still the better financial choice?
What is total cost of ownership, and name three costs teams routinely forget?
How would you size a cloud instance for an existing physical server?

Mini assignment

Take one machine you can access. Record its specification and its measured utilisation over ten minutes. Write a short recommendation for the equivalent cloud instance size, and state one risk of choosing it.

Conclusion

The four models are different deals over the same stack. Choose by lead time, utilisation, control and residency - not by which word sounds more modern.

Useful resources

Hand picked references for this topic

kubectl Reference

Official reference for the kubectl command line tool.

Topics #Beginner #Cloud Computing #Hands On Lab #Linux #Linux Commands

Written by Lorens Mishra

Software Engineer Notes Management System Administrator