“Serverless” adalah salah satu kata di dunia tech yang paling sering membuat orang salah paham — bukan karena konsepnya sulit, tapi karena namanya sendiri misleading. Ada server, tetap ada. Kamu hanya tidak mengelolanya.
Dan “tidak mengelola server” ini memang ada manfaatnya. Tapi bukan berarti cocok untuk semua situasi.
Di 2026, serverless sudah cukup mature. Cold start sudah berkurang drastis, ekosistem tools-nya sudah lebih baik, dan pricing model sudah lebih predictable. Tapi masih banyak developer yang either over-adopt (pakai serverless untuk hal yang tidak cocok) atau under-adopt (takut pakai karena stigma lama).
Artikel ini buat kamu yang mau mengerti kapan serverless adalah pilihan yang tepat, dan kapan kamu lebih baik stick dengan server tradisional.
Apa Itu Serverless (Benar-benar)
Supaya kita sama pemahaman: serverless function (atau Function as a Service / FaaS) adalah kode yang:
- Berjalan sebagai unit fungsi independen
- Di-trigger oleh event (HTTP request, queue message, scheduled job, dll)
- Scale otomatis (dari nol, ke banyak, kembali ke nol)
- Dibayar per eksekusi / per waktu compute yang dipakai, bukan per jam server berjalan
Platform utama: AWS Lambda, Cloudflare Workers, Vercel Edge Functions, Google Cloud Functions, Azure Functions.
Masing-masing punya karakteristik berbeda (runtime, cold start behavior, pricing, batas size), tapi konsep dasarnya sama.
Kenapa Serverless Makin Relevan di 2026
Beberapa hal yang berubah yang membuat serverless lebih viable:
Cold start sudah jauh membaik. Dulu keluhan utama serverless adalah cold start — waktu yang dibutuhkan container baru untuk boot ketika fungsi belum aktif. Cloudflare Workers mengeliminasi ini dengan isolate-based architecture. AWS Lambda juga terus improve dengan SnapStart untuk JVM. Cold start masih ada, tapi jauh less painful dari 3-4 tahun lalu.
Edge serverless makin powerful. Cloudflare Workers, Vercel Edge, dan Deno Deploy memungkinkan kode kamu berjalan di ratusan titik di seluruh dunia, dekat dengan user. Untuk latency-sensitive use case, ini game changer.
Ekosistem framework mature. Framework seperti SST (Serverless Stack), Hono.js untuk edge, atau Nitro (dari tim Nuxt) membuat develop dan deploy serverless lebih streamlined.
AI inference di edge. Model AI yang lebih ringan sekarang bisa di-run di edge serverless, yang membuka use case baru.
Kapan Serverless Adalah Pilihan Tepat
1. Traffic yang Tidak Merata / Spiky
Kalau aplikasi kamu punya pola traffic yang sangat tidak merata — ramai di jam tertentu, sepi di jam lain — serverless sangat hemat. Kamu bayar hanya saat ada request. Server tradisional yang jalan 24/7 untuk handle puncak traffic sementara 80% waktu idle itu buang uang.
Contoh: Aplikasi yang kirim notifikasi harian jam 9 pagi, form yang diisi user cuma di jam kantor, atau event-driven processing.
2. Startup / MVP yang Budget Terbatas
Serverless cocok banget untuk fase awal karena:
- Bayar sesuai pemakaian, bukan fixed cost
- Tidak perlu maintain server, patching OS, dll
- Fokus ke build product, bukan infra management
Free tier di AWS Lambda, Cloudflare Workers, dan Vercel cukup generous untuk aplikasi yang masih kecil.
3. Microservice dan Event-Driven Architecture
Kalau kamu sudah punya arsitektur yang terdiri dari service-service kecil yang independent — serverless function cocok banget sebagai “worker” untuk tiap service. Combine dengan message queue (SQS, RabbitMQ, atau Kafka) untuk async processing.
4. Scheduled Jobs / Cron
Ganti cron job yang butuh dedicated server dengan Lambda + EventBridge atau Cloudflare Cron Triggers. Jauh lebih murah dan lebih mudah dikelola.
5. Stateless API Endpoints
API yang stateless (tidak maintain state antara request), volume request-nya bervariasi, dan tidak butuh koneksi database yang persistent — ini sweet spot serverless.
6. Edge-Heavy Use Cases
Content transformation, A/B testing logic, personalization, atau bot protection yang perlu berjalan dekat dengan user — Cloudflare Workers atau Vercel Edge Functions adalah pilihan yang powerful.
Kapan Hindari Serverless
1. Long-Running Jobs
Serverless functions punya batas waktu eksekusi. AWS Lambda maksimal 15 menit. Cloudflare Workers bahkan lebih pendek (50ms CPU time untuk free tier, sekitar 30 detik untuk paid).
Kalau kamu process video, batch import data besar, atau training ML — serverless bukan tempatnya. Pakai long-running container atau VM.
2. Aplikasi dengan Koneksi Database yang Heavy
Salah satu gotcha terbesar: serverless function yang scale ke banyak instance secara tiba-tiba bisa exhaust connection pool database kamu. PostgreSQL hanya support sejumlah tertentu concurrent connections.
Solusinya ada (PgBouncer, connection pooler seperti PlanetScale atau Neon yang punya connection pooling built-in), tapi ini tambah complexity. Kalau kamu expect traffic yang consistent dan heavy ke database, server tradisional dengan connection pool yang proper sering lebih mudah dikelola.
3. Stateful Applications
Aplikasi yang butuh maintain state di server (WebSocket sessions yang persistent, in-memory cache yang perlu dishare antar request) membutuhkan workaround di serverless — external Redis, DynamoDB, dll. Bukan impossible, tapi menambah kompleksitas dan cost.
4. Latency yang Sangat Kritis (Di Luar Edge)
Untuk non-edge serverless (Lambda, Cloud Functions), kalau ada cold start, latency bisa spike. Untuk aplikasi real-time yang latency-nya harus sub-100ms secara konsisten, ini bisa jadi masalah.
5. Ketika Local Dev Experience Penting
Salah satu pain point serverless yang sering underappreciated: local development experience. Mensimulasikan event triggers, permissions, dan environment yang persis sama dengan cloud itu tidak selalu mudah. Kalau tim kamu butuh fast iteration dengan feedback loop yang cepat, server biasa kadang lebih smooth.
6. Compliance dan Data Residency
Beberapa industri (kesehatan, keuangan) punya regulasi ketat soal di mana data boleh diproses dan disimpan. Kalau compliance requirements spesifik, pastikan platform serverless kamu mendukung ini sebelum commit.
Hybrid Architecture: Yang Sering Paling Masuk Akal
Di dunia nyata, jawabannya sering: keduanya, sesuai use case.
Arsitektur yang saya sering rekomendasikan untuk startup/scale-up:
- Core application (backend API, database): Container-based di Kubernetes atau managed service (Railway, Fly.io, Render) — lebih predictable, lebih mudah untuk stateful operations
- Background jobs: Serverless functions — scheduled tasks, webhook handlers, async processing
- Edge concerns: Cloudflare Workers — caching, rate limiting, auth edge case, A/B testing
- File processing: Lambda yang di-trigger oleh S3 upload event
Tidak ada yang pure serverless atau pure server — combine berdasarkan kebutuhan tiap komponen.
Pertanyaan yang Perlu Dijawab Sebelum Adopt Serverless
Sebelum commit ke serverless untuk bagian tertentu dari sistem, tanyakan:
- Berapa lama maksimal execution time yang dibutuhkan?
- Apakah ini stateless? Kalau tidak, bagaimana state akan dikelola?
- Berapa concurrent instances yang mungkin terjadi, dan apakah ini aman untuk database?
- Apakah cold start acceptable untuk use case ini?
- Bagaimana cara debug ketika ada issue di production?
- Apakah cost model serverless lebih efisien dari server untuk traffic pattern yang diharapkan?
Jawaban dari pertanyaan-pertanyaan ini akan jauh lebih berguna dari “serverless lagi hype” atau “serverless terlalu ribet.”
Kesimpulan
Serverless di 2026 adalah teknologi yang sudah proven dan memiliki tempat yang jelas dalam arsitektur modern. Bukan untuk menggantikan semua, tapi sebagai tool yang powerful untuk use case yang tepat.
Jangan adopt karena hype. Jangan hindari karena takut kompleksitas. Pahami trade-off-nya, match dengan kebutuhan spesifik sistem kamu, dan ambil keputusan berdasarkan data dan requirements nyata.
Lagi desain arsitektur untuk aplikasi baru dan bingung pilih antara serverless, container, atau tradisional server? Atau mau audit arsitektur yang sudah ada untuk lihat apakah ada yang bisa dioptimasi? Yuk ngobrol — hubungi mafadev dan kita diskusi teknikal bareng.
Leave a Reply