Cloud Computing: Someone Else's Computer

The Shift That Changed How All Software Gets Built

In 2006, a small startup called Netflix was spending $55,000 a month on physical servers. Every time traffic spiked — a popular show dropped, a holiday weekend hit — their site crashed. They could not afford enough servers for peak traffic, and most of the time the servers they did have sat idle, burning electricity and doing nothing. Today, Netflix handles 17% of all downstream internet traffic in the United States and owns zero servers. Every frame you stream runs on Amazon's cloud infrastructure. Netflix went from crashing under load to serving 260 million subscribers across 190 countries, and the key architectural decision was this: stop buying computers, start renting them.

The shift from "own your servers" to "rent what you need" is the single biggest change in how software is built and deployed in the last 20 years. It turned three-person startups into billion-dollar companies without anyone buying a single rack of hardware. It also created a $250 billion industry dominated by three companies that effectively run the internet's backbone. Whether you are building software, managing a business, or just trying to understand why your Google Docs never lose data, the cloud is the infrastructure beneath it all. Here is how it actually works.

What Cloud Computing Actually Means

Strip away the marketing and "the cloud" is not magic, not a metaphor, and not floating in the sky. It is actual physical data centers — warehouses full of servers, cooling systems, backup generators, and fiber-optic cables — owned and operated by companies like Amazon, Microsoft, and Google. Instead of buying your own hardware, you rent computing power from these facilities by the hour, minute, or even second.

The economics are what made it revolutionary. Before the cloud, launching a web application meant buying servers (capital expense), finding a place to put them (colocation facility or server closet), hiring someone to maintain them (system administrator), and hoping your traffic estimates were right. Overestimate and you waste money on idle hardware. Underestimate and your site crashes on launch day. Cloud computing converts that upfront capital expense into an ongoing operating expense — like switching from buying a car to paying for rides.

A single AWS data center region contains hundreds of thousands of servers. Amazon currently operates 34 regions worldwide, each containing multiple physically separated "availability zones" to protect against local failures. Google operates 40 regions. Microsoft Azure has 60+. These facilities are engineered for 99.99% uptime — meaning less than 53 minutes of downtime per year. Most companies running their own servers cannot come close to that reliability.

IaaS, PaaS, SaaS: Three Layers of "Someone Else's Problem"

Cloud services come in three layers, each abstracting away more of the complexity. Think of it as a spectrum: at one end, you control almost everything; at the other, you control almost nothing.

IaaS (Infrastructure as a Service) gives you raw computing resources: virtual machines, storage, and networking. AWS EC2 is the classic example — you pick an operating system, choose your CPU and RAM, and get what is essentially a remote computer. You install whatever software you want, configure the security, and maintain everything from the OS up. IaaS is what Netflix uses. It is what most tech companies building custom software use. Maximum flexibility, maximum responsibility.

PaaS (Platform as a Service) removes another layer of management. Heroku, Google App Engine, and AWS Elastic Beanstalk fall here. You hand over your application code and the platform handles the operating system, runtime, scaling, and load balancing. A developer can deploy a web application in minutes without ever thinking about which Linux distribution is running underneath. The tradeoff: you gain speed but lose some configurability.

SaaS (Software as a Service) is the layer most people touch every day without realizing it. Gmail, Slack, Salesforce, Dropbox, Netflix — these are all SaaS. You do not deploy code, manage servers, or configure anything technical. You open a browser, sign in, and use the software. The provider handles everything from the hardware to the application. This is the logical end state of "someone else's computer" — you do not even know where your data physically lives, and for most purposes, you do not need to.

The Big Three: AWS, Azure, and Google Cloud

Three companies control roughly two-thirds of the global cloud infrastructure market. Their combined revenue exceeds $250 billion per year — more than the GDP of most countries.

AWS (Amazon Web Services) was the first mover. Launched in 2006, it started because Amazon realized it had built world-class infrastructure to run its own e-commerce platform and could rent the excess capacity. Today AWS offers over 200 services — from basic compute and storage to machine learning, satellite ground stations, and quantum computing. It is the default choice for startups and the backbone for companies like Netflix, Airbnb, and NASA.

