Kenapa Serverless? #

Pertanyaan “kenapa serverless?” bukan cuma muncul dari engineer junior. Senior engineer, tech lead, bahkan CTO sering menanyakannya — dan itu pertanyaan yang valid. 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 di sisi provider. Yang berubah adalah siapa yang bertanggung jawab terhadap server tersebut — dan jawabannya bukan tim engineering lagi. Artikel ini membahas akar masalah yang melatarbelakangi serverless, keuntungan nyata yang ditawarkan, jebakan yang sering diabaikan, dan panduan pragmatis kapan serverless adalah pilihan tepat.

Masalah Fundamental Arsitektur Tradisional #

Sebelum membahas kenapa serverless menarik, kita harus jujur pada masalah yang sebenarnya ingin dipecahkan. Masalah-masalah ini bukan hipotetis — semua engineer backend pernah mengalaminya.

Infrastruktur sebagai Beban Kognitif #

Pada arsitektur tradisional (VM atau bare metal), tim engineering menghabiskan waktu untuk hal-hal yang tidak berkaitan langsung dengan value bisnis:

Tanggung jawab tradisional:
  ✓ Provisioning server fisik/virtual
  ✓ Patch OS dan dependency
  ✓ Konfigurasi network & firewall
  ✓ Monitoring resource (CPU, RAM, disk)
  ✓ Capacity planning untuk puncak
  ✓ Rotasi credential & secret
  ✓ Setup backup & disaster recovery

Semua itu sah-sah saja — tapi waktu yang dihabiskan untuk itu adalah waktu yang tidak digunakan untuk fitur produk, optimasi UX, atau eksperimen bisnis.

Realita yang jarang dibicarakan: di banyak tim, 30–50% waktu engineering habis untuk operasional infrastruktur. Serverless tidak menghapus semua itu, tapi memindahkan sebagian besar ke provider — dan itu sudah menjadi game changer.

Over-Provisioning vs Under-Provisioning #

Dilema klasik capacity planning:

flowchart LR
    A["Prediksi traffic"] --> B{"Keputusan"}
    B -- "Terlalu besar" --> C["Uang terbuang<br/>80% resource idle"]
    B -- "Terlalu kecil" --> D["Downtime & latency<br/>user kecewa"]
    B -- "Pas (jarang)" --> E["Untungnya minimal<br/>suruh Ops lembur"]

Autoscaling di model tradisional memang membantu, tapi:

• Konfigurasinya kompleks — min/max instance, cooldown, threshold metric
• Scaling tidak instan — butuh waktu spin-up VM atau container
• Tetap perlu baseline — minimal 1–2 instance harus tetap hidup 24/7

Hasilnya: tim tetap membayar resource idle hanya untuk menangani spike yang mungkin tidak pernah datang.

Model Biaya yang Tidak Efisien #

Pada VM atau container tradisional,账单-nya sangat tidak ramah untuk traffic fluktuatif:

Padahal mayoritas aplikasi modern punya karakteristik:

• Event-driven — kerja hanya saat ada trigger
• Traffic tidak konsisten — puncak di jam tertentu, sepi di jam lain
• Sporadis — beberapa fitur mungkin dipanggil ratusan kali per hari, yang lain hanya 5 kali per bulan

Untuk pola seperti ini, model pay-per-idle adalah pemborosan sistematis.

Time-to-Market yang Lambat #

Setiap service baru di arsitektur tradisional sering memicu ritual panjang:

Setup service baru — checklist tradisional:

  □ Provision server/cluster
  □ Setup load balancer
  □ Konfigurasi auto-scaling
  □ Setup CI/CD pipeline
  □ Integrasi monitoring & alerting
  □ Setup log aggregation
  □ Konfigurasi secret management
  □ Test failover & recovery
  □ Approval security review
  □ ... baru mulai coding

Akibatnya:

Ide cepat, tapi implementasi lambat.

Ini jadi masalah besar di lingkungan startup atau tim produk yang perlu validasi hipotesis dalam hitungan hari, bukan bulan.

Serverless sebagai Jawaban Evolusi #

