Object Storage #
Object storage adalah jenis penyimpanan yang paling identik dengan cloud — dan seringkali yang paling sering digunakan. Ia menyimpan data sebagai “objek” yang terdiri dari data itu sendiri, metadata, dan identifier unik. Tidak ada hierarki folder seperti di filesystem, tidak ada block yang perlu di-format. Kamu simpan objek, kamu ambil objek, menggunakan API HTTP yang sederhana. Skala object storage hampir tidak terbatas, dan ia adalah fondasi untuk hampir semua workload data di cloud — dari backup hingga data lake, dari hosting static website hingga distribusi media.
Cara Kerja Object Storage #
Object storage berbeda secara fundamental dari cara filesystem tradisional bekerja.
Filesystem Tradisional:
/data/
├── users/
│ ├── profile-123.jpg
│ └── profile-456.jpg
└── reports/
└── 2024-q4.pdf
Akses: path hierarkis seperti direktori
Modifikasi: bisa edit file di tempat (seek, write, seek)
Object Storage:
Bucket: my-app-storage
├── users/profile-123.jpg ← terlihat seperti path, tapi
├── users/profile-456.jpg sebenarnya hanya "key" (nama objek)
└── reports/2024-q4.pdf ← slash hanya bagian dari nama,
bukan direktori nyata
Akses: HTTP API (GET, PUT, DELETE)
Modifikasi: tidak bisa edit — harus upload ulang objek baru
Setiap objek terdiri dari:
→ Data (bytes — bisa apa saja)
→ Key (identifier unik dalam bucket)
→ Metadata (content-type, ukuran, custom metadata)
→ Version ID (jika versioning aktif)
Karakteristik Kunci Object Storage #
Flat Namespace #
Object storage tidak punya direktori nyata — hanya key strings.
"Folder" yang kamu lihat di console adalah ilusi dari prefix.
Key: "users/profile-123.jpg"
Key: "users/profile-456.jpg"
Key: "reports/2024-q4.pdf"
Jika kamu list dengan prefix "users/":
→ Hasilnya: profile-123.jpg, profile-456.jpg
→ Tapi "users/" bukan direktori — hanya filter berdasarkan prefix key
Implikasi:
✓ Tidak ada operasi "rename folder" yang mahal
✓ Tidak ada overhead direktori — bisa simpan miliaran objek
✗ List objects lebih lambat dari filesystem untuk banyak objek
✗ Tidak bisa rename objek langsung (harus copy + delete)
Eventual Consistency vs Strong Consistency #
Catatan penting tentang consistency:
Strong consistency (standar modern):
→ PUT objek → langsung bisa GET objek terbaru
→ Sebagian besar provider besar sudah menjamin ini
→ Perilaku yang diharapkan untuk kebanyakan use case
Eventual consistency (model lama, masih ada di beberapa kasus):
→ PUT objek → mungkin butuh beberapa milidetik/detik untuk propagasi
→ Biasanya hanya relevan untuk overwrite dan delete di beberapa provider
→ Cek dokumentasi provider yang kamu gunakan
Dalam praktik:
Untuk sebagian besar workload, kamu tidak akan merasakan perbedaannya.
Yang penting: jangan design sistem yang depend on reading
immediately after write di lingkungan yang belum confirmed consistency.
Durability Tinggi #
Object storage dirancang untuk durability ekstrem:
→ Data direplikasi ke beberapa AZ secara otomatis
→ Durability tipikal: 99.999999999% (11 nines)
→ Artinya: menyimpan 10 juta objek, ekspektasi kehilangan
satu objek setiap 10.000 tahun
Ini bukan berarti kamu tidak perlu backup:
✓ Durability melindungi dari hardware failure
✗ Tidak melindungi dari: hapus tidak sengaja, aplikasi bug
yang overwrite data, atau ransomware
→ Versioning + lifecycle policy + cross-region replication
untuk proteksi yang lebih komprehensif
Fitur-Fitur Penting Object Storage #
Versioning #
Versioning menyimpan semua versi objek yang pernah ada.
Upload "report.pdf" (v1)
Upload "report.pdf" lagi (v2) — v1 tetap ada
Upload "report.pdf" lagi (v3) — v1 dan v2 tetap ada
Kegunaan:
✓ Restore jika file dihapus tidak sengaja
✓ Audit trail — lihat riwayat perubahan
✓ Proteksi dari ransomware (tidak bisa hapus semua versi sekaligus)
✗ Biaya storage meningkat (semua versi disimpan)
→ Kombinasikan dengan lifecycle rule untuk hapus versi lama
Access Control #
Kontrol akses object storage:
Bucket Policy (level bucket):
→ Aturan JSON yang mengontrol siapa boleh akses bucket
→ Bisa izinkan akses publik atau terbatas
ACL per Objek:
→ Kontrol akses per-objek individual
→ Umumnya tidak disarankan — bucket policy lebih mudah dikelola
Pre-signed URL:
→ URL sementara yang mengizinkan akses ke objek private
→ Kamu generate URL dengan expiry time
→ Bagikan ke pihak lain — mereka bisa download tanpa credentials
→ Berguna untuk: berbagi file sementara, upload dari client browser
Contoh pre-signed URL use case:
User minta download laporan → backend generate pre-signed URL
(berlaku 15 menit) → redirect user ke URL tersebut
User download langsung dari object storage tanpa lewat backend
Static Website Hosting #
Object storage bisa serve static website langsung:
Upload: index.html, style.css, app.js, gambar-gambar
Enable static website hosting pada bucket
Set bucket sebagai public read
→ Bucket serve file via HTTP/HTTPS
→ Tidak butuh server apapun
→ Biaya sangat murah (hanya bayar storage + request)
→ Kombinasikan dengan CDN untuk distribusi global
Cocok untuk:
✓ Single Page Application (React, Vue, Angular hasil build)
✓ Landing page statis
✓ Dokumentasi
✗ Tidak cocok untuk server-side rendering atau dynamic content
Use Case Object Storage #
Cocok untuk:
✓ Backup dan archive
→ Murah, durable, bisa di-tier ke storage lebih murah lagi
✓ Media storage (gambar, video, audio)
→ Serve langsung ke user via CDN
→ Skala hampir tidak terbatas
✓ Data lake dan analytics
→ Simpan raw data dalam jumlah besar
→ Format: Parquet, CSV, JSON, Avro
→ Query langsung dengan serverless analytics engine
✓ Log dan event data
→ Aggregate logs dari banyak sumber ke satu tempat
→ Murah untuk retention jangka panjang
✓ Artifact dan deployment
→ Container images (bisa, tapi ada dedicated registry)
→ Build artifacts, release packages
✓ Static website dan CDN origin
→ Hosting file statis yang langsung di-serve ke user
Tidak cocok untuk:
✗ Database — tidak ada query capability native
✗ File yang perlu sering dimodifikasi sebagian (partial write)
✗ Aplikasi yang butuh filesystem semantics (lock, seek, in-place edit)
✗ Workload yang sangat latency-sensitive (block storage lebih baik)
Ringkasan #
- Object storage menyimpan data sebagai objek dengan key unik — tidak ada direktori nyata, hanya flat namespace dengan prefix sebagai ilusi folder.
- Tidak bisa edit objek di tempat — harus upload ulang seluruh objek; ini adalah trade-off untuk durability dan skalabilitas.
- Durability 11 nines bukan berarti tidak perlu backup — ia melindungi dari hardware failure, bukan dari hapus tidak sengaja atau bug aplikasi.
- Versioning + lifecycle policy = proteksi data yang komprehensif — simpan semua versi untuk recovery, hapus versi lama secara otomatis untuk kontrol biaya.
- Pre-signed URL untuk berbagi file private sementara — generate URL dengan expiry tanpa perlu membuat objek menjadi public.
- Object storage adalah fondasi data lake dan analytics — simpan data mentah dalam format terbuka, query dengan serverless engine sesuai kebutuhan.