Microsoft Azure dominates the enterprise market. If a company already runs on Microsoft Office, Active Directory, and Windows Server, Azure is the path of least resistance. Azure is the US government's preferred cloud (it won the $10 billion JEDI defense contract, later restructured into JWCC). Its deep integration with the Microsoft ecosystem makes it the natural choice for Fortune 500 companies that have been Microsoft shops for decades.

Google Cloud Platform (GCP) has the smallest market share of the three but punches above its weight in specific domains. Google built the infrastructure that runs Search, YouTube, and Gmail — services operating at scales most companies never approach. GCP is strongest in data analytics (BigQuery), machine learning (Vertex AI, TensorFlow), and Kubernetes (Google invented the container orchestration system the industry now standardizes on). Spotify's migration to GCP is one of the highest-profile case studies in cloud adoption.

How Scaling Works: The Killer Feature

Scaling is the reason cloud computing won. Before the cloud, scaling meant buying more servers, waiting weeks for delivery, racking them in a data center, installing an operating system, configuring networking, and deploying your application. If you guessed wrong about traffic, you either crashed or wasted money. Cloud scaling flips this entirely.

Vertical scaling means making a single server bigger — more CPU cores, more RAM, faster storage. It is simple but has a ceiling. You cannot add infinite RAM to one machine. It also requires downtime to resize.

Horizontal scaling means adding more servers. This is what the cloud excels at. Instead of one powerful machine, you run 50 smaller ones behind a load balancer that distributes incoming requests evenly. If traffic doubles, you spin up 50 more. If it drops at 3 AM, you shut down 80 of them. Each server runs the same application, and the load balancer routes each user to whichever server has capacity.

Auto-scaling is the automation layer that makes this hands-free. You define rules — "if average CPU usage exceeds 70% for 5 minutes, add two servers" — and the cloud provider handles the rest. Netflix uses auto-scaling to add servers every evening when viewership climbs and remove them overnight when America sleeps. The graph below shows what this looks like across a typical 24-hour period.

This is the mathematical advantage that makes cloud computing the default for any workload with variable traffic. An e-commerce site that does 10x normal traffic on Black Friday would need to own 10x the servers year-round if self-hosted. With auto-scaling, those servers exist for one day and disappear the next. The savings are not marginal — they are structural.

Serverless: Do Not Even Think About Servers

If auto-scaling is "the cloud manages how many servers you have," serverless is "there are no servers, stop asking." Functions-as-a-Service (FaaS) platforms like AWS Lambda, Google Cloud Functions, and Azure Functions take the abstraction one step further. You write a single function — say, "resize this uploaded photo to create a thumbnail" — upload it, and define a trigger ("run this whenever a new image lands in storage"). The cloud runs your function, bills you for the 200 milliseconds of compute time it consumed, and shuts everything down.

No idle server sits waiting for uploads. No capacity planning. No patching the operating system. If nobody uploads a photo for six hours, you pay exactly zero. If a million users upload simultaneously, Lambda spins up a million parallel instances. The scaling is not automatic — it is invisible.

The catch? Serverless functions have limits. They are stateless (no memory between invocations), they have execution time limits (15 minutes on Lambda), and they suffer from "cold starts" — the first invocation after a period of inactivity takes longer because the runtime environment needs to initialize. For short, event-driven tasks like image processing, webhook handling, or data transformation, serverless is ideal. For long-running processes like video encoding or machine learning training, traditional servers are still the better fit.

The Real Costs: Cloud Is Not Always Cheaper

Cloud computing's economics are compelling for variable workloads, but the math changes for large, predictable ones. The gap between cloud marketing and cloud reality has produced some of the most instructive business decisions in recent tech history.

Netflix spends approximately $1.2 billion per year on AWS. For Netflix, this makes sense. Their traffic varies enormously — evening peaks in each time zone, massive surges during new show releases, quiet periods overnight. The alternative would be building and maintaining a global network of data centers capable of handling peak load, which would cost far more than $1.2 billion when you factor in real estate, power, cooling, hardware, staffing, and the fact that most of that capacity would sit idle most of the time.

Dropbox tells the opposite story. In 2016, Dropbox completed a two-year project to migrate the majority of its data off AWS and onto its own custom-built infrastructure. The result: $75 million in savings over two years. Dropbox's workload is fundamentally different from Netflix's — it is storage-heavy (exabytes of user files), predictable (files do not suddenly disappear at 3 AM), and constant (storage demands only grow). For that profile, owning hardware is cheaper than renting it at cloud markup.

