Kenapa Serverless? #

Pertanyaan “kenapa serverless?” sering muncul bukan hanya dari engineer junior, tetapi juga dari senior engineer, tech lead, bahkan CTO. Ini pertanyaan yang valid—karena serverless bukan sekadar tren, melainkan konsekuensi logis dari evolusi cara kita membangun, menjalankan, dan menskalakan sistem.

Serverless bukan berarti tidak ada server. Server tetap ada. Yang berubah adalah siapa yang bertanggung jawab terhadap server tersebut. Dalam arsitektur serverless, tanggung jawab operasional server berpindah dari tim engineering ke platform.

Artikel ini akan membahas secara mendalam kenapa serverless muncul, masalah apa yang ia selesaikan, apa keuntungan nyata (dan jebakannya), serta kapan serverless adalah pilihan rasional — dan kapan justru tidak.

Masalah Fundamental dalam Arsitektur Tradisional #

Sebelum membahas serverless, kita perlu jujur pada akar masalah yang ingin ia selesaikan.

Infrastruktur Menjadi Beban Kognitif #

Pada arsitektur tradisional (VM atau bare metal):

Provisioning server
Patch OS
Konfigurasi network
Monitoring resource
Capacity planning

Semua ini tidak berhubungan langsung dengan value bisnis, tetapi menyita waktu dan energi engineer.

Engineer dibayar untuk memecahkan masalah bisnis, bukan mengurusi kernel panic.

Over-Provisioning vs Under-Provisioning #

Provision terlalu besar → uang terbuang
Provision terlalu kecil → downtime & latency

Autoscaling membantu, tapi:

Konfigurasinya kompleks
Scaling tidak instan
Tetap perlu baseline server yang hidup 24/7

Model Biaya yang Tidak Efisien #

Pada VM atau container tradisional:

Server idle tetap bayar
Traffic sepi = tetap bayar
Jam malam = tetap bayar

Padahal banyak aplikasi:

Event-driven
Tidak konsisten traffic-nya
Peak hanya di jam tertentu

Time-to-Market Lambat #

Setiap service baru sering berarti:

Setup infra
Setup CI/CD
Setup monitoring
Setup scaling

Akibatnya:

Ide cepat → implementasi lambat

Serverless sebagai Jawaban Evolusi #

Serverless muncul sebagai abstraksi tingkat lanjut dari cloud.

Jika:

VM mengabstraksi hardware
Container mengabstraksi OS

Maka:

Serverless mengabstraksi server itu sendiri

Engineer hanya fokus pada:

Function
Event
Data

Bukan:

CPU
Memory
Disk
OS

Kenapa Serverless Menarik Secara Teknis #

Zero Infrastructure Management #

Dengan serverless:

Tidak ada provisioning server
Tidak ada patch OS
Tidak ada capacity planning

Platform yang bertanggung jawab:

AWS Lambda
Google Cloud Functions
Azure Functions

Engineer menulis kode bisnis, bukan kode operasional.

Autoscaling Native dan Instan #

Serverless:

Scale dari 0 ke ribuan instance otomatis
Tanpa konfigurasi scaling policy
Tanpa warm pool

Ini sangat sulit ditiru di sistem non-serverless.

Pay-per-Execution (Bukan Pay-per-Idle) #

Model billing serverless:

Bayar per request
Bayar per durasi eksekusi
Tidak ada biaya idle

Efek langsung:

Cocok untuk traffic fluktuatif
Cocok untuk workload sporadis
Cocok untuk startup dan eksperimen

Event-Driven Architecture Jadi First-Class Citizen #

Serverless sangat natural dengan event:

HTTP request
Message queue
File upload
Cron
Stream data

Ini mendorong desain sistem yang:

Decoupled
Reaktif
Mudah diskalakan

Kenapa Serverless Menarik Secara Bisnis #

Cost Efficiency (Jika Dipakai dengan Benar) #

Serverless unggul ketika:

Traffic tidak konstan
Banyak idle time
Event jarang tapi penting

Contoh nyata:

Background job
Webhook handler
Image processing
Notification system

Faster Time-to-Market #

Tidak perlu infra setup panjang
MVP bisa live dalam hitungan jam
Eksperimen murah dan cepat

Ini sangat krusial untuk:

Startup
Produk baru
Feature validation

Skala Tanpa Hiring Infrastruktur Engineer #

Dengan serverless:

Tim kecil bisa handle traffic besar
Fokus hiring ke product & backend
Infra team bisa sangat minimal

Kenapa Serverless Cocok untuk Pola Sistem Modern #

Microservices #

Serverless dan microservices saling melengkapi:

Service kecil
Scope jelas
Independent scaling

Function serverless adalah bentuk ekstrem dari microservice.

Event-Driven & Async System #

Serverless sangat ideal untuk:

Pub/Sub
Queue consumer
Stream processor

Karena:

Scale otomatis per event
Tidak ada worker idle

Backend-for-Frontend (BFF) #

Serverless cocok untuk:

API tipis
Logic spesifik per client
Gateway ringan

**Kenapa Serverless Bukan Solusi Segalanya** #

Serverless bukan silver bullet.

Cold Start #

Latency awal
Masalah untuk low-latency system
Perlu mitigasi (provisioned concurrency, dll)

Vendor Lock-in #

API spesifik provider
Runtime terbatas
Migration cost tidak nol

Observability Lebih Sulit #

Debug distributed function
Trace async flow
Log tersebar

Perlu tooling matang.

Tidak Cocok untuk Long-Running Process #

Batas waktu eksekusi
Tidak cocok untuk:
- Video rendering panjang
- ML training
- Stateful service

Kapan Serverless Adalah Pilihan Tepat #

Gunakan serverless jika:

Workload event-driven
Traffic tidak konsisten
Fokus ke speed & agility
Tim infra terbatas

Kapan Sebaiknya Tidak Menggunakan Serverless #

Hindari serverless jika:

Latency ultra rendah wajib
Long-running job dominan
Full control infra dibutuhkan
Biaya jadi lebih mahal di scale tertentu

Penutup #

Serverless bukan tentang menghilangkan server.

Serverless adalah tentang:

Menghilangkan beban yang tidak perlu
Menggeser fokus dari operasi ke produk
Mendesain sistem yang lebih reaktif dan elastis

Pertanyaan yang lebih tepat bukan “kenapa serverless?”, tapi:

“Apakah masalah saya layak diselesaikan dengan serverless?”

Jika iya—serverless adalah alat yang sangat kuat.

Jika tidak—menggunakannya hanya akan menjadi technical debt versi baru.