Serverless bukan muncul tiba-tiba. Ia adalah abstraksi tingkat lanjut yang melanjutkan tren yang sudah dimulai sejak virtualisasi:

flowchart LR
    A["Server Fisik"] -->|"Abstraksi hardware"| B["VM"]
    B -->|"Abstraksi OS"| C["Container"]
    C -->|"Abstraksi server"| D["Serverless"]
    
    style A stroke:#ff5555,stroke-width:2px
    style B stroke:#ffaa00,stroke-width:2px
    style C stroke:#0080ff,stroke-width:2px
    style D stroke:#00bb00,stroke-width:2px

Setiap langkah menyederhanakan satu layer yang sebelumnya menjadi tanggung jawab developer:

Perhatikan bedanya: di serverless, tiga layer terbawah (server, runtime, scaling) hilang dari tanggung jawab developer. Yang tersisa adalah kode, event, dan data — tiga hal yang benar-benar bernilai bisnis.

Keuntungan Teknis Serverless #

1. Zero Infrastructure Management #

Ini adalah janji utama serverless — dan yang paling terasa dampaknya:

# ANTI-PATTERN: Checklist harian sysadmin di era tradisional
# (bukan cuma waktu, tapi juga risiko human error)
daily_ops:
  - check_disk_space: "df -h"
  - check_memory: "free -m"
  - rotate_logs: "logrotate"
  - update_packages: "apt update && apt upgrade"
  - review_alerts: "cek 5 dashboard monitoring"
  - backup_data: "pg_dump ke S3"

# BENAR: Di era serverless, semua checklist di atas
# adalah urusan AWS/GCP/Azure. Engineer fokus ke kode.
serverless_daily_ops:
  - review_function_logs: "CloudWatch"
  - review_error_rate: "Datadog"
  - ship_feature: "git push origin main"

Provider yang menawarkan ini:

• AWS Lambda — pionir, ekosistem paling matang
• Google Cloud Functions — integrasi native dengan GCP
• Azure Functions — tight coupling dengan .NET dan Azure ecosystem
• Cloudflare Workers — edge compute, latency super rendah

2. Autoscaling Native dan Instan #

Serverless punya kemampuan scaling yang sangat sulit ditiru di sistem tradisional:

sequenceDiagram
    participant T as Traffic
    participant S as Serverless Platform
    participant F1 as Function Instance 1
    participant F2 as Function Instance 2
    participant F3 as Function Instance N...

    T->>S: 1 request
    S->>F1: invoke
    T->>S: 100 requests/detik
    S->>F1: invoke
    S->>F2: spawn baru
    T->>S: 10.000 requests/detik
    S->>F1: invoke
    S->>F2: invoke
    S->>F3: spawn 98 instance lagi

    Note over S: Scaling terjadi dalam milidetik,<br/>tanpa konfigurasi scaling policy,<br/>tanpa warm pool management.

Karakteristik scaling serverless:

3. Pay-per-Execution #

Ini yang sering jadi sorotan utama — dan memang powerful:

Perbandingan model billing:

Serverless:
  Bayar hanya saat kode berjalan
  - 1.000 request × 200ms = 1.000 × durasi
  - 0 request = Rp 0
  - Tidak ada biaya idle, tidak ada baseline

VM/Container Tradisional:
  Bayar selama server hidup
  - Server hidup 24/7 = 720 jam/bulan
  - Request 0 atau 1 juta = bayar sama
  - Ada minimum spend bulanan

Efek langsungnya:

• Cocok untuk traffic fluktuatif
• Cocok untuk workload sporadis (cron job, webhook, notifikasi)
• Cocok untuk startup yang ingin eksperimen murah

4. Event-Driven Sebagai First-Class Citizen #

Serverless sangat natural dengan event — dan ini sering tidak disadari oleh tim yang datang dari arsitektur request-response:

flowchart LR
    subgraph Sources[Event Sources]
        A1[HTTP Request]
        A2[S3 Upload]
        A3[SQS Message]
        A4[CRON Schedule]
        A5[DynamoDB Stream]
    end
    
    subgraph Lambda[Lambda Function]
        L[Process Event]
    end
    
    subgraph Targets[Targets]
        T1[Send Email]
        T2[Write to DB]
        T3[Trigger Workflow]
    end
    
    Sources --> Lambda
    Lambda --> Targets

