Belajar Cloud Computing - Sejarah, Evolusi & Definisi Cloud Computing

#Pendahuluan

Di episode 0, kalian sudah menyiapkan environment: akun cloud, CLI, dan MFA. Sekarang saatnya memahami mengapa cloud ada. Banyak orang langsung belajar cara pakai — membuat VM, bucket, dan lain-lain — tanpa tahu masalah yang sebenarnya dipecahkan cloud. Akibatnya, keputusan arsitektur terasa seperti menebak.

Episode 1 membangun fondasi konseptual itu: bagaimana infrastruktur berevolusi selama puluhan tahun, apa yang memicu lahirnya cloud, dan bagaimana NIST — lembaga standardisasi pemerintah Amerika — mendefinisikan cloud secara resmi.

#Era Sebelum Cloud: On-Premise Data Center

Sebelum cloud, hampir semua perusahaan mengelola data center sendiri. Semua hardware — server, switch, storage, UPS, sistem pendingin — dibeli, dirakit, dirawat, dan diganti sendiri. Model ini punya tiga masalah besar:

CapEx besar di awal — hardware dibeli di muka, jauh sebelum kebutuhannya jelas.
Utilisasi buruk — server di-provision untuk mengantisipasi peak load, padahal rata-rata pemakaian jauh di bawah kapasitas.
Siklus lambat — menambah kapasitas butuh berhari-hari sampai berbulan-bulan: procurement, pengiriman, rak, instalasi, konfigurasi.

Bayangkan membeli truk kontainer penuh sebelum tahu berapa banyak barang yang akan dikirim. Itu on-premise: membayar penuh di depan, lalu berharap kapasitasnya terpakai. Itulah mengapa on-premise memaksa estimasi ke atas — dan estimasi itu selalu salah.

#Colocation: Menyewa Ruang, Tetap Pemilik Hardware

Langkah pertama menuju efisiensi adalah colocation (colo): perusahaan menyewa rack, daya listrik, dan pendingin di fasilitas data center milik penyedia, tetapi tetap membeli dan memiliki server sendiri. Biaya gedung hilang, tapi masalah hardware dan provisioning belum hilang — hanya dipindah tempat.

#Virtualisasi: VMware, KVM, dan Pemisahan Software dari Hardware

Lompatan kunci berikutnya adalah virtualisasi: sebuah software bernama hypervisor membagi satu server fisik menjadi banyak virtual machine (VM) yang independen. VMware mempopulerkan konsep ini di dunia enterprise; KVM membawanya ke Linux secara terbuka.

Dampaknya revolusioner: satu server fisik bisa menjalankan banyak sistem operasi sekaligus, masing-masing terisolasi. Hardware berubah dari "satu mesin untuk satu aplikasi" menjadi pool resource yang bisa dibagi. VM bisa dibuat, dihapus, dan dipindah antar host dalam hitungan menit — sesuatu yang mustahil di era fisik.

Perintah virsh list --all menampilkan daftar VM yang dikelola hypervisor KVM/libvirt di mesin kalian. Konsep VM inilah yang nanti menjadi unit dasar komputasi di cloud.

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

Virtualisasi membuktikan bahwa kapasitas bisa dibagi, tapi masih butuh siapa yang menjualnya sebagai layanan. Tiga perusahaan mengambil peran itu dalam dekade 2000-an.

Penyedia	Tahun	Produk Awal	Cikal Bakal
AWS	2006	S3 (Maret), EC2 (Agustus)	Menjual kelebihan kapasitas infrastruktur internal Amazon
GCP	2008	App Engine	Mengomersialkan platform yang menjalankan layanan Google
Azure	2010	Windows Azure	Cloud untuk ekosistem Microsoft (Windows, .NET, SQL)

Ketiganya menunjukkan pola yang sama: perusahaan yang punya infrastruktur raksasa untuk kebutuhan sendiri, lalu menyadari bahwa kapasitasnya bisa dijual. Amazon, yang setiap tahun membangun data center untuk mendukung toko online-nya, menemukan bahwa lebih dari 90% kapasitasnya menganggur di luar musim puncak. Menjualnya sebagai layanan jauh lebih masuk akal daripada membiarkannya menganggur.

#Region dan Availability Zone

Satu hal yang membedakan cloud dari virtualisasi biasa adalah skala geografis. Penyedia cloud membangun data center dalam kelompok yang disebut Region (misalnya ap-southeast-1 di Singapura atau asia-southeast1 di Jakarta). Di dalam satu Region ada beberapa Availability Zone (AZ) — data center terpisah yang saling menjaga jarak aman.

Mengapa AZ penting? Karena kegagalan tidak bisa dihindari — listrik mati, kabel putus, atau banjir. Dengan menempatkan aplikasi di beberapa AZ, kalian mendapat ketersediaan tanpa membangun gedung sendiri. Inilah perbedaan besar dengan on-premise: di cloud, "tempat menyimpan server" ikut menjadi layanan.

