Someone else's computer, rented by the minute

The cloud is a set of computers in data centres that you rent instead of buy. That is the whole idea. Everything else — the acronyms, the pricing calculators, the certification tracks — is detail layered on top of renting compute, storage, and network capacity from a company that runs it at scale.

What makes it different from a server under a desk is not the hardware. It is that capacity arrives in minutes rather than weeks, you pay for what you use, and someone else handles the power, cooling, and failed disks.

The three service models

Nearly every cloud product fits one of three shapes, and the difference is simply how much of the stack you still manage:

  • Infrastructure as a Service (IaaS) — you rent raw machines and disks. Maximum control, maximum responsibility: patching, scaling, and security are yours.
  • Platform as a Service (PaaS) — you hand over code and the platform runs it. No servers to patch, less control over the environment.
  • Software as a Service (SaaS) — you just use the finished product. Gmail and Google Workspace are SaaS; you manage accounts, nothing more.

Most small businesses need far less IaaS than they expect. A static site on managed hosting with a CDN in front of it is cheaper, faster, and harder to break than a virtual machine you have to maintain.

Who manages what Yellow is yours to run. Grey is handled for you. LAYER IaaS PaaS SaaS Application Runtime Operating system Virtual machines Servers and network Data centre Most control Middle ground Least upkeep
The less of the stack you manage, the fewer things there are to keep patched.

The three big providers

AWS, Microsoft Azure, and Google Cloud dominate, and for most projects the choice matters less than people think. The deciding factors are usually practical:

  • AWS — the widest service catalogue and the most documentation and community answers.
  • Azure — the natural fit if your organisation already runs Microsoft 365 and Active Directory.
  • Google Cloud — strong on data, analytics, and container tooling.
Amazon Web Services logo Microsoft Azure logo Google Cloud logo

Pick the one your team can actually operate. A well-run setup on any of the three beats a neglected setup on the one with the best marketing.

The pieces you will actually touch

A typical website or app touches a small, predictable set of services:

  • Compute — where your code runs: a virtual machine, a container, or a serverless function.
  • Storage — object storage for images, uploads, and backups, billed by the gigabyte.
  • Database — a managed engine so backups and failover are not your problem.
  • DNS — the records that point your domain at all of the above.
  • CDN — caches copies of your site near your visitors, which is the single biggest speed win for an audience spread across regions.
  • Certificates — the SSL that puts the padlock in the address bar.
The five that cause most outages Configuration, not code. DNS points at the live server after every migration SSL renews automatically check the expiry date One canonical domain, no loops www or bare, pick one Production environment variables set not just locally Backups and billing alerts on before launch day
Five configuration checks that prevent most small-site outages.

What you are really paying for

Cloud billing catches people out because it is metered rather than fixed. The recurring surprises are almost always the same three:

  • Egress — moving data out of the provider costs money; moving it in usually does not.
  • Idle resources — a machine you provisioned for a test in March is still billing in August.
  • Over-provisioning — paying for capacity sized to a traffic spike that has not happened yet.

Set a billing alert on day one. It takes two minutes and it is the difference between noticing a mistake at ten dollars and noticing it at three hundred.

Where the bill actually comes from Metered, not fixed. These three cause most surprises. Egress data leaving the provider in is free, out is not Idle resources the test machine from March still billing in August Over-provisioning capacity for a spike that has not come size it later Set a billing alert on day one. Two minutes, and it catches all three.
Alerts on billing and uptime are the two to configure before launch day.

The settings that decide whether you stay up

In our experience most outages on small sites are not code failures. They are configuration:

  • DNS records pointing at an old server after a migration.
  • An SSL certificate that expired because nothing was set to renew it.
  • A redirect loop between the www and non-www versions of a domain.
  • Environment variables that exist locally and were never set in production.
  • Storage permissions left open, or locked so tight the app cannot read its own files.

None of these are difficult. They are simply easy to forget, which is why a launch checklist matters more than deep provider knowledge.

A reasonable starting point

  • Static or brochure site: managed static hosting plus a CDN and automatic SSL. Cheap, fast, very little to break.
  • Site with a backend: a managed platform for the app and a managed database. Skip raw virtual machines until you have a reason.
  • Mobile app backend: managed APIs and storage, with alerting from the first release rather than the first outage.

Whichever route you take, get three things in place before launch: automated backups, a billing alert, and an uptime check that tells you about a problem before a customer does.

If the cloud part is the blocker

Configuration is the piece most teams would rather hand over, and it is a large part of what we do — hosting, DNS, SSL, redirects, storage, access, and environments on AWS, Azure, or Google Cloud, then maintenance so it keeps working after launch. If something is live and broken right now, send the error and the environment details.