Event sources yang didukung native:

Ini mendorong desain sistem yang decoupled, reactive, dan scalable — yang biasanya hanya dicapai dengan effort besar di arsitektur tradisional.

Keuntungan Bisnis Serverless #

Cost Efficiency (Jika Dipakai dengan Benar) #

Serverless bukan selalu lebih murah — tapi untuk workload yang tepat, selisihnya bisa signifikan:

flowchart TD
    A{"Profil traffic?"} -->|"Spiky/sporadis"| B["Serverless biasanya lebih murah"]
    A -->|"Stabil & tinggi"| C["Server traditional bisa lebih murah"]
    A -->|"Sangat tinggi, konstan"| D["Reserved/committed instance menang"]

Contoh workload yang biasanya menang di serverless:

• Background job — proses yang berjalan beberapa kali per jam
• Webhook handler — traffic unpredictable, spike saat event eksternal
• Image processing — dipicu hanya saat upload
• Notification system — email/push saat event tertentu
• API untuk MVP — traffic masih rendah, biaya tetap rendah
• ETL/transformasi data — dijalankan terjadwal, bukan 24/7

Faster Time-to-Market #

Ini krusial untuk:

• Startup — validasi ide sebelum kehabisan runway
• Produk baru — time-to-market menentukan competitive advantage
• Feature validation — A/B test dengan biaya rendah

Skala Tanpa Hiring Infrastruktur Engineer #

Salah satu keuntungan yang sering tidak terlihat di awal: serverless memungkinkan tim kecil menangani traffic besar.

Skenario tradisional (tim 5 engineer):
  1 Tech Lead
  2 Backend Engineer
  1 Frontend Engineer
  1 DevOps/Infrastructure Engineer  ← tidak perlu di model serverless

Skenario serverless (tim 4 engineer):
  1 Tech Lead
  3 Backend Engineer (semuanya bisa handle infra via IaC)

Pengalaman banyak startup: dengan serverless, tim 3–5 engineer bisa handle traffic yang biasanya butuh tim 10+ di arsitektur tradisional. Ini bukan hiperbola — ini terjadi di banyak perusahaan (Coca-Cola, Nordstrom, fintech startup) yang bermigrasi ke serverless.

Serverless Cocok untuk Pola Sistem Modern #

Microservices #

Serverless dan microservices adalah pasangan alami:

flowchart TB
    subgraph Monolith["Monolith"]
        M["1 codebase besar<br/>1 deployment<br/>1 tim"]
    end
    
    subgraph Microservice["Microservices"]
        S1["Service A<br/>1 function"]
        S2["Service B<br/>1 function"]
        S3["Service C<br/>1 function"]
    end
    
    subgraph ServerlessMicroservice["Serverless Microservices"]
        L1["Function: Auth"]
        L2["Function: Catalog"]
        L3["Function: Order"]
        L4["Function: Payment"]
        L5["Function: Notification"]
    end
    
    Monolith -->|"Decompose"| Microservice
    Microservice -->|"Run on"| ServerlessMicroservice

Function serverless adalah bentuk paling granular dari microservice — satu function, satu tanggung jawab, satu deployment.

Event-Driven dan Async System #

Serverless ideal untuk:

• Pub/Sub consumer — terima message, proses, keluar
• Queue worker — scale per message
• Stream processor — Kinesis, Kafka consumer
• Webhook handler — dipanggil event dari sistem eksternal

Karena semua model ini:

• Skala otomatis per event
• Tidak ada worker idle saat antrian kosong
• Biaya nol saat tidak ada event

Backend-for-Frontend (BFF) #

Serverless cocok untuk:

• API tipis — agregasi data untuk mobile/web
• Logic spesifik per client — endpoint berbeda untuk iOS vs Android
• Gateway ringan — routing, auth, transform

Function BFF biasanya kecil, cepat, dan murah — persis karakter serverless.

Kenapa Serverless BUKAN Solusi Segalanya #

Sekarang bagian yang jarang dibicarakan marketing. Serverless punya keterbatasan nyata yang harus dipahami sebelum commit.