The decision is not ideological — it is mathematical. Spotify ran its own data centers for years before migrating to Google Cloud Platform between 2016 and 2018 in a move that took two full years. The calculus for Spotify: they were spending enormous engineering effort maintaining infrastructure instead of building music features. By moving to GCP, they freed hundreds of engineers to work on the product instead of keeping servers running. The cost of cloud was higher on paper, but the opportunity cost of misallocated engineering talent was higher still.

Containers and Docker: Solving "It Works on My Machine"

Every developer has experienced this nightmare: the application works perfectly on their laptop, passes all tests, and then breaks catastrophically when deployed to a server. The reason is almost always environmental — a different operating system version, a missing library, a slightly different configuration file, or a dependency that was installed globally on the developer's machine but not on the server.

Containers solve this by packaging an application with everything it needs to run — code, runtime, libraries, system tools, and configuration — into a single, portable unit. If it runs in the container on your laptop, it runs in the same container on a test server, on a production cloud instance, or on your colleague's machine. The container is the consistent environment.

Docker is the tool that made containers practical. Released in 2013, Docker provided a simple way to define, build, and run containers using a plain-text file called a Dockerfile. Before Docker, containers existed (Linux had them for years) but were too complicated for most developers to use. Docker made them accessible, and adoption exploded.

A Docker container is not a virtual machine. A virtual machine includes a complete operating system — kernel, drivers, everything — which makes it heavy (gigabytes in size, minutes to start). A container shares the host operating system's kernel and only packages the application layer, making it lightweight (megabytes in size, starts in seconds). You can run hundreds of containers on a single server where you might manage only a handful of virtual machines.

Kubernetes (often shortened to K8s) is the orchestration layer that manages containers at scale. If Docker is a shipping container, Kubernetes is the port authority that decides which containers go on which ships, reroutes when a ship is full, and replaces containers that fall overboard. Google originally developed Kubernetes internally (they had been running containers at massive scale for over a decade) and open-sourced it in 2014. Today, Kubernetes is the industry standard for running containerized applications in production. Every major cloud provider offers a managed Kubernetes service.

Cloud Security: The Configuration Problem

The knee-jerk reaction to cloud computing is "but is it secure?" The short answer: the cloud providers themselves are among the most secure computing environments on Earth. AWS, Azure, and Google Cloud spend billions annually on security — physical security (biometric access, 24/7 surveillance, man-traps at data center entrances), network security (DDoS mitigation, encryption in transit and at rest), and compliance (SOC 2, HIPAA, FedRAMP, ISO 27001). Most companies could not afford a fraction of this infrastructure for their own data centers.

The real risk is not the cloud — it is misconfiguration. The most common cloud security breaches happen because someone leaves a storage bucket publicly accessible, uses weak credentials, or grants overly broad permissions. The 2019 Capital One breach, which exposed data on 100 million customers, was caused by a misconfigured firewall rule on an AWS instance — not by a flaw in AWS itself.

Cloud security operates on a shared responsibility model. The provider secures the infrastructure — the physical data centers, the hypervisors, the network hardware. The customer secures what they put on it — their data, their access controls, their application code. The dividing line moves depending on the service tier. With IaaS, you are responsible for everything from the operating system up. With SaaS, the provider handles nearly all of it. Understanding where that line falls is the difference between a secure deployment and a headline-making breach.

Real-World Cloud Architecture

To make this concrete, here is a simplified version of how a modern application like Airbnb might be architected on the cloud.

Each component runs as a managed cloud service. The CDN (CloudFront) has edge servers in 50+ countries. The load balancer (ALB) distributes traffic across application instances running in containers. The database (RDS or DynamoDB) is replicated across availability zones for fault tolerance. The cache layer (ElastiCache/Redis) stores frequently accessed data in memory for sub-millisecond response times. None of this hardware is owned by Airbnb. All of it can scale independently based on demand.

A single AWS region — us-east-1 in Northern Virginia — handles more internet traffic than most countries. It is the default region for AWS, which means a disproportionate share of the internet's infrastructure runs from data centers in a corridor along the Dulles Toll Road. When that region has had outages (multiple times, including a notable incident in 2017 caused by a mistyped command), the disruption has rippled across thousands of websites and services simultaneously.

