Serverless #

Serverless adalah model arsitektur cloud di mana developer tidak perlu mengelola server secara langsung (provisioning, patching, scaling). Infrastruktur sepenuhnya ditangani oleh cloud provider, sementara developer fokus pada business logic.

⚠️ Serverless bukan berarti “tanpa server”, tapi server-nya diabstraksikan.

Contoh layanan serverless:

• AWS: Lambda, API Gateway, DynamoDB
• GCP: Cloud Functions, Cloud Run, Firestore
• Azure: Azure Functions, Logic Apps

Cara Kerja Serverless (High-Level Flow) #

Client
  ↓ HTTP/Event
API Gateway / Event Source
  ↓
Serverless Function
  ↓
Managed Services (DB, Cache, Queue, Storage)

Karakteristik utama:

• Event-driven
• Auto-scale
• Pay-per-use
• Stateless by default

Komponen Utama dalam Arsitektur Serverless #

Compute (Function as a Service / FaaS) #

Menjalankan fungsi kecil dengan lifecycle pendek.

Contoh:

• AWS Lambda
• Cloud Functions

Ciri khas:

• Stateless
• Timeout terbatas
• Cold start possible

API Gateway / Event Trigger #

Sebagai entry point event:

• HTTP request
• Queue message
• Cron
• File upload

Contoh:

• AWS API Gateway
• GCP Eventarc

Managed Backend Services #

Serverless sangat bergantung pada managed services:

• Database (DynamoDB, Firestore)
• Cache (Redis managed)
• Queue (SQS, Pub/Sub)
• Storage (S3, GCS)

Kapan Serverless Tepat Digunakan? #

✅ Cocok untuk:

• Event-driven system
• API dengan traffic fluktuatif
• Background job
• Microservice skala kecil–menengah
• MVP & rapid development

❌ Kurang cocok untuk:

• Long-running process
• Low-latency ultra-critical system
• Heavy stateful workload
• Workload dengan traffic konstan tinggi (lebih murah VM)

Keuntungan Serverless #

No Server Management #

• Tidak perlu patch OS
• Tidak perlu scaling manual

Auto Scaling by Default #

• Scale to zero
• Scale massively saat spike

Cost Efficiency #

• Bayar per eksekusi
• Tidak bayar idle

Faster Time-to-Market #

• Fokus ke logic
• Infrastruktur minimal

Tantangan & Risiko Serverless #

Cold Start #

Fungsi pertama setelah idle akan lebih lambat.

Mitigasi:

• Provisioned concurrency
• Lightweight runtime
• Warm-up scheduler

Observability Sulit #

• Distributed tracing
• Debugging async

Solusi:

• Centralized logging
• Correlation ID
• Tracing (OpenTelemetry)

Vendor Lock-in #

• API spesifik provider

Solusi:

• Abstraction layer
• Framework (Serverless, Terraform)

Best Practice Serverless Architecture #

Fungsi Harus Kecil & Single Responsibility #

❌ Anti-pattern:

• Satu fungsi 1.000 baris

✅ Best practice:

• 1 fungsi = 1 responsibility

Stateless by Design #

❌ Jangan simpan state di memory

✅ Gunakan:

• Database
• Cache
• Object storage

Gunakan Event, Bukan Chaining Sync #

❌ Sinkron berantai:

API → Function A → Function B → Function C

✅ Event-driven:

Event → Queue → Function

Timeout & Retry Harus Explicit #

• Set timeout konservatif
• Gunakan retry dengan backoff
• Dead Letter Queue (DLQ)

Connection Management #

❌ Buka DB connection tiap request

✅ Reuse connection di global scope

Infrastructure as Code (IaC) #

Gunakan:

• Terraform
• CloudFormation
• Pulumi

Manfaat:

• Repeatable
• Versioned
• Audit-friendly

Security Best Practice #

• Least privilege IAM
• Secret di Secret Manager
• Jangan hardcode credential
• Validasi input (OWASP)

Observability is Mandatory #

Minimal wajib punya:

• Structured logging
• Metrics
• Tracing

Contoh metrics:

• Invocation count
• Error rate
• Duration
• Throttling

Anti-Pattern Serverless #

🚫 Serverless Monolith 🚫 Business logic + infra logic campur 🚫 Terlalu banyak sync call 🚫 Over-engineering untuk traffic kecil

Contoh Use Case Nyata #

Notification Service #

• Trigger: Queue
• Function: Kirim email / push

Image Processing #

• Trigger: Upload file
• Function: Resize, compress

Scheduled Job #

• Trigger: Cron
• Function: Cleanup data

Diagram Decision Tree: Apakah Problem Ini Cocok untuk Serverless? #

Gunakan decision tree berikut sebelum memutuskan menggunakan serverless. Ini penting untuk menghindari salah arsitektur sejak awal.

[ Mulai dari Problem / Use Case ]
            |
            v
Apakah workload bersifat EVENT-DRIVEN?
            |
     +------+------+
     |             |
    YA            TIDAK
     |             |
     v             v
Apakah request/traffic FLUKTUATIF?
     |             |
 +---+---+         |
 |       |         |
YA      TIDAK      |
 |       |         |
 v       v         v
Apakah durasi task < batas timeout?
 |       |   Apakah workload RUNNING TERUS?
 |       |         |
 |       |     +---+---+
 |       |     |       |
 |       |    YA      TIDAK
 |       |     |       |
 |       |     v       v
 |       |  ❌ Serverless   Pertimbangkan Container
 |       |                  (Cloud Run / ECS)
 |       |
 v       v
Apakah butuh STATE di memory?
 |       |
+--+--+  |
|     |  |
YA    TIDAK
|     |  |
|     v  v
|  Gunakan External State
|  (DB / Cache / Storage)
|     |
|     v
|  Apakah latency ultra-rendah (<10ms)?
|     |
| +---+---+
| |       |
|YA      TIDAK
| |       |
| v       v
|❌ VM / Bare Metal   ✅ SERVERLESS COCOK
|

Interpretasi Cepat #

✅ Serverless cocok jika:

• Event-driven
• Traffic naik-turun
• Task pendek
• Stateless
• Tidak butuh latency ekstrem

❌ Hindari serverless jika:

• Long-running process
• Stateful heavy workload
• Traffic konstan tinggi
• Latency sangat kritikal

Checklist Serverless Production-Ready #

• ✅ Stateless function
• ✅ Timeout & retry defined
• ✅ DLQ configured
• ✅ Logging & tracing aktif
• ✅ IaC digunakan
• ✅ Security principle applied

Kesimpulan #

Serverless adalah arsitektur yang sangat powerful jika digunakan pada problem yang tepat. Ia bukan silver bullet, tetapi memberikan:

• Kecepatan
• Skalabilitas
• Efisiensi

Dengan mengikuti best practice, serverless dapat menjadi fondasi sistem modern yang resilient, scalable, dan cost-effective.