Cold Start #

Function yang jarang dipanggil akan butuh waktu startup:

Cold start timeline:

flowchart TD
    Request["Request masuk"]
    Decision{"Platform cari container siap?"}
    Exec["Eksekusi (~50ms)"]
    Provision["Provision container baru (~200ms–5 detik)"]
    Init["Init runtime"]
    ExecCode["Eksekusi kode"]

    Request --> Decision
    Decision -->|Ya| Exec
    Decision -->|Tidak| Provision
    Provision --> Init
    Init --> ExecCode

Cold start menjadi masalah untuk:

• API yang sensitif latency (real-time trading, gaming)
• Function yang dipanggil jarang (jam pertama setelah deploy)
• Runtime berat (Java lebih lambat dari Node.js atau Go)

# ANTI-PATTERN: Mengabaikan cold start untuk use case latency-kritis
# (misalnya: real-time bidding, IoT command)
function_timeout: 100ms  # target response
actual_latency: 3500ms   # rata-rata karena cold start
# → target tidak pernah tercapai

# BENAR: Pilih serverless hanya untuk use case yang toleran
# terhadap cold start, atau mitigasi dengan:
#   - provisioned concurrency
#   - lighter runtime
#   - keep-warm strategy
#   - edge function (Cloudflare Workers, Lambda@Edge)

Vendor Lock-in #

flowchart LR
    A[Code di AWS Lambda] -->|Migrate ke GCP| B[Refactor handler signature]
    B --> C[Update event trigger]
    C --> D[Update IAM permission]
    D --> E[Test integration ulang]
    E --> F[Update monitoring]
    F --> G[Biaya migrasi tinggi]

Setiap provider punya:

• API event sendiri (S3 event vs Cloud Storage event)
• IAM model sendiri
• Runtime limit sendiri
• Pricing model sendiri (walau mirip)

Migrasi tidak mustahil, tapi tidak nol biaya. Mitigation: gunakan framework agnostic seperti Serverless Framework, Terraform, atau Pulumi untuk abstraksi.

Observability Lebih Sulit #

Sistem terdistribusi memang lebih sulit di-debug:

Tantangan observability serverless:

  ✗ 50 function = 50 log stream berbeda
  ✗ Request melewati 5 function = 5 hop yang harus di-trace
  ✗ Async event = tidak ada correlation ID otomatis
  ✗ Cold start metrics sulit di-aggregate
  ✗ Vendor-specific tool (X-Ray, Stackdriver) tidak portable

Solusi: invest di APM tool dari awal (Datadog, Lumigo, Epsagon, Thundra), terapkan distributed tracing, dan pakai structured logging dengan correlation ID.

Tidak Cocok untuk Long-Running Process #

Ada batas keras untuk durasi eksekusi:

Artinya serverless TIDAK cocok untuk:

• Video rendering berdurasi panjang
• ML model training
• ETL batch yang memproses data besar
• Stateful long-lived connection (WebSocket di Lambda = anti-pattern)
• Proses yang harus idle menunggu event eksternal

Decision Framework — Pilih Serverless atau Tidak #

Daripada menebak-nebak, gunakan framework ini untuk memutuskan.

flowchart TD
    A{"Profil workload?"} -->|"Event-driven"| B{"Butuh latensi<br/>ultra-rendah?"}
    A -->|"Long-running"| C["Gunakan VM/Container"]
    A -->|"Stateful persistent"| C
    A -->|"Traffic konstan tinggi"| D{"Ada budget<br/>untuk reserved?"}
    D -->|"Ya"| E["Gunakan VM/Container<br/>dengan reserved"]
    D -->|"Tidak"| F["Serverless masih bisa<br/>tapi pertimbangkan cost"]
    B -->|"Ya"| G["Serverless dengan<br/>mitigasi cold start"]
    B -->|"Tidak"| H["Sangat cocok<br/>serverless ✓"]
    
    style H stroke:#00bb00,stroke-width:2px
    style C stroke:#ff5555,stroke-width:2px
    style E stroke:#ffaa00,stroke-width:2px
    style G stroke:#ffaa00,stroke-width:2px
    style F stroke:#ffaa00,stroke-width:2px

