What the cloud actually is

Servers, virtualization, and the infrastructure behind everything

1,650 words9 min read

'The cloud' is one of those terms that sounds mystical until you understand what it actually means. There's no floating data in the sky. The cloud is just other people's computers - millions of physical servers sitting in massive data centers around the world. When you 'save to the cloud,' you're saving to a hard drive. It's just not your hard drive.

But there's more to it than that. The magic of cloud computing isn't the hardware - it's the software that makes those servers infinitely flexible. Through [[virtualization]], a single physical server can pretend to be dozens of independent computers. This is how Amazon, Google, and Microsoft can sell computing power like electricity: on-demand, pay-for-what-you-use, instantly scalable.

The shift to cloud computing represents one of the most significant changes in how we build and deploy software. Instead of buying servers, racking them in a data center, and maintaining them for years, developers can spin up resources in seconds and tear them down when finished. This has enabled entirely new ways of building software - from startups that scale to millions of users without owning a single server, to enterprises that can experiment without massive upfront investments.

Inside a data center

Modern data centers are engineering marvels. Rows upon rows of server racks fill warehouse-sized buildings, connected by miles of fiber optic cables. These facilities consume enormous amounts of electricity - not just to power the servers, but to cool them. A single rack of servers can generate as much heat as a small house. Google alone uses enough electricity to power a small country.

Cooling is often the biggest engineering challenge. Hot aisle/cold aisle configurations, liquid cooling, free air cooling in cold climates - data centers use every trick to remove heat efficiently. Some hyperscale providers have even built underwater data centers or located facilities near cold-water sources. PUE (Power Usage Effectiveness) - the ratio of total facility power to IT equipment power - is a key metric. A PUE of 1.0 would mean all power goes to computing; modern hyperscale data centers achieve 1.1-1.2.

Major cloud providers operate dozens of data centers across multiple continents, organized into 'regions' and 'availability zones.' This geographic distribution provides redundancy (if one center fails, others pick up the load), reduces latency (data travels shorter distances), and helps comply with data sovereignty laws (some countries require data to stay within their borders). AWS alone operates in 30+ regions with 100+ availability zones worldwide.

Virtualization: many computers from one

The key technology that enables cloud computing is [[virtualization]]. A [[hypervisor]] - software that sits between the physical hardware and operating systems - creates multiple [[virtual machines]] (VMs) on a single physical server. Each VM gets its own virtual CPU, memory, storage, and network interface. It behaves like a completely independent computer, unaware that it's sharing hardware with others.

There are two types of hypervisors. Type 1 (bare-metal) hypervisors like VMware ESXi, Microsoft Hyper-V, and Xen run directly on hardware with no host OS - they ARE the OS. Type 2 (hosted) hypervisors like VirtualBox and VMware Workstation run as applications on top of a conventional OS. Cloud providers use Type 1 for maximum efficiency and security.

Cloud Virtualization

App A
App B
App C
Guest OS
Guest OS
Guest OS
vCPU/vRAM
vCPU/vRAM
vCPU/vRAM
Hypervisor (VMware, KVM, Hyper-V)
Host Operating System
Physical Hardware (CPU, RAM, Storage, Network)
Hover over components to learn more
Virtual Machines
  • + Strong isolation
  • + Run different OS types
  • - GB of storage each
  • - Minutes to boot
Containers
  • + MB of storage each
  • + Seconds to start
  • + Higher density
  • - Share host kernel
Compare virtual machines and containers - two approaches to running multiple applications on shared hardware

Virtual machines provide strong isolation. If one VM crashes or gets hacked, others on the same physical server are protected. Each VM runs its own operating system kernel, so you can have Linux VMs and Windows VMs on the same hardware. But this comes at a cost: each VM needs gigabytes of storage for its OS and takes minutes to boot. There's also overhead - the hypervisor must translate between virtual and physical hardware.

Hardware virtualization extensions (Intel VT-x, AMD-V) dramatically improved VM performance by allowing certain instructions to execute directly on hardware rather than being trapped and emulated. Modern VMs typically achieve 95%+ of bare-metal performance for most workloads.

Containers: lighter than VMs

[[Containers]] take a different approach. Instead of virtualizing hardware and running separate operating systems, containers share the host's kernel and just isolate the application environment. A container packages an application with its dependencies (libraries, binaries, config files) but skips the full OS. The Linux kernel provides isolation through namespaces (separate views of processes, network, filesystem) and cgroups (resource limits).

[[Docker]] popularized containers by making them easy to build and deploy. A Docker container is defined by a Dockerfile - a simple text file that specifies the base image and any modifications. Containers start in seconds (no OS boot required), use megabytes instead of gigabytes, and you can run many more of them on the same hardware. An application that might need 10 VMs could run as 100+ containers.

