Kapan Digunakan? #

Serverless bukan sekadar tren teknologi atau kata kunci pemasaran yang keren. Ia mewakili sebuah pergeseran paradigma dalam cara kita membangun, menjalankan, dan menskalakan perangkat lunak. Namun, seperti halnya semua teknologi arsitektur, serverless bukanlah solusi universal untuk semua masalah. Banyak kegagalan dalam adopsi serverless terjadi bukan karena teknologi tersebut buruk, melainkan karena ia diterapkan pada konteks atau situasi yang salah.

Mengadopsi serverless membutuhkan evaluasi yang objektif terhadap kebutuhan aplikasi, pola traffic, kapabilitas tim, dan aspek finansial. Kita tidak boleh memilih serverless hanya karena ingin terlihat modern. Kita harus memilihnya karena karakteristik beban kerja aplikasi kita memang membutuhkan keunggulan yang ditawarkan oleh serverless. Artikel ini akan membedah secara pragmatis kapan kita harus menggunakan serverless dan kapan kita sebaiknya menghindarinya.

Karakteristik Workload yang Sangat Cocok #

Kunci utama keberhasilan adopsi serverless terletak pada pemetaan pola kerja (workload pattern) aplikasi kita. Ada beberapa pola beban kerja yang secara alami sangat cocok dengan model eksekusi on-demand dan event-driven khas serverless.

1. Pola Traffic Tidak Stabil (Sporadic & Burst Traffic) #

Jika aplikasi kita memiliki traffic yang sangat berfluktuasi—ramai pada jam-jam tertentu dan benar-benar sunyi pada jam lainnya—serverless adalah pilihan terbaik.

flowchart TD
    A["Traffic Masuk"] --> B{"Tipe Traffic?"}
    B -->|"Stabil / Konstan"| C["Server Tradisional / VM<br/>(Resource terpakai optimal)"]
    B -->|"Spiky / Fluktuatif"| D["Serverless<br/>(Scale-to-Zero saat sepi,<br/>instant scaling saat ramai)"]

Contoh nyata skenario ini meliputi:

• Sistem Webhook Pembayaran: Webhook dari payment gateway hanya masuk ketika ada transaksi sukses. Transaksi bisa sangat ramai pada siang hari dan hampir nol pada pukul 2 malam.
• Aplikasi Kampanye Pemasaran (Marketing Campaign): Situs mikro yang dibuat khusus untuk promosi musiman (seperti flash sale) yang diserbu ribuan pengguna dalam waktu 10 menit, kemudian sepi selama berbulan-bulan.
• Endpoint Notifikasi: Mengirim email atau pesan push secara massal pada waktu-waktu tertentu.

2. Pipeline Pemrosesan Data Berbasis Event (Event-Driven Pipeline) #

Dalam arsitektur event-driven, serverless bertindak sebagai pelaksana tugas asinkron yang sangat efisien. Ketika ada suatu kejadian (event) di dalam sistem, platform cloud akan memicu fungsi serverless untuk memprosesnya.

flowchart LR
    Upload["User mengunggah file ke Storage"] -->|Event: ObjectCreated| Trigger["Platform Cloud memicu Function"]
    Trigger -->|Proses| Action1["Resize Gambar"]
    Trigger -->|Proses| Action2["Ekstrak Metadata"]
    Trigger -->|Proses| Action3["Simpan Log ke DB"]

Pola ini sangat efisien karena kita tidak perlu menjalankan server virtual 24/7 hanya untuk menunggu user mengunggah file. Fungsi hanya menyala, memproses file selama beberapa detik, lalu mati kembali.

3. Pekerjaan Latar Belakang Terjadwal (Scheduled Background Jobs / Cron) #

Banyak aplikasi memiliki tugas berkala seperti menghasilkan laporan harian setiap pukul 12 malam, melakukan sinkronisasi database setiap jam, atau membersihkan data sampah (garbage collection) mingguan.

Menyewa VM khusus untuk tugas-tugas terjadwal ini adalah pemborosan besar karena server akan menganggur selama lebih dari 95% waktunya. Dengan serverless, kita dapat mengonfigurasi pemicu waktu (Cron schedule) untuk menjalankan fungsi pada waktu yang ditentukan dan hanya membayar untuk durasi singkat saat laporan tersebut dibuat.

