Cloud Computing: What It Actually Is and Why It Changed How Software Gets Built

Before 2006, if a startup wanted to run a web application, the founders had to buy physical servers, rack them in a data centre, negotiate power and cooling contracts, hire someone to manage the hardware, and wait weeks for delivery. Amazon Web Services changed that calculus permanently. Today a developer can provision a virtual server in under a minute, pay for it by the hour, and shut it down when traffic drops. That shift — from capital expenditure to operational expenditure, from weeks to seconds — is cloud computing in practical terms.

What Cloud Computing Actually Means

The formal definition from NIST (National Institute of Standards and Technology) describes cloud computing as a model for enabling on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort. Strip the bureaucratic language and you get: rent compute, storage, and networking from someone else’s data centre, over the internet, and pay only for what you use.

The five characteristics NIST calls essential are worth knowing:

• On-demand self-service — you provision resources through a console or API without calling anyone
• Broad network access — resources are reachable from laptops, phones, and other services over standard protocols
• Resource pooling — the provider serves many customers from shared infrastructure, isolating each tenant logically
• Rapid elasticity — capacity scales up or down automatically based on demand
• Measured service — usage is tracked, controlled, and reported so billing reflects actual consumption

Traditional IT vs Cloud Model
-------------------------------
Traditional:
  [Your Hardware] --> [Your DC] --> [Your Team Manages Everything]
  Upfront cost: $$$$$   Time to provision: weeks

Cloud:
  [AWS / Azure / GCP] --> [Your App] --> [You manage config + code]
  Upfront cost: $0      Time to provision: minutes
  Pay per hour used

The Three Service Models

Cloud providers package their offerings into three abstraction layers. Each layer trades control for convenience.

Infrastructure as a Service (IaaS)

IaaS gives you virtual machines, block storage, and virtual networks. The provider manages physical hardware, hypervisors, and data centre facilities. You manage everything from the operating system upward: patches, middleware, runtime, application code, and data.

Use this when you need direct control over the OS — for example, running a licensed database engine that requires specific kernel parameters, or migrating a legacy application that cannot be containerised yet.

Platform as a Service (PaaS)

PaaS adds the operating system, runtime, middleware, and often a database. You bring code and configuration. The provider handles patching, scaling, and the underlying infrastructure. Google App Engine, AWS Elastic Beanstalk, and Azure App Service are examples. Developers write code, push it, and the platform handles the rest.

Software as a Service (SaaS)

SaaS delivers a complete application over the internet. You log in and use it. The provider manages everything: hardware, OS, middleware, application code, and updates. Salesforce, Gmail, Slack, and Zoom are SaaS products. The end-user never thinks about infrastructure at all.

Responsibility Stack by Service Model
---------------------------------------
Layer           | On-Prem | IaaS | PaaS | SaaS
----------------|---------|------|------|------
Applications    |  You    | You  | You  | Vendor
Data            |  You    | You  | You  | Shared
Runtime         |  You    | You  | Vend | Vendor
Middleware      |  You    | You  | Vend | Vendor
OS              |  You    | You  | Vend | Vendor
Virtualisation  |  You    | Vend | Vend | Vendor
Physical HW     |  You    | Vend | Vend | Vendor

Deployment Models

The service model answers “what does the provider manage?” The deployment model answers “who can access the environment?”

Public cloud infrastructure is owned and operated by a third-party provider and shared across many customers. AWS, Azure, and GCP are public clouds. Workloads run on shared physical hosts, isolated by hypervisors and networking controls. Cost is lowest here because the infrastructure is shared.

Private cloud infrastructure is dedicated to a single organisation. It may run in a provider’s data centre (hosted private cloud) or on the organisation’s own premises. A hospital processing patient records under strict HIPAA requirements, or a defence contractor with government security clearances, might choose private cloud for control and audit purposes.

Hybrid cloud connects a private environment to a public one, typically over a private link or VPN. The financial services sector uses this heavily: sensitive trading data stays on-premises while batch analytics jobs run on public cloud burst capacity during peak periods.

Multi-cloud is a variant where an organisation deliberately uses services from two or more public providers — perhaps AWS for compute and GCP for its data analytics tooling. The benefit is avoiding dependency on any single vendor; the cost is operational complexity.

The Shared Responsibility Model

One of the most misunderstood concepts in cloud security. The cloud provider secures the infrastructure — physical facilities, hypervisor software, network hardware, and the managed service control plane. The customer secures what they run on that infrastructure: their data, identity controls, network configuration, and application code.

A breach caused by a misconfigured S3 bucket that exposes customer data is the customer’s responsibility, not Amazon’s. The provider secured the storage service; the customer chose to make the bucket public. Understanding this boundary is non-negotiable before putting any sensitive workload in the cloud.

A Real Business Case: E-Commerce at Scale

A mid-size retailer runs a daily peak at 8 PM when promotional emails go out. For fifteen minutes, traffic is ten times the daily average. On traditional infrastructure, they would provision enough servers to handle that peak — leaving 90% idle for the other 23 hours and 45 minutes.

On AWS, they configure Auto Scaling groups that watch CPU utilisation and add EC2 instances within 90 seconds of a spike. When traffic drops, the extra instances terminate automatically. They pay only for those extra instances during those extra minutes. Annual server costs drop by roughly 60% while handling the same peak load without degradation.

Why This Matters Beyond Cost

The cost argument is straightforward. What is less obvious is how cloud changed development speed. When provisioning infrastructure takes minutes instead of weeks, engineers experiment more. A hypothesis about a new feature can be tested in an isolated environment spun up on Monday and deleted on Friday. Failure costs almost nothing. That low cost of experimentation is what drives the iteration speed at modern software companies.

Cloud also democratised access to capabilities that previously required massive capital. A two-person startup in 2024 can access GPU compute for machine learning training, global content delivery networks, managed Kubernetes, and petabyte-scale data warehouses — services that required hundreds of millions in infrastructure investment a decade ago.

Understanding cloud computing is no longer optional for anyone working in software. Whether you write code, manage systems, or make product decisions, the infrastructure your work runs on is almost certainly cloud-based, and knowing how that infrastructure works makes you substantially more effective at your job.