Pros & Cons Serverless #

Serverless bukan lagi sekadar buzzword. Dalam beberapa tahun terakhir, serverless telah menjadi pendekatan arsitektur yang diadopsi luas oleh startup hingga perusahaan skala enterprise. Meski namanya serverless, bukan berarti server benar-benar hilang—melainkan tanggung jawab pengelolaan server dialihkan sepenuhnya ke cloud provider.

Namun, seperti semua pendekatan teknologi, serverless bukanlah solusi universal. Ada konteks di mana serverless sangat unggul, dan ada pula kondisi di mana ia justru menimbulkan masalah baru. Artikel ini membahas pro dan kontra teknologi serverless secara mendetail dan rasional, agar pembaca dapat mengambil keputusan arsitektural dengan sadar.

Apa Itu Serverless? #

Serverless adalah model komputasi cloud di mana developer fokus pada business logic, sementara provisioning server, scaling, patching OS, dan high availability ditangani oleh provider.

Contoh layanan serverless:

• Function as a Service (FaaS): AWS Lambda, Google Cloud Functions, Azure Functions
• Serverless Container: AWS Fargate, Cloud Run
• Serverless Backend Service: Firebase, Supabase
• Serverless Message & Event: SQS, Pub/Sub, EventBridge

Kelebihan (Pros) #

Tidak Perlu Mengelola Infrastruktur #

Keuntungan utama serverless adalah eliminasi beban operasional server.

Tanpa serverless:

• Provision VM
• Patch OS
• Setup autoscaling
• Handle availability & failover

Dengan serverless:

• Deploy kode
• Tentukan memory / timeout
• Done

Dampak positif:

• Tim kecil bisa mengelola sistem kompleks
• Developer fokus ke fitur, bukan server

👉 Cocok untuk tim engineering ramping.

Autoscaling Default (Zero to N) #

Serverless bersifat event-driven dan secara default autoscale.

Karakteristik:

• Bisa scale dari 0 request → ribuan request secara otomatis
• Tidak perlu load balancer manual
• Tidak perlu capacity planning awal

Contoh kasus:

• API yang tiba-tiba viral
• Job batch periodik
• Event-based processing (upload file, webhook)

👉 Sangat kuat untuk workload tidak terprediksi.

Model Billing Pay-as-You-Go #

Serverless dibayar berdasarkan:

• Jumlah eksekusi
• Durasi eksekusi
• Resource aktual (memory/CPU)

Artinya:

• Tidak ada biaya idle
• Tidak bayar server yang menganggur

Contoh:

• Cron job 1x per hari → bayar 1x eksekusi
• API jarang dipakai → biaya nyaris nol

👉 Ideal untuk:

• MVP
• Proof of Concept
• Aplikasi low-traffic

Time-to-Market Lebih Cepat #

Dengan serverless:

• Tidak setup infra panjang
• CI/CD lebih sederhana
• Deployment lebih cepat

Developer bisa:

• Deploy fitur dalam hitungan menit
• Iterasi cepat
• Validasi ide lebih cepat

👉 Cocok untuk produk yang masih eksplorasi market.

Reliability & High Availability by Default #

Cloud provider menyediakan:

• Multi-AZ
• Auto-retry
• Managed failover

Tanpa perlu:

• Setup HA manual
• Replication infra sendiri

👉 Cocok untuk sistem yang butuh availability tinggi tanpa tim SRE besar.

Kekurangan (Cons) #

Cold Start #

Cold start terjadi saat:

• Tidak ada instance aktif
• Function perlu di-spin up

Dampaknya:

• Latency awal (ratusan ms hingga detik)
• Buruk untuk API latency-sensitive

Masalah ini makin terasa jika:

• Runtime berat (Java, .NET)
• Memory kecil

👉 Kurang cocok untuk:

• Real-time system
• Low-latency API (<50ms)

Vendor Lock-in #

Setiap provider punya:

• API
• Event model
• IAM
• Deployment tooling berbeda

Migrasi antar provider:

• Tidak trivial
• Bisa mahal secara engineering cost

Contoh:

• AWS Lambda + DynamoDB
• GCP Functions + Firestore

👉 Serverless mengikat arsitektur ke provider.

Observability Lebih Kompleks #

Dalam sistem serverless:

• Banyak function kecil
• Event-driven
• Asynchronous

Dampaknya:

• Tracing sulit
• Debugging tidak linear
• Log tersebar

Butuh:

• Distributed tracing
• Structured logging
• Correlation ID

👉 Tanpa disiplin observability, debugging bisa menyiksa.

Biaya Bisa Tidak Terduga #

Meski pay-as-you-go, serverless bisa mahal jika:

• Traffic tinggi dan stabil
• Function lama berjalan
• Banyak inter-service call

Ironi:

Pada skala besar & stabil, VM atau container bisa lebih murah.

👉 Serverless bukan selalu solusi paling hemat.

Batasan Runtime & Eksekusi #

Serverless memiliki limit:

• Timeout maksimum
• Memory terbatas
• CPU terbatas
• Tidak cocok untuk long-running process

Tidak cocok untuk:

• Video processing berat
• Machine learning training
• WebSocket stateful

👉 Serverless bukan pengganti semua workload.

Kompleksitas Arsitektur di Skala Besar #

Serverless mendorong:

• Microservices
• Event-driven
• Banyak komponen kecil

Tanpa desain matang:

• Spaghetti event
• Sulit reasoning
• Coupling tidak terlihat

👉 Dibutuhkan engineering maturity.

Ringkasan Pro vs Kontra #

Kapan Serverless Layak Digunakan? #

Gunakan serverless jika:

• Traffic tidak stabil
• Tim kecil
• Fokus ke bisnis
• Event-driven workload
• MVP / early stage

Hindari serverless jika:

• Latency sangat kritikal
• Workload stabil & tinggi
• Long-running job
• Butuh kontrol penuh infra

Penutup #

Serverless bukan silver bullet, tapi alat yang sangat kuat jika digunakan di konteks yang tepat. Kunci utamanya bukan memilih serverless atau tidak, melainkan memahami trade-off-nya secara sadar.

Engineer yang matang tidak bertanya:

“Apakah serverless bagus?”

Tapi:

“Apakah serverless masuk akal untuk problem ini?”