Learn Cloud Computing - History, Evolution & Definition of Cloud Computing

#Introduction

In episode 0, you prepared your environment: cloud accounts, CLI, and MFA. Now it's time to understand why the cloud exists. Many people jump straight into learning how to use it — creating VMs, buckets, and so on — without knowing the actual problems the cloud solves. As a result, architecture decisions feel like guesswork.

Episode 1 builds that conceptual foundation: how infrastructure evolved over decades, what triggered the birth of the cloud, and how NIST — the American government's standardization body — officially defines the cloud.

#The Pre-Cloud Era: On-Premise Data Centers

Before the cloud, nearly every company managed its own data center. All the hardware — servers, switches, storage, UPS, cooling systems — was bought, assembled, maintained, and replaced in-house. This model has three major problems:

Large upfront CapEx — hardware is purchased in advance, long before the need is clear.
Poor utilization — servers are provisioned to anticipate peak load, even though average usage is far below capacity.
Slow cycle — adding capacity takes days to months: procurement, shipping, racking, installation, configuration.

Imagine buying a full container truck before knowing how much cargo you'll ship. That's on-premise: paying in full upfront, then hoping the capacity gets used. That's why on-premise forces you to overestimate — and those estimates are always wrong.

#Colocation: Renting Space, Still Owning the Hardware

The first step toward efficiency is colocation (colo): companies rent racks, electrical power, and cooling at a provider-owned data center facility, but still buy and own their servers. Building costs disappear, but the hardware and provisioning problems remain — they've just been moved somewhere else.

#Virtualization: VMware, KVM, and Decoupling Software from Hardware

The next key leap was virtualization: software called a hypervisor splits one physical server into many independent virtual machines (VMs). VMware popularized this concept in the enterprise world; KVM brought it to Linux in an open way.

The impact was revolutionary: one physical server can run many operating systems simultaneously, each isolated. Hardware shifts from "one machine per application" to a shareable resource pool. VMs can be created, deleted, and migrated between hosts in minutes — something impossible in the physical era.

The command virsh list --all lists the VMs managed by the KVM/libvirt hypervisor on your machine. This VM concept later becomes the basic unit of computing in the cloud.

#Cloud Commercialization: AWS 2006, GCP 2008, Azure 2010

Virtualization proved that capacity could be shared, but it still needed someone to sell it as a service. Three companies took on that role in the 2000s decade.

Provider	Year	Initial Products	Origin
AWS	2006	S3 (March), EC2 (August)	Selling surplus capacity of Amazon's internal infrastructure
GCP	2008	App Engine	Commercializing the platform that runs Google services
Azure	2010	Windows Azure	Cloud for the Microsoft ecosystem (Windows, .NET, SQL)

All three show the same pattern: companies with massive infrastructure for their own needs, who then realized their capacity could be sold. Amazon, which built data centers every year to support its online store, discovered that more than 90% of its capacity sat idle outside peak seasons. Selling it as a service made far more sense than letting it go to waste.

#Regions and Availability Zones

One thing that distinguishes the cloud from ordinary virtualization is geographic scale. Cloud providers build data centers in groups called Regions (for example ap-southeast-1 in Singapore or asia-southeast1 in Jakarta). Within one Region there are several Availability Zones (AZs) — separate data centers kept at a safe distance from one another.

Why do AZs matter? Because failure is unavoidable — power outages, cut cables, or floods. By placing applications across multiple AZs, you get availability without building your own buildings. This is the big difference from on-premise: in the cloud, "where your servers live" becomes a service too.

Note

Learning to read Region codes early on will help you a lot. AWS uses formats like ap-southeast-1, GCP like asia-southeast1, and Azure like southeastasia. You'll encounter them often in CLI commands and configurations in the episodes ahead.

#NIST Definition of Cloud Computing

To keep the term "cloud" from becoming a vague buzzword, NIST published SP 800-145, which defines cloud computing through five mandatory characteristics. These five are the "legal requirements" for a service to be called cloud:

Characteristic	Meaning
On-demand self-service	Provision without human interaction from the provider
Broad network access	Access over standard networks from various devices
Resource pooling	Resources shared across many customers, physical location abstracted
Rapid elasticity	Capacity scales up and down automatically as needed
Measured service	Usage is measured and billed based on consumption

Notice the pattern behind all five: the cloud is a service that is automatic, affordable, and measurable. If a product lacks any of these five — for example, you still must submit a ticket to add capacity — then it's not really cloud yet.

#CapEx vs OpEx: Changing How You Think

The most tangible difference between on-premise and cloud lies in the financial model.

CapEx (Capital Expenditure) — upfront capital spending on long-term assets. Buying servers, building data centers, purchasing licenses. In on-premise, these costs are borne upfront and hard to reverse.
OpEx (Operating Expenditure) — recurring operational spending. Salaries, electricity, subscriptions. In the cloud, compute costs become OpEx: pay per hour or per usage.

This is the meaning of pay-as-you-go — pay only for what you use. If application load drops, costs drop too. If traffic rises, capacity rises automatically. Compare:

A concrete example: an e-commerce application that spikes 20x during a flash sale. On-premise, the IT team must buy extra servers well in advance — and those servers sit idle for the next 11 months. In the cloud, capacity grows within minutes when the surge hits, then shrinks back — and the bill follows: expensive during the spike, cheap after.

Aspect	On-premise (CapEx)	Cloud (OpEx)
Payment	Large, upfront	Per usage, small
Capacity	Fixed, over-provisioned	Elastic, matches load
Provisioning cycle	Weeks to months	Minutes
Hardware obsolescence risk	Borne by you	Borne by the provider
Economies of scale	Limited per company	Massive, shared across millions of customers

Tip

Pay attention to the word "elastic" — it's the bridge between the NIST characteristics and the cost model. Elasticity isn't just about technical capacity, it's also about money: capacity that shrinks automatically means a bill that shrinks automatically.

#The Evolution at a Glance

Era	Technology	Problem Solved
On-premise	Physical servers	Full ownership of infrastructure
Colocation	Rented racks + power	Data center building costs
Virtualization	VMware / KVM	Poor hardware utilization
Cloud	API + self-service	Slow provisioning and high costs
Serverless	Function-as-a-Service	Managing servers entirely

Each era moved one layer of responsibility from you to someone else — and the cloud continues that trajectory. In episode 2, you'll see exactly how far that layer can be moved.

#Conclusion

Episode 1 gives this series its conceptual foundation:

On-premise struggles with CapEx, utilization, and speed; colocation only moves the problem, virtualization actually solves it.
AWS (2006), GCP (2008), and Azure (2010) commercialized the capacity they owned.
NIST defines the cloud through five characteristics: on-demand, broad access, pooling, elasticity, and measured service.
The cloud shifts costs from CapEx to OpEx through pay-as-you-go.

In episode 2, we enter the cloud's operational language: the IaaS, PaaS, SaaS, and FaaS service models, plus the shared responsibility model — who is responsible for what, and how to map AWS, GCP, and Azure services side by side.