Belajar Cloud Engineer - Storage & Database Services

#Pendahuluan

Setelah di episode 3 kalian berhasil membuat VM dan men-deploy function serverless, pertanyaan berikutnya selalu: "data-nya disimpan di mana?" Semua aplikasi membutuhkan tempat penyimpanan — dan kesalahan paling mahal di cloud justru sering terjadi di lapisan ini: data hilang, biaya storage membengkak, atau database yang dipilih ternyata tidak cocok untuk workload.

Episode 4 membahas storage dan database services — dua domain yang sering dicampur jadi satu padahal sangat berbeda. Kalian akan memahami empat jenis storage (object, block, file, archive) dan dua keluarga database (relasional managed & NoSQL), lalu merancang arsitektur storage + database untuk satu aplikasi nyata.

#Empat Jenis Storage Cloud

#Object Storage (S3 / Cloud Storage / Blob)

Object storage menyimpan file sebagai objek dalam bucket, diakses via API HTTP, dengan kapasitas yang praktis tanpa batas. Ini adalah penyimpanan paling penting di dunia cloud — untuk file statis website, upload user, backup, log, dan data lake.

aws s3api create-bucket \
  --bucket lab-$(whoami)-backup \
  --region ap-southeast-1 \
  --create-bucket-configuration LocationConstraint=ap-southeast-1
aws s3 cp ./laporan.pdf s3://lab-$(whoami)-backup/
aws s3 ls s3://lab-$(whoami)-backup/

Konsep kunci object storage:

• Bucket = wadah top-level; object = file + metadata; key = path unik di dalam bucket.
• Versi (versioning) bisa diaktifkan untuk menjaga riwayat — dasar strategi backup episode 20.
• Lifecycle policy — aturan otomatis memindahkan objek antar tier penyimpanan atau menghapusnya setelah waktu tertentu.
• Durability sangat tinggi (11 9s di S3) — data disalin redundan ke beberapa AZ.

#Block Storage (EBS / Persistent Disk / Managed Disk)

Block storage adalah disk mentah yang dipasang ke VM — seperti hard disk internal. Dipakai untuk OS dan database yang butuh latency rendah. Harus di-attach ke instance; berdiri sendiri ia tidak berguna.

aws ec2 create-volume \
  --availability-zone ap-southeast-1a \
  --size 10 \
  --volume-type gp3
aws ec2 attach-volume --volume-id vol-0abc --instance-id i-0def --device /dev/sdf

#File Storage (EFS / Filestore / Azure Files)

File storage menyediakan filesystem bersama yang bisa di-mount ke banyak VM sekaligus (protocol NFS/SMB). Cocok untuk web farm yang berbagi konten, aplikasi legacy, atau home directory.

#Archive Storage (Glacier / Coldline/Archive / Archive tier)

Untuk data yang jarang diakses tapi wajib disimpan (backup lama, data regulasi). Murah, tapi ada biaya dan waktu untuk mengambil kembali data. Lifecycle policy otomatis memindahkan objek ke tier ini.

#Managed Database Relasional (RDS / Cloud SQL / Azure SQL)

Saat aplikasi butuh transaksi dengan skema tetap (user, order, payment), kita pakai database relasional. Cloud menghilangkan pekerjaan admin database: provisioning, patching, backup, dan failover ditangani provider.

gcloud sql instances create lab-db \
  --database-version=POSTGRES_15 \
  --tier=db-f1-micro \
  --region=asia-southeast2 \
  --backup-start-time=02:00
gcloud sql databases create app --instance=lab-db

Mengapa pilih managed DB daripada install PostgreSQL sendiri di VM? Karena di managed DB, high availability, backup, dan patching jadi tanggung jawab provider — kalian cukup memakai connection string-nya. Ini persis contoh shared responsibility yang kita bahas di episode 1.

#Database NoSQL (DynamoDB / Firestore / Cosmos DB)

Untuk workload dengan skema fleksibel, skala massive, atau akses key-value yang super cepat, pakai NoSQL:

Contoh di DynamoDB — NoSQL beda cara berpikir: kalian tidak "query fleksibel", kalian mendesain akses pattern (partition key + sort key) lebih dulu:

Partition key: customerId (string)
Sort key:     orderDate (string, ISO date)
 
Akses yang didukung desain ini:
- semua order per customer  → Query(partition key)
- order per customer per hari → Query(partition key + sort key prefix)
- cari order global          → BUTUH Scan (mahal!) — hindari

Kapan pilih NoSQL vs relasional? Jika workload-nya transaksional dan butuh JOIN/ACID ketat, pakai relasional. Jika skalanya raksasa dan akses pattern sudah jelas (contoh session store, katalog produk, event log), NoSQL menang. Kesalahan umum: memakai NoSQL karena "keren" padahal aplikasi hanya butuh 3 tabel dengan relasi — akhirnya memodelkan ulang di SQL.

#Latihan: Merancang Arsitektur Storage + Database

Aplikasi nyata: layanan upload foto profil yang dipakai jutaan user. Rancang lapisan datanya:

Arsitektur yang disarankan:

1. Foto disimpan di object storage (S3/GCS/Blob) — murah, scalable, langsung bisa disajikan via CDN.
2. Metadata (user, URL foto, ukuran) di managed relasional atau NoSQL — pilih berdasarkan kebutuhan query.
3. Cache/thumbnails dihasilkan lewat function serverless yang terpicu upload (ini jadi jembatan ke episode 11).
4. Backup: versioning object storage diaktifkan, snapshot DB otomatis.

Kerjakan pemetaannya sendiri di ketiga provider, catat nama layanan masing-masing lapisan, lalu bandingkan. Latihan seperti inilah yang melatih naluri arsitektur cloud.

#Penutup

Inti yang harus dibawa pulang:

• Empat jenis storage: object (file tanpa batas), block (disk VM), file (shared filesystem), archive (jarang diakses, murah).
• Lifecycle policy mengotomasi pemindahan data antar tier dan menghapus data tua otomatis.
• Managed DB (RDS/Cloud SQL/Azure SQL) menghilangkan pekerjaan admin database; backup dan HA jadi tugas provider.
• NoSQL (DynamoDB/Firestore/Cosmos) menang untuk skala raksasa dengan akses pattern jelas — desain key-nya dulu, baru buat tabel.
• Arsitektur data yang baik selalu dimulai dari bagaimana data diakses, bukan dari "database mana yang paling populer".

Di episode 5 selanjutnya kita akan membahas networking cloud — VPC, subnet, security group/firewall rules, NAT, peering, dan load balancer, lalu mendesain VPC multi-tier untuk aplikasi web production. Sampai jumpa di episode 5!