Container images are built in layers, with each instruction in the Dockerfile creating a new layer. Base images provide the operating system environment (Ubuntu, Alpine, scratch), and you add your application on top. Images are stored in registries (Docker Hub, AWS ECR, Google Container Registry) and can be pulled to any machine with a container runtime. This reproducibility is a key advantage - the same image runs identically in development, testing, and production.

AspectVirtual MachinesContainers
IsolationComplete OS isolation (hypervisor)Process-level isolation (namespaces)
Boot timeMinutesSeconds (or milliseconds)
SizeGigabytes (includes OS)Megabytes (shared kernel)
DensityTens per serverHundreds or thousands per server
OS supportAny OS (Windows, Linux, etc.)Host kernel only (Linux on Linux)
OverheadHigher (hypervisor + OS)Lower (shared kernel)
SecurityStronger isolationKernel vulnerabilities affect all

Orchestration: managing thousands of containers

Running a few containers is easy. Running thousands across hundreds of servers? That requires [[orchestration]]. [[Kubernetes]] (K8s) has become the de facto standard tool for this. Originally developed by Google (based on their internal Borg system), it handles deploying containers, scaling them up and down based on demand, restarting failed containers, distributing load across machines, rolling out updates, and managing secrets and configuration.

Kubernetes treats your containers as cattle, not pets. Individual containers are disposable - if one fails, Kubernetes spins up a replacement. This philosophy enables incredible resilience: services can survive hardware failures, network issues, and even data center outages without human intervention. You declare the desired state ('I want 5 replicas of this service'), and Kubernetes continuously works to maintain it.

Key Kubernetes concepts include Pods (the smallest deployable unit, one or more containers that share network/storage), Deployments (manage replica sets and rolling updates), Services (stable network endpoints for pods), and Ingress (HTTP routing from outside the cluster). The learning curve is steep, but the abstraction is powerful - your application can run on any Kubernetes cluster regardless of the underlying infrastructure.

The three models: IaaS, PaaS, SaaS

Cloud services come in different flavors depending on how much you want to manage versus how much the provider handles:

  • Infrastructure as a Service (IaaS): Rent virtual machines and manage everything above the hypervisor. You control OS, runtime, and application. Most control, most responsibility. Examples: AWS EC2, Google Compute Engine, Azure Virtual Machines.
  • Platform as a Service (PaaS): Rent a platform that handles servers, scaling, and deployment. You just provide code. The platform handles OS patches, load balancing, and infrastructure. Examples: Heroku, Vercel, Google App Engine, AWS Elastic Beanstalk.
  • Software as a Service (SaaS): Use complete applications over the internet. You manage nothing but your data and configuration. Examples: Gmail, Salesforce, Dropbox, Slack.

There's also Function as a Service (FaaS) or 'serverless' - AWS Lambda, Google Cloud Functions, Cloudflare Workers. You don't even think about servers; you write individual functions that execute in response to events. The platform scales automatically, from zero to millions of executions, and you pay only for compute time used (often in 100ms increments). This model is ideal for event-driven architectures and intermittent workloads.

Multi-cloud and hybrid cloud

Many organizations use multiple cloud providers - AWS for some workloads, Google Cloud for others, Azure for enterprise integration. This [[multi-cloud]] strategy provides redundancy (not dependent on one provider), leverage (negotiate better pricing), and best-of-breed services (use each provider's strengths). The downside is complexity - different APIs, different tooling, different mental models.

[[Hybrid cloud]] combines public cloud with on-premises infrastructure. Sensitive workloads might run in your own data center while burst capacity runs in the cloud. This is common in regulated industries (finance, healthcare) where data residency matters. Technologies like AWS Outposts, Azure Arc, and Google Anthos extend cloud management to on-premises resources.

Why cloud computing changed everything

Before cloud computing, starting a business meant buying servers. You had to estimate capacity months in advance, purchase hardware, wait for delivery, rack and stack it, install software, configure networking, set up monitoring, plan for redundancy. If you underestimated, your site would crash under load. If you overestimated, you'd have expensive machines sitting idle. Capital expenditure was locked in upfront.

Cloud computing flipped this model. Now you can spin up a server in seconds, scale to handle a viral moment, then scale back down when traffic normalizes. You pay only for what you use, turning capital expenditure into operational expenditure. This elastic computing model has enabled countless startups to build and scale without massive upfront investment - and let established companies experiment without betting the farm.

Beyond cost flexibility, cloud computing enabled new architectural patterns. Microservices (decomposing applications into small, independent services) became practical when you could spin up services on demand. DevOps practices (continuous deployment, infrastructure as code) accelerated because infrastructure became programmable. The entire modern software stack - from development to deployment to operations - has been reshaped by cloud computing.

The cloud is not about cost savings; it's about agility and the ability to move fast.

Werner Vogels, CTO of Amazon
How Things Work - A Visual Guide to Technology