Problem yang Diselesaikan #

Memahami masalah yang dipecahkan cloud lebih penting dari sekadar menghafal fitur-fiturnya. Ketika kamu tahu mengapa suatu fitur ada, kamu bisa menggunakannya dengan tepat — bukan hanya karena tersedia. Bagian ini membahas masalah nyata yang dihadapi organisasi sebelum cloud ada, dan bagaimana cloud mengatasinya secara langsung.

Capacity Planning yang Tidak Pernah Tepat #

Ini adalah masalah paling fundamental di era infrastruktur tradisional. Organisasi harus memutuskan berapa banyak server yang dibutuhkan — jauh sebelum beban aktual diketahui.

Dilema Capacity Planning Tradisional:

  Skenario A — Over-provisioning:
    Beli 100 server untuk antisipasi beban puncak
    Beban aktual rata-rata hanya butuh 30 server
    → 70 server menganggur, biaya tetap berjalan
    → Utilisasi rata-rata: 15–20%

  Skenario B — Under-provisioning:
    Beli 30 server sesuai beban normal
    Saat event besar / lonjakan trafik
    → Server kehabisan kapasitas
    → Layanan lambat atau mati
    → Revenue hilang, reputasi rusak

  Tidak ada skenario C yang mudah di era tradisional.

Cloud memecahkan ini dengan elastisitas. Kapasitas bisa disesuaikan dengan beban aktual, bukan proyeksi. Organisasi tidak lagi dipaksa memilih antara boros atau rapuh.

Waktu Pengadaan yang Menghambat Inovasi #

Di era tradisional, menambah kapasitas bukan soal klik tombol. Ada proses panjang yang melibatkan banyak pihak.

Proses Pengadaan Server Tradisional:
  1. Engineer identifikasi kebutuhan
  2. Ajukan purchase request ke procurement
  3. Approval dari manager → finance → IT security
  4. Tender / negosiasi vendor
  5. Purchase order dikirim
  6. Vendor proses dan kirim hardware (2–8 minggu)
  7. Hardware diterima, dicek, di-rack
  8. OS dan software diinstall, dikonfigurasi
  9. Jaringan dan storage dikonfigurasi
  10. Testing dan handover ke tim aplikasi

Total waktu: 4–12 minggu, kadang lebih

Cloud:
  Engineer buka console atau jalankan terraform apply
  → Infrastruktur siap dalam 2–10 menit

Waktu pengadaan yang lama bukan hanya masalah kecepatan teknis — ia menghambat kemampuan organisasi untuk bereksperimen, merespons peluang, dan berinovasi. Tim yang menunggu 8 minggu untuk mendapat server tidak bisa bergerak secepat kompetitor yang bisa spin up infrastruktur dalam menit.

Beban Capital Expenditure #

Infrastruktur tradisional membutuhkan investasi besar di muka sebelum menghasilkan nilai apa pun. Ini adalah hambatan serius, terutama untuk startup dan proyek baru.

Model CapEx Tradisional:
  Tahun 0: Beli server, storage, network equipment → Rp 5 miliar
  Tahun 0: Bangun/sewa data center space           → Rp 2 miliar
  Tahun 0: Pengkabelan, instalasi, commissioning   → Rp 1 miliar
  ─────────────────────────────────────────────────────────────
  Total sebelum satu baris kode berjalan di produksi: Rp 8 miliar

  Dan hardware punya lifecycle — dalam 3–5 tahun, perlu refresh lagi.

Model OpEx Cloud:
  Bulan 1: Bayar hanya untuk resource yang dipakai
  Skala naik saat tumbuh, skala turun saat sepi
  Tidak ada komitmen jangka panjang untuk hardware
  → Modal bisa dialokasikan untuk pengembangan produk

Pergeseran dari CapEx ke OpEx ini secara langsung mengubah dinamika finansial bisnis — terutama startup yang tidak ingin menghabiskan modal awal untuk infrastruktur sebelum product-market fit tercapai.

Overhead Operasional yang Menguras Fokus #

Mengelola data center bukan hanya soal server. Ada ekosistem panjang yang harus dikelola dan semua itu membutuhkan tenaga, keahlian, dan waktu.

