FaaS/Serverless #
Serverless adalah model di mana kamu menulis kode tanpa memikirkan server sama sekali — tidak ada OS yang perlu di-patch, tidak ada kapasitas yang perlu direncanakan, tidak ada server yang perlu di-monitor. Kamu hanya mendefinisikan apa yang dilakukan kode ketika sebuah event terjadi, dan platform menangani sisanya. Istilah “serverless” sering disalahartikan sebagai “tidak ada server” — padahal server tetap ada, hanya saja kamu tidak perlu tahu tentangnya.
Cara Kerja Serverless #
Di model tradisional, server berjalan terus-menerus menunggu request. Di serverless, kode hanya berjalan ketika ada event yang men-trigger-nya — dan berhenti setelah selesai.
Model Server Tradisional:
Server berjalan 24/7
→ Menunggu request (idle, tapi tetap dibayar)
→ Menerima request → proses → kirim response
→ Kembali menunggu (idle lagi)
Biaya: proporsional dengan waktu server berjalan,
tidak peduli seberapa banyak request yang datang
Model Serverless (FaaS):
Tidak ada instance yang berjalan saat idle
→ Event terjadi (HTTP request, pesan di queue, perubahan file)
→ Platform inisialisasi execution environment
→ Fungsi berjalan → proses → selesai
→ Execution environment dilepaskan
Biaya: proporsional dengan jumlah eksekusi dan durasinya,
bukan dengan waktu "server berjalan"
Anatomy Fungsi Serverless #
Sebuah fungsi serverless pada dasarnya adalah sepotong kode dengan tiga elemen: trigger, handler, dan return value.
// Contoh struktur fungsi serverless (pseudocode)
// Trigger: HTTP request POST /orders
// Handler: proses pembuatan order baru
// Return: response HTTP
function handleCreateOrder(event, context) {
// event: berisi data request (body, headers, path params)
// context: informasi tentang eksekusi (timeout, request ID)
const orderData = parseBody(event.body)
// Validasi input
if (!orderData.productId || !orderData.quantity) {
return {
statusCode: 400,
body: JSON.stringify({ error: "productId dan quantity wajib diisi" })
}
}
// Proses bisnis
const order = createOrder(orderData)
return {
statusCode: 201,
body: JSON.stringify(order)
}
}
Fungsi ini tidak punya state, tidak punya “siklus hidup server” — ia ada ketika dipanggil, dan tidak ada ketika tidak dipanggil.
Trigger — Apa yang Memulai Eksekusi #
Salah satu kekuatan serverless adalah fleksibilitas trigger. Fungsi bisa diaktifkan oleh berbagai jenis event.
Jenis Trigger Umum:
HTTP / API Gateway:
→ Request ke endpoint REST atau GraphQL
→ Paling umum untuk web API dan backend aplikasi
Message Queue / Event Stream:
→ Pesan masuk ke queue (SQS, Pub/Sub, Service Bus)
→ Record baru di event stream (Kinesis, Kafka managed)
→ Cocok untuk async processing dan event-driven architecture
Storage Event:
→ File baru di-upload ke object storage
→ Record di database berubah (change data capture)
→ Cocok untuk ETL, image processing, file validation
Scheduled (Cron):
→ Jalankan fungsi setiap interval tertentu
→ Pengganti cron job yang tidak butuh server dedicated
Other Services:
→ Email masuk
→ IoT device message
→ Authentication event (user login)
Cold Start — Tantangan Utama Serverless #
Ketika sebuah fungsi dipanggil pertama kali (atau setelah lama tidak dipanggil), platform perlu menginisialisasi execution environment dari nol. Ini disebut cold start dan bisa menambah latensi yang signifikan.
Cold Start vs Warm Start:
Cold Start (instance baru):
Platform siapkan environment
→ Download dan ekstrak package fungsi
→ Inisialisasi runtime (Node.js, Python, Java, dll)
→ Jalankan initialization code (koneksi DB, load config)
→ Eksekusi handler
Total latensi cold start: ratusan ms hingga beberapa detik
(bergantung pada runtime dan ukuran package)
Warm Start (instance sudah ada):
Instance existing langsung eksekusi handler
Total latensi warm start: sama dengan latency normal kode
Faktor yang Mempengaruhi Cold Start:
✗ Runtime yang berat (Java, .NET) → cold start lebih lama
✓ Runtime yang ringan (Python, Node.js) → cold start lebih cepat
✗ Package besar (banyak dependensi) → cold start lebih lama
✗ Code yang banyak inisialisasi (koneksi DB) → lebih lama
Cold start bukan alasan untuk menghindari serverless, tapi ia adalah faktor yang harus diperhitungkan dalam desain. Untuk API yang butuh latensi konsisten rendah (< 100ms), cold start bisa menjadi masalah. Solusinya bisa berupa provisioned concurrency (bayar untuk instance yang selalu warm), optimasi ukuran package, atau memilih runtime yang lebih ringan.
Batasan Serverless yang Perlu Diketahui #
Serverless bukan solusi universal. Ada batasan teknis yang harus dipahami sebelum mengadopsinya.
Batasan Umum Serverless:
Durasi Eksekusi:
→ Setiap fungsi punya batas waktu maksimum
(biasanya 15 menit, beberapa platform lebih pendek)
→ Tidak cocok untuk proses yang butuh jam untuk selesai
Stateless:
→ Tidak ada state yang tersimpan di antara eksekusi
→ Setiap eksekusi harus mandiri atau bergantung pada
external store (database, cache)
Concurrency dan Throttling:
→ Ada batas berapa banyak fungsi bisa berjalan bersamaan
→ Saat melebihi limit, request baru di-throttle
→ Penting untuk dimonitor dan direncanakan
Vendor Lock-in yang Lebih Tinggi:
→ Trigger, runtime environment, dan konfigurasi sangat
spesifik per provider
→ Lebih sulit di-port ke provider lain dibanding VM
Debugging yang Lebih Kompleks:
→ Tidak bisa SSH ke "server" untuk debug
→ Distributed tracing dan logging yang baik menjadi wajib
Kapan Serverless Tepat Digunakan #
Gunakan Serverless jika:
✓ Workload event-driven dengan pola trafik yang tidak predictable
→ Fungsi yang jarang dipanggil tapi harus selalu siap
→ Proses background yang dipicu oleh event
✓ Kamu ingin nol overhead operasional
→ Tidak ada server yang perlu di-patch atau di-monitor
→ Sangat cocok untuk tim kecil atau startup
✓ Workload dengan banyak idle time
→ Aplikasi yang digunakan hanya beberapa jam sehari
→ Bayar eksekusi, bukan waktu idle
✓ Integrasi dan automation sederhana
→ Webhook handler
→ ETL ringan
→ Notifikasi otomatis
Hindari Serverless jika:
✗ Workload butuh eksekusi panjang (> 15 menit)
✗ Aplikasi yang butuh latensi sangat konsisten dan rendah
(cold start bisa mengganggu)
✗ Proses yang butuh banyak state dan komunikasi antar komponen
→ Container atau microservices mungkin lebih tepat
✗ Workload yang sangat predictable dan tinggi
→ Biaya serverless di throughput tinggi bisa lebih mahal
dari container yang selalu berjalan
Ringkasan #
- Serverless bukan “tidak ada server” — server tetap ada, hanya dikelola sepenuhnya oleh provider. Kamu hanya menulis kode dan mendefinisikan trigger.
- FaaS ditagih per eksekusi, bukan per waktu berjalan — ini membuatnya sangat efisien untuk workload dengan idle time tinggi.
- Cold start adalah trade-off utama — latensi pertama eksekusi (atau setelah idle) bisa ratusan ms hingga detik. Runtime ringan dan package kecil membantu meminimalkan ini.
- Serverless mendorong arsitektur event-driven — fungsi yang kecil, satu tujuan, dan dipicu oleh event adalah pola yang paling cocok.
- Stateless adalah syarat mutlak — tidak ada shared state antar eksekusi; gunakan external store untuk persistence.
- Vendor lock-in lebih tinggi dibanding IaaS — trigger, runtime, dan konfigurasi sangat provider-specific. Pertimbangkan ini jika portabilitas adalah prioritas.