Note

Belajar membaca kode Region sejak awal akan sangat membantu. AWS memakai format seperti ap-southeast-1, GCP seperti asia-southeast1, dan Azure seperti southeastasia. Kalian akan sering menemuinya di perintah CLI dan konfigurasi pada episode-episode berikutnya.

#Definisi NIST Cloud Computing

Agar istilah "cloud" tidak jadi buzzword yang tidak jelas, NIST menerbitkan SP 800-145 yang mendefinisikan cloud computing dengan lima karakteristik wajib. Lima hal ini adalah "syarat sah" sebuah layanan disebut cloud:

Karakteristik	Makna
On-demand self-service	Provision tanpa interaksi manusia dari penyedia
Broad network access	Akses lewat jaringan standar dari berbagai device
Resource pooling	Resource dibagi banyak pelanggan, lokasi fisik abstrak
Rapid elasticity	Kapasitas naik-turun otomatis sesuai kebutuhan
Measured service	Pemakaian diukur dan ditagih sesuai pemakaian

Perhatikan pola di balik kelimanya: cloud adalah layanan yang otomatis, terjangkau, dan terukur. Kalau sebuah produk tidak punya salah satu dari lima ini — misalnya tetap harus mengirim tiket untuk menambah kapasitas — maka produk itu belum benar-benar cloud.

#CapEx vs OpEx: Mengubah Cara Kalian Berpikir

Perbedaan paling nyata antara on-premise dan cloud ada di model keuangan.

CapEx (Capital Expenditure) — pengeluaran modal di muka untuk aset jangka panjang. Membeli server, membangun data center, membeli lisensi. Di on-premise, biaya ini ditanggung di awal dan sulit ditarik kembali.
OpEx (Operating Expenditure) — pengeluaran operasional berulang. Gaji, listrik, langganan. Di cloud, biaya komputasi menjadi OpEx: bayar per jam atau per pemakaian.

Inilah makna pay-as-you-go — bayar hanya untuk yang kalian pakai. Kalau beban aplikasi turun, biaya ikut turun. Kalau traffic naik, kapasitas naik otomatis. Bandingkan:

Contoh konkret: aplikasi e-commerce yang melonjak 20 kali lipat saat flash sale. Di on-premise, tim IT harus membeli server ekstra jauh hari sebelumnya — dan server itu menganggur selama 11 bulan berikutnya. Di cloud, kapasitas bertambah dalam hitungan menit saat lonjakan tiba, lalu menyusut kembali — dan tagihan mengikuti: mahal saat lonjakan, murah setelahnya.

Aspek	On-premise (CapEx)	Cloud (OpEx)
Pembayaran	Di muka, besar	Per pemakaian, kecil
Kapasitas	Fixed, over-provision	Elastic, sesuai beban
Siklus provisioning	Minggu sampai bulan	Menit
Risiko hardware obsolete	Ditanggung sendiri	Ditanggung penyedia
Skala ekonomi	Terbatas per perusahaan	Raksasa, dibagi jutaan pelanggan

Tip

Perhatikan kata "elastis" — ini jembatan antara karakteristik NIST dan model biaya. Elastisitas bukan cuma soal kapasitas teknis, tapi juga soal uang: kapasitas yang menyusut otomatis berarti tagihan yang menyusut otomatis.

#Perjalanan Evolusi Sekilas

Era	Teknologi	Masalah yang Dipecahkan
On-premise	Server fisik	Pemilik penuh atas infrastruktur
Colocation	Rack + daya sewa	Biaya gedung data center
Virtualisasi	VMware / KVM	Utilisasi hardware yang buruk
Cloud	API + self-service	Provisioning lambat dan biaya tinggi
Serverless	Function-as-a-Service	Mengelola server sama sekali

Setiap era memindahkan satu lapisan tanggung jawab dari kalian ke pihak lain — dan cloud meneruskan arah itu. Di episode 2, kalian akan melihat persis berapa jauh lapisan itu bisa dipindahkan.

#Penutup

Episode 1 memberikan fondasi konseptual seri ini:

On-premise bermasalah di CapEx, utilisasi, dan kecepatan; colocation hanya memindahkan masalah, virtualisasi baru memecahkannya.
AWS (2006), GCP (2008), dan Azure (2010) mengomersialkan kapasitas yang mereka miliki.
NIST mendefinisikan cloud lewat lima karakteristik: on-demand, broad access, pooling, elasticity, dan measured service.
Cloud mengubah biaya dari CapEx ke OpEx lewat pay-as-you-go.

Di episode 2, kita masuk ke bahasa operasional cloud: model layanan IaaS, PaaS, SaaS, dan FaaS, plus shared responsibility model — siapa bertanggung jawab atas apa, dan bagaimana memetakan layanan AWS, GCP, dan Azure secara sejajar.