Penggunaan Layanan #

Setelah memahami IaaS, PaaS, SaaS, dan FaaS secara individual, pertanyaan yang lebih sulit muncul: kapan menggunakan yang mana? Tidak ada jawaban tunggal yang benar untuk semua situasi. Model layanan yang tepat bergantung pada sifat workload, ukuran tim, kebutuhan kontrol, dan prioritas bisnis. Artikel ini menyediakan kerangka berpikir untuk membuat keputusan tersebut secara sistematis.

Perbandingan Empat Model Sekaligus #

Sebelum masuk ke decision framework, mari lihat empat model secara berdampingan di dimensi yang paling penting.

Prinsip Utama — Pilih Abstraksi Setinggi Mungkin #

Sebelum masuk ke decision tree, ada satu prinsip yang harus jadi default: pilih model layanan dengan abstraksi tertinggi yang masih memenuhi kebutuhanmu.

// ANTI-PATTERN: Default ke IaaS untuk semua hal
"Kita butuh database"
  → Buat VM, install PostgreSQL, konfigurasi replikasi sendiri

"Kita butuh message queue"
  → Buat VM, install RabbitMQ, kelola cluster sendiri

"Kita butuh deploy web app"
  → Buat VM, install Nginx, konfigurasi reverse proxy sendiri

Akibat:
  → Tim ops kelelahan kelola infrastruktur
  → Banyak waktu untuk maintenance, sedikit untuk produk
  → Attack surface lebih luas

// BENAR: Gunakan managed service jika tersedia
"Kita butuh database"
  → Pakai managed database (DBaaS)
  → Backup otomatis, failover otomatis, patching otomatis

"Kita butuh message queue"
  → Pakai managed message queue
  → Tidak ada cluster yang perlu dikelola

"Kita butuh deploy web app"
  → Pakai container PaaS atau App Platform
  → Push kode, siap jalan

Resistensi terhadap prinsip ini biasanya datang dari “tapi kita tidak punya kontrol penuh” atau “managed service lebih mahal”. Kedua argumen ini valid tapi sering dilebih-lebihkan. Nilai dari kontrol yang jarang dibutuhkan biasanya lebih rendah dari biaya waktu yang dihabiskan untuk maintenance.

Decision Tree #

Gunakan alur berikut untuk menentukan model layanan yang paling tepat untuk setiap komponen sistem kamu.

Mulai
  │
  ▼
Apakah ini software yang sudah ada (email, CRM, collaboration)?
  │
  ├── Ya → Pertimbangkan SaaS
  │          Cek: compliance OK? Data sensitivity OK? Harga OK?
  │          Jika semua OK → pakai SaaS
  │
  └── Tidak (custom software) → lanjut
          │
          ▼
        Apakah workload dipicu event dan berjalan singkat?
          │
          ├── Ya → Pertimbangkan FaaS/Serverless
          │          Cocok jika: idle time tinggi, stateless,
          │          tidak butuh latensi konsisten sangat rendah
          │
          └── Tidak → lanjut
                  │
                  ▼
                Apakah butuh akses atau konfigurasi OS secara langsung?
                  │
                  ├── Ya → IaaS (VM)
                  │         Butuh keahlian ops yang cukup
                  │
                  └── Tidak → PaaS / Managed Services
                              Pilih level PaaS sesuai komponen:
                              - Web app / API → App Platform / Container PaaS
                              - Database → DBaaS
                              - Cache → Managed cache
                              - Storage → Object / Block / File storage

Skenario dan Rekomendasi #

Skenario 1 — Startup dengan Tim Kecil #

Konteks:
  Tim: 3–5 developer, 0 ops dedicated
  Produk: Web app + REST API + Database
  Prioritas: Ship fast, minimize maintenance

Rekomendasi:
  Web app + API  → Container PaaS atau App Platform
  Database       → Managed relational database (DBaaS)
  Storage        → Object storage (managed)
  Auth           → Identity service atau SaaS (Auth0, dll)
  Email          → SaaS (SendGrid, Mailgun, dll)

  Alasan: Tim tidak punya kapasitas untuk kelola infrastruktur.
  Setiap jam yang dihabiskan untuk maintenance OS adalah jam
  yang tidak dihabiskan untuk membangun produk.