Evaluasi Finansial dan TCO (Total Cost of Ownership) #

Saat membandingkan biaya serverless dengan server tradisional (IaaS/VM), kita sering terjebak hanya pada perbandingan nominal tagihan komputasi mentah. Ini adalah kesalahan besar. Kita harus menghitung Total Cost of Ownership (TCO), yang mencakup biaya operasional, waktu kerja tim, dan efisiensi resource.

Perbandingan Skenario Biaya: VM vs. Serverless #

Mari kita lakukan simulasi perbandingan biaya antara menyewa VM Virtual Private Server (VPS) berspesifikasi sedang seharga $40/bulan dengan menggunakan layanan komputasi serverless (seperti AWS Lambda atau Google Cloud Run) untuk skenario traffic yang berbeda.

Mengapa Serverless Bisa Lebih Murah? #

• Menghilangkan Biaya Idle: Kita tidak pernah membayar untuk CPU dan RAM yang menganggur.
• Mereduksi Biaya Manajemen (Ops Cost): Kita tidak perlu menyewa insinyur DevOps khusus untuk memantau OS, mengonfigurasi patching keamanan, atau mengelola kluster Kubernetes. Waktu yang dihemat oleh tim engineering untuk mengurus infrastruktur bernilai ribuan dolar.

Aspek Organisasional dan Kecepatan Tim #

Pilihan teknologi tidak hanya berdampak pada performa aplikasi, tetapi juga pada produktivitas dan struktur tim pengembang kita.

1. Keuntungan untuk Tim Kecil dan Startup #

Bagi startup atau tim kecil dengan jumlah engineer terbatas, beban mengelola server bisa menjadi beban kognitif yang melumpuhkan. Tim harus membagi fokus antara menulis fitur produk dengan mengamankan server.

Fokus Tim Tanpa Serverless:
  [Menulis Fitur Bisnis: 50%] + [Mengelola Server, Patch, Monitoring, OS: 50%]

Fokus Tim Dengan Serverless:
  [Menulis Fitur Bisnis: 90%] + [Konfigurasi Serverless IaC: 10%]

Dengan serverless, seluruh beban operasional tingkat rendah dialihkan ke cloud provider. Tim kecil yang terdiri dari 2-3 orang pengembang dapat meluncurkan produk berskala global dan menangani ribuan pengguna tanpa perlu merekrut DevOps engineer khusus sejak hari pertama.

2. Akselerasi Time-to-Market (TTM) #

Serverless memotong birokrasi operasional dalam penyediaan infrastruktur. Di era tradisional, membuat satu microservice baru membutuhkan koordinasi dengan tim infrastruktur untuk menyiapkan VM, mengonfigurasi IP, membuat load balancer, dan mendaftarkan DNS. Proses ini bisa memakan waktu berhari-hari.

Di ekosistem serverless, developer dapat mendefinisikan infrastruktur di dalam file konfigurasi kode (Infrastructure as Code) dan mendeploy fungsi baru dalam hitungan menit. Ini membuat siklus eksperimen, umpan balik dari pengguna, dan peluncuran fitur baru berjalan jauh lebih cepat.

Panduan Keputusan: Decision Tree #

Untuk mempermudah proses pengambilan keputusan arsitektur, kita dapat menggunakan pohon keputusan (decision tree) berikut sebelum menentukan apakah suatu layanan layak dibangun di atas serverless.

flowchart TD
    Start["Mulai Evaluasi Arsitektur"] --> Q1{"Apakah proses berjalan<br/>lebih dari 15 menit?"}
    Q1 -- "Ya" --> VM["Gunakan VM / Container Long-running<br/>(e.g., AWS EC2, ECS, GCP GCE)"]
    Q1 -- "Tidak" --> Q2{"Apakah aplikasi membutuhkan<br/>latensi ultra-rendah konsisten<br/>(sub-10ms, tanpa cold start)?"}
    
    Q2 -- "Ya" --> VM
    Q2 -- "Tidak" --> Q3{"Apakah traffic stabil<br/>dan sangat tinggi 24/7?"}
    
    Q3 -- "Ya" --> VM
    Q3 -- "Tidak" --> Q4{"Apakah tim memiliki<br/>sumber daya khusus untuk<br/>manajemen OS & network?"}
    
    Q4 -- "Tidak" --> SL["Sangat Direkomendasikan:<br/>Serverless Architecture"]
    Q4 -- "Ya" --> Q5{"Apakah ingin mengoptimalkan<br/>biaya idle dan mempercepat<br/>time-to-market?"}
    
    Q5 -- "Ya" --> SL
    Q5 -- "Tidak" --> VM