Gunakan Serverless Jika #

Sangat cocok untuk:
  ✓ Workload event-driven (webhook, queue, file upload)
  ✓ Traffic tidak konsisten atau sporadis
  ✓ Fokus ke speed-to-market tinggi
  ✓ Tim infra terbatas atau tidak ada
  ✓ API untuk MVP atau eksperimen
  ✓ Microservices kecil dengan scope jelas
  ✓ Scheduled jobs / cron replacement

Hindari Serverless Jika #

Tidak cocok untuk:
  ✗ Latency ultra-rendah (sub-10ms konsisten)
  ✗ Long-running process (video encoding, ML training)
  ✗ Stateful long-lived connection
  ✗ Kebutuhan kontrol OS/hardware penuh
  ✗ Workload traffic konstan tinggi (reserved instance menang)
  ✗ Compliance yang melarang shared infrastructure

Prinsip penting: serverless adalah alat, bukan agama. Pilih berdasarkan profil workload, bukan karena hype. Tim yang sukses dengan serverless adalah tim yang paham kapan tidak menggunakannya.

Anti-Pattern yang Sering Terjadi #

Beberapa jebakan umum saat mengadopsi serverless:

# ✗ Anti-Pattern 1: Mengira serverless = tanpa biaya
# Faktanya, untuk traffic tinggi dan konstan, serverless
# bisa lebih mahal dari VM/Container.
# Hitung cost per 1 juta request, bukan asumsi generik.

# ✓ Solusi: monitor billing dengan tag per service,
#   pasang budget alarm, dan review cost mingguan.

# ✗ Anti-Pattern 2: Memaksakan monolith sebagai satu function
# Kehilangan semua benefit scaling, observability, dan isolation.

# ✓ Solusi: pecah berdasarkan domain atau use case,
#   gunakan Step Functions/Workflows untuk orkestrasi.

# ✗ Anti-Pattern 3: Abaikan cold start sampai production
# Baru sadar cold start masalah saat user complain.

# ✓ Solusi: load test dengan traffic pattern realistis
#   sebelum launch, monitor P99 latency dari hari pertama.

# ✗ Anti-Pattern 4: Tidak invest di observability
# 50 function tanpa distributed tracing = mimpi buruk debugging.

# ✓ Solusi: APM tool + structured logging + correlation ID
#   dari awal, bukan setelah production down.

# ✗ Anti-Pattern 5: Pilih serverless karena "keren"
# Tanpa analisis workload, adopsi serverless = technical debt.

# ✓ Solusi: gunakan decision framework di atas
#   untuk setiap service baru, jangan blanket adopt.

Ringkasan #

• Serverless bukan tren — ia adalah konsekuensi logis dari evolusi infrastruktur: hardware → VM → container → function. Setiap langkah menyederhanakan satu layer.
• Masalah utama yang diselesaikan: beban operasional infrastructure, over/under-provisioning, model biaya yang tidak efisien untuk traffic fluktuatif, dan time-to-market lambat.
• Keuntungan teknis: zero infrastructure management, autoscaling instan per request, pay-per-execution, dan event-driven sebagai first-class citizen.
• Keuntungan bisnis: cost efficiency untuk workload yang tepat, time-to-market yang jauh lebih cepat, dan tim kecil bisa handle traffic besar.
• Paling cocok untuk: microservices, event-driven system, BFF API, scheduled jobs, webhook handler, dan MVP/startup.
• Keterbatasan nyata: cold start, vendor lock-in, observability lebih sulit, tidak cocok untuk long-running process, dan bisa lebih mahal untuk traffic konstan tinggi.
• Prinsip utama: serverless adalah alat, bukan agama. Gunakan decision framework, monitor cost, invest di observability, dan jangan paksakan untuk workload yang tidak cocok.
• Pertanyaan yang tepat bukan “kenapa serverless?”, tapi “apakah masalah saya layak diselesaikan dengan serverless?” — jawabannya menentukan segalanya.

← Sebelumnya: Sejarah Serverless   Berikutnya: Kapan Digunakan? →