Skenario 2 — Enterprise dengan Aplikasi Legacy #

Konteks:
  Tim: enterprise besar, ada tim ops
  Produk: Aplikasi legacy yang butuh dimigrasi ke cloud
  Prioritas: Migrasi cepat, risiko rendah

Rekomendasi:
  Fase 1 → Rehost ke IaaS (lift-and-shift)
             Pindahkan VM ke cloud, minimal perubahan
             Manfaat: cloud billing, tidak perlu hardware sendiri

  Fase 2 → Replatform komponen yang mudah
             Database → migrasi ke DBaaS
             File storage → migrasi ke object storage

  Fase 3 → Refactor bertahap
             Pecah monolith jika memungkinkan
             Tambahkan elasticity dan managed services

  Alasan: Migrasi langsung ke full PaaS dari legacy app
  terlalu berisiko. Bertahap adalah pendekatan yang lebih aman.

Skenario 3 — Platform Data dan Analytics #

Konteks:
  Tim: data engineers dan data scientists
  Produk: Pipeline data, ML training, BI dashboards
  Prioritas: Fleksibilitas komputasi, biaya efisien

Rekomendasi:
  Data ingestion    → Managed message queue / event stream
  Data storage      → Object storage (data lake)
  Data processing   → Managed Spark / managed ETL service
  ML training       → Managed ML platform (dengan GPU instances)
  Serving model     → Container atau FaaS tergantung traffic pattern
  BI dashboard      → SaaS BI tool atau managed service

  Alasan: Workload data sangat cocok dengan managed services —
  processing yang intermittent, storage yang besar, dan
  kebutuhan compute yang sangat fluktuatif.

Jangan Terjebak Satu Model untuk Semua #

Kesalahan umum adalah memilih satu model layanan dan menerapkannya ke seluruh sistem. Arsitektur yang baik biasanya menggunakan campuran model layanan yang berbeda untuk komponen yang berbeda.

Contoh Arsitektur Hybrid yang Wajar:

  Web frontend          → CDN + Object storage (konten statis)
  API backend           → Container PaaS
  Authentication        → Identity SaaS
  Database utama        → Managed relational DB (DBaaS)
  Cache                 → Managed in-memory cache
  File upload processing → FaaS (trigger saat file baru)
  Email notifications   → Email SaaS
  Analytics             → SaaS BI tool
  Background jobs berat → IaaS (VM) untuk kontrol penuh
  Monitoring            → Observability SaaS

Setiap komponen dipilih berdasarkan kebutuhan spesifiknya, bukan karena “kita pakai satu model saja untuk konsistensi.”

Ringkasan #

• Default ke abstraksi tertinggi yang memenuhi kebutuhan — mulai dari SaaS atau managed service, turun ke IaaS hanya jika ada alasan konkret.
• Tidak ada satu model untuk semua komponen — sistem yang baik biasanya campuran IaaS, PaaS, FaaS, dan SaaS sesuai kebutuhan masing-masing komponen.
• FaaS ideal untuk workload event-driven dengan idle time tinggi — bayar per eksekusi, bukan per jam server berjalan.
• PaaS mengurangi beban ops secara signifikan — developer fokus ke kode bisnis, bukan maintenance infrastruktur.
• IaaS tetap relevan untuk workload yang butuh kontrol OS — atau sebagai langkah pertama migrasi legacy application.
• SaaS adalah pilihan terbaik untuk fungsi commodity — tidak ada nilai kompetitif dalam membangun email server atau project management sendiri.
• Evaluasi vendor lock-in sebagai bagian dari keputusan — semakin tinggi abstraksi, semakin tinggi lock-in. Pertimbangkan ini sesuai toleransi kamu.

← Sebelumnya: SaaS   Berikutnya: Public Cloud →