Kapan Serverless Sebaiknya Dihindari? #

Seorang insinyur perangkat lunak yang baik harus bersikap jujur mengenai kelemahan dan batasan teknologi yang digunakannya. Ada beberapa skenario kritis di mana serverless justru akan menjadi bumerang yang meningkatkan biaya operasional dan memperburuk performa sistem kita.

1. Workload yang Berjalan Terus-menerus (Long-Running Processes) #

FaaS memiliki batasan waktu eksekusi yang ketat (timeout). Sebagai contoh, AWS Lambda membatasi waktu eksekusi maksimal 15 menit per pemanggilan. Jika kita memiliki aplikasi yang melakukan komputasi berat seperti rendering video 3D, pelatihan model kecerdasan buatan (ML training), pemrosesan big data berskala besar, atau web server WebSocket yang membutuhkan koneksi persisten berjam-jam, serverless FaaS adalah pilihan yang buruk. Kita akan sering mengalami timeout dan biaya eksekusi milidetik kumulatif akan melonjak drastis melewati biaya sewa VM standar.

2. Aplikasi Sensitif Latensi (Ultra-Low Latency) #

Masalah cold start adalah karakteristik bawaan serverless. Ketika sebuah fungsi sudah lama tidak dipanggil, cloud provider akan menghancurkan kontainer penampungnya untuk menghemat resource. Saat request baru masuk, cloud provider harus menyiapkan kontainer baru, mengunduh kode, dan menginisiasi runtime. Proses inisialisasi ini bisa memakan waktu antara 200 milidetik hingga beberapa detik.

Jika aplikasi kita adalah sistem transaksi saham real-time, game multiplayer online, atau core banking API yang membutuhkan respon di bawah 20 milidetik secara konsisten, cold start serverless akan merusak pengalaman pengguna kita.

3. Workload dengan Traffic Stabil dan Sangat Tinggi #

Ketika traffic aplikasi kita sudah sangat besar, stabil, dan dapat diprediksi secara konsisten 24 jam sehari, efisiensi serverless akan hilang. Keuntungan finansial dari serverless berasal dari hilangnya biaya idle. Namun jika CPU server kita bekerja 90% sepanjang waktu tanpa ada idle, menyewa VM dengan harga flat bulanan (atau bahkan mendedikasikan hardware fisik) akan jauh lebih murah secara matematis dibandingkan membayar miliaran invokasi fungsi serverless secara retail.

Ringkasan #

• Serverless adalah pilihan terbaik untuk pola traffic yang tidak stabil (spiky), aplikasi berbasis event-driven, tugas terjadwal (cron), serta lingkungan pengujian/staging.
• TCO (Total Cost of Ownership) serverless sangat efisien untuk tim kecil dan startup karena menghilangkan biaya pemeliharaan infrastruktur dan mengeliminasi pembayaran resource idle.
• Serverless mempercepat rilis produk (Time-to-Market) dengan memungkinkan developer fokus menulis kode dan mengotomatiskan infrastruktur lewat deklarasi kode (IaC).
• Hindari serverless jika aplikasi kita menjalankan proses komputasi yang lama (> 15 menit), membutuhkan latensi ultra-rendah secara konsisten tanpa cold start, atau melayani traffic stabil berskala raksasa 24/7.
• Gunakan diagram pohon keputusan (decision tree) untuk mengevaluasi kelayakan arsitektur secara rasional sebelum melakukan migrasi infrastruktur.

← Sebelumnya: Kenapa Serverless   Berikutnya: Kasak Kusuk →