Yang Harus Dikelola di On-Premise:
  Hardware:
    □ Server, storage, network switches, load balancer
    □ Hardware failure — disk mati, RAM rusak, power supply
    □ Hardware refresh cycle setiap 3–5 tahun

  Fasilitas:
    □ Power — UPS, generator, redundansi listrik
    □ Cooling — pendingin ruangan, monitoring suhu
    □ Physical security — akses kontrol, CCTV, kunci rack
    □ Fire suppression

  Software & OS:
    □ OS patching dan update
    □ Security vulnerability monitoring
    □ Lisensi software

  Semua ini = tim yang besar dan biaya yang terus-menerus
  Semua ini = fokus yang tidak ke produk utama bisnis

Cloud mengambil alih hampir semua tanggung jawab ini melalui model shared responsibility. Organisasi bisa fokus pada layer yang paling dekat dengan nilai bisnisnya.

Skalabilitas Geografis yang Mahal #

Melayani pengguna di berbagai region secara tradisional berarti membangun atau menyewa data center di setiap lokasi — investasi besar dan kompleksitas operasional yang berlipat ganda.

Ekspansi Geografis Tradisional:
  Melayani Indonesia + Singapura + Jepang:
  → Bangun/sewa 3 data center terpisah
  → Tim operasional di setiap lokasi
  → Replikasi data antar lokasi (custom solution)
  → Waktu: 6–18 bulan, biaya: sangat besar

Ekspansi Geografis dengan Cloud:
  Melayani Indonesia + Singapura + Jepang:
  → Pilih 3 region di console cloud provider
  → Deploy infrastructure-as-code ke 3 region
  → Built-in tools untuk replikasi dan routing
  → Waktu: hari hingga minggu

Cloud provider sudah membangun infrastruktur global. Organisasi tinggal memilih region mana yang ingin digunakan — tanpa perlu investasi fisik di setiap lokasi.

Keterbatasan Disaster Recovery #

Membangun disaster recovery (DR) yang solid di era tradisional adalah proyek besar tersendiri — membutuhkan data center kedua, replikasi data, dan latihan failover yang rumit.

DR Tradisional:
  Primary DC ──── replikasi manual ────→ Secondary DC
  
  Tantangan:
  ✗ Biaya double — bayar dua data center meski secondary jarang dipakai
  ✗ Konfigurasi replikasi yang kompleks dan rawan error
  ✗ RPO (Recovery Point Objective) dan RTO (Recovery Time Objective)
    sulit dijamin tanpa testing rutin yang mahal
  ✗ Testing failover bisa ganggu operasional

DR dengan Cloud:
  ✓ Multi-AZ deployment built-in untuk availability zone failure
  ✓ Cross-region replication untuk regional disaster
  ✓ Snapshot dan backup otomatis
  ✓ Infrastructure-as-code → DR environment bisa di-recreate
    dari kode, bukan dari dokumentasi manual

Ringkasan #

Capacity planning tradisional selalu salah — either over-provisioning (boros) atau under-provisioning (rapuh). Cloud memecahkan ini dengan elastisitas real-time.
Waktu pengadaan 4–12 minggu menghambat inovasi — cloud mempersingkat ini menjadi menit. Ini bukan hanya soal kecepatan teknis, tapi kemampuan bisnis untuk bereksperimen dan bergerak.
CapEx besar di muka menguras modal — model OpEx cloud memungkinkan organisasi membayar sesuai penggunaan dan mengalokasikan modal ke hal yang lebih bernilai.
Overhead operasional data center mengalihkan fokus — cloud mengambil alih tanggung jawab hardware, fasilitas, dan sebagian OS sehingga tim bisa fokus ke produk.
Ekspansi geografis yang dulunya butuh bulan dan miliaran kini bisa dilakukan dalam hari dengan infrastruktur global yang sudah ada.
Disaster recovery menjadi lebih terjangkau — multi-AZ, cross-region replication, dan infrastructure-as-code membuat DR lebih reliable dan lebih mudah di-test.

← Sebelumnya: Evolusi Cloud Berikutnya: Mitos atau Miskonsepsi →