Kapan Digunakan? #

Serverless bukan sekadar tren teknologi, melainkan sebuah paradigm shift dalam cara tim engineering membangun, menjalankan, dan menskalakan sistem. Namun, serverless bukan solusi universal. Banyak kegagalan adopsi serverless bukan disebabkan oleh teknologinya, melainkan karena dipakai pada konteks yang salah.

Artikel ini membahas kapan situasi dan kondisi paling tepat menggunakan serverless, dengan pendekatan rasional, berbasis karakteristik beban kerja, organisasi tim, serta tujuan bisnis. Fokus utama artikel ini adalah decision making, bukan sekadar definisi.

Ketika Beban Kerja Bersifat Tidak Stabil (Sporadic / Burst Traffic) #

Karakteristik Situas #

Traffic tidak konsisten
Lonjakan mendadak (burst)
Banyak waktu idle (server menganggur)

Contoh nyata:

API untuk campaign marketing
Sistem notifikasi
Webhook receiver
Backend aplikasi yang baru launching

Rasionalisasi Teknis #

Pada arsitektur tradisional (VM / container long-running):

Kapasitas harus disiapkan untuk peak load
Pada jam sepi, resource tetap dibayar

Serverless bekerja dengan prinsip:

Scale to zero
Eksekusi berbasis event

➡️ Biaya berbanding lurus dengan penggunaan aktual, bukan kapasitas yang diprediksi.

Kesimpulan: Jika traffic tidak bisa diprediksi atau jarang tapi meledak, serverless adalah pilihan rasional.

Ketika Aplikasi Bersifat Event-Driven #

Karakteristik Situasi #

Aksi dipicu oleh event, bukan request terus-menerus
Tidak membutuhkan proses yang selalu hidup

Contoh event:

File di-upload ke object storage
Message masuk ke queue
Perubahan data
Schedule / cron

Rasionalisasi Arsitektural #

Serverless (Function-as-a-Service) secara natural:

Stateless
Event-based
Short-lived execution

Membangun sistem event-driven di VM/container sering kali menghasilkan:

Service idle
Cron job kompleks
Over-engineering

➡️ Serverless menghilangkan kebutuhan service “penunggu event”.

Kesimpulan: Jika logika bisnis hanya berjalan saat event terjadi, serverless adalah native fit.

Ketika Tim Ingin Fokus ke Business Logic, Bukan Infrastruktur #

Karakteristik Tim #

Tim kecil / startup
Produk masih mencari product-market fit
Engineering bandwidth terbatas

Rasionalisasi Organisasi #

Mengelola VM / Kubernetes berarti:

Capacity planning
Patching OS
Monitoring node
Scaling strategy

Serverless menggeser tanggung jawab:

Infra → cloud provider
Tim → logic & flow bisnis

➡️ Cognitive load engineer menurun drastis.

Kesimpulan: Jika value utama tim adalah kecepatan eksperimen, serverless lebih rasional dibanding infra-heavy stack.

Ketika Time-to-Market Lebih Penting daripada Optimalisasi Biaya Jangka Panjang #

Karakteristik Produk #

MVP
Proof of Concept
Internal tools
Feature eksperimen

Rasionalisasi Strategis #

Serverless memungkinkan:

Deploy cepat
Setup minimal
Tidak perlu provisioning

Trade-off:

Biaya per request bisa lebih mahal di skala besar
Vendor lock-in

Namun: ➡️ Biaya delay produk sering lebih mahal daripada biaya cloud.

Kesimpulan: Saat kecepatan lebih penting dari efisiensi maksimal, serverless adalah keputusan logis.

Ketika Beban Kerja Bersifat Highly Parallel #

Karakteristik Workload #

Banyak task kecil
Independen satu sama lain
Bisa dijalankan paralel

Contoh:

Image/video processing
Data transformation
Fan-out/fan-in workload

Rasionalisasi Teknis #

Serverless:

Autoscaling instan
Ribuan eksekusi paralel
Tanpa orchestration manual

Menggunakan VM:

Perlu worker pool
Queue management
Scaling logic

➡️ Serverless menang di orchestration by default.

Kesimpulan: Jika workload bisa diparalelkan, serverless memberikan leverage besar.

Ketika Reliability Lebih Penting daripada Kontrol Infrastruktur #

Karakteristik Kebutuhan #

High availability
Toleransi terhadap failure
Minimal ops overhead

Rasionalisasi Reliability #

Cloud provider serverless:

Built-in multi-AZ
Automatic restart
Managed scaling

Mengimplementasikan reliability setara di VM:

Load balancer
Auto-scaling group
Health check
Failover logic

➡️ Serverless memberikan enterprise-grade reliability tanpa kompleksitas.

Kesimpulan: Jika reliability ingin dicapai tanpa membangun sistem HA sendiri, serverless masuk akal.

Ketika Sistem Bersifat Modular dan Tersegmentasi #

Karakteristik Arsitektur #

Microservices
Domain-driven design
Bounded context jelas

Rasionalisasi Desain #

Serverless mendorong:

Small functions
Clear input-output
Loose coupling

Namun buruk untuk:

Monolith besar
Shared mutable state

➡️ Serverless memaksa disiplin arsitektur.

Kesimpulan: Jika sistem sudah atau ingin modular, serverless memperkuat desain tersebut.

Ketika Biaya Idle Harus Dihilangkan #

Masalah Umum VM/Container #

Server hidup 24/7
Utilisasi rendah
Cost tidak sebanding usage

Rasionalisasi Finansial #

Serverless:

Tidak ada biaya idle
Bayar per eksekusi

Cocok untuk:

Admin tools
API internal
Sistem yang jarang diakses

Kesimpulan: Jika idle cost terasa menyakitkan, serverless adalah solusi langsung.

Kapan Serverless BUKAN Pilihan Tepat (Sebagai Penyeimbang) #

Agar rasional, penting menyebut batasan:

Long-running process
Low-latency ekstrem
Stateful workload
Beban konstan tinggi
Kebutuhan kontrol OS/networking

Pada kondisi ini, container atau VM lebih tepat.

Penutup #

Serverless bukan tentang menghilangkan server, tetapi tentang:

Menghilangkan decision fatigue yang tidak perlu
Mengoptimalkan fokus engineering
Menyelaraskan teknologi dengan konteks bisnis

Keputusan menggunakan serverless harus didasarkan pada:

Pola workload
Struktur tim
Fase produk
Prioritas bisnis

Jika digunakan pada konteks yang tepat, serverless bukan hanya efisien— ia menjadi akselerator strategi engineering.

Engineering yang baik bukan memilih teknologi paling canggih, tetapi teknologi paling tepat untuk konteksnya.