The Environmental Question

Data centers consume approximately 1-1.5% of global electricity — a number that is growing as AI workloads demand more compute. The environmental case for cloud computing is nuanced. On one hand, shared infrastructure is inherently more efficient than every company running its own servers. Cloud providers operate at scales where they can invest in custom-designed, energy-efficient hardware, advanced cooling systems, and renewable energy procurement that individual companies cannot match. Google has been carbon neutral since 2007 and claims to match 100% of its electricity consumption with renewable energy purchases. Microsoft has pledged to be carbon negative by 2030. AWS has committed to 100% renewable energy by 2025.

On the other hand, the efficiency gains from cloud consolidation have been partially offset by the sheer growth in computing demand. More efficient infrastructure lowers the cost of compute, which increases demand for compute — a dynamic economists call a rebound effect. AI training runs, in particular, are enormously energy-intensive. Training a single large language model can consume as much electricity as 100 US homes use in a year. Whether cloud computing is net positive or net negative for the environment depends on whether you compare it to the alternative (every company running its own less-efficient servers) or to a world with less total compute.

Answers to Questions People Actually Ask

Is the cloud secure? Cloud providers spend more on security than most companies' entire IT budgets. The risk is not the cloud infrastructure itself — it is misconfiguration by the people using it. Leaving a storage bucket publicly accessible, using weak passwords, or granting overly broad permissions causes the vast majority of cloud security incidents. The providers give you the tools. Using them correctly is on you.

What happens if AWS goes down? It has, multiple times. In 2017, a typo in an AWS S3 command during a routine debugging exercise took down a significant portion of the internet for several hours — affecting sites from Slack to Trello to the SEC. The lesson: design for failure. Serious applications distribute across multiple availability zones (separate data centers within a region) or even multiple regions (completely independent infrastructure in different geographic locations). Netflix runs a tool called Chaos Monkey that randomly terminates production instances to ensure their system can tolerate failures at any time.

Can I use the cloud for personal projects? Yes, and it is often free. AWS, Google Cloud, and Azure all offer free tiers that include limited compute, storage, and database resources at no charge. You can run a small website, API, or personal project for $0-5/month. Many developers use the free tier for years before ever paying a bill. The catch: watch for unexpected charges from services you forgot to turn off or data transfer costs that exceed the free allocation.

What is the environmental impact? Data centers consume about 1-1.5% of global electricity. However, consolidated cloud infrastructure is significantly more efficient than the alternative — thousands of companies each running their own small, inefficient server rooms. The major providers are investing heavily in renewable energy, and shared infrastructure means higher utilization rates (less wasted capacity). Cloud computing likely reduces total energy consumption compared to a world where everyone hosts their own servers, but the growth of AI workloads is an open question.

Why do cloud bills get so high? Three common traps. First, forgotten resources — a test server left running for months, a database snapshot accumulating storage charges. Second, data transfer costs, which cloud providers price aggressively (downloading data from the cloud is often far more expensive than uploading it — a phenomenon called "egress pricing" that critics call a lock-in strategy). Third, over-provisioning — running larger instances than necessary because nobody bothered to right-size after launch. Companies routinely find 30-40% waste in their cloud bills when they actually audit them.

Where Cloud Computing Takes You Next

Understanding cloud computing is foundational to understanding modern software. Every startup pitch, every tech job listing, every discussion about data privacy and digital sovereignty assumes you know what the cloud is and how it works. The concepts here — IaaS/PaaS/SaaS layers, horizontal scaling, containers, serverless, the shared responsibility model — are the vocabulary of modern technology infrastructure.

The cloud is not a trend that might reverse. It is the settled architecture of how computing works now. The interesting questions going forward are about the edges: where does cloud end and on-premises begin? How will AI workloads change the economics? Will regulation force data localization that fragments the global cloud? What happens when the three dominant providers have enough leverage to raise prices — and do customers have enough alternatives?

Those are strategic questions. But they only make sense if you first understand the mechanical reality beneath them: somewhere in Northern Virginia, Oregon, Dublin, or Singapore, in a climate-controlled warehouse you will never see, a physical server is running your code right now. Someone else owns it. You are renting it by the second. And that arrangement — strange as it sounds — is why a 3-person startup can serve 100 million users without buying a single piece of hardware.