Belajar Cloud Architect - Compute & Serverless Architecture

#Pendahuluan

Di episode 3 kita belajar bahwa setiap keputusan arsitektur adalah trade-off. Tidak ada topik yang lebih jelas menunjukkan ini selain pilihan compute — kategori resource paling dasar, paling mahal, dan paling menentukan cara kerja aplikasi.

VM, container, dan serverless bukan soal "mana yang terbaik" secara absolut. Masing-masing menang di kondisi berbeda. Arsitek yang baik membaca karakteristik workload — traffic, bentuk beban, kebutuhan state, keahlian tim — lalu memilih tipe compute yang paling masuk akal. Episode ini membangun kerangka berpikir itu.

#Spektrum Compute

#Virtual Machines (IaaS)

VM memberi kontrol penuh atas sistem operasi: kalian memilih OS, menginstall apa pun, mengatur networking secara detail. Ini adalah pola paling fleksibel dan paling kita kenal — tetapi juga paling banyak memberi tanggung jawab: patching OS, capacity planning, dan operasional server.

Cocok: legacy app, kebutuhan OS khusus, custom kernel,
       workload stateful, kontrol networking penuh.
Hindari: workload spike-y yang sering idle (boros biaya).

#Containers

Container memaketkan aplikasi dengan dependency-nya, berjalan di atas kernel host. Lebih ringan dari VM, deployment cepat, dan konsisten di semua environment. Arsitektur container membuka jalan ke Kubernetes dan pola deployment modern (episode 14).

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "index.js"]

Dockerfile di atas menunjukkan esensi container: aplikasi + environment = satu artefak. Image yang sama berjalan di laptop, staging, dan produksi — menghilangkan masalah "jalannya di mesin saya".

#Serverless (FaaS)

Serverless mengabstraksi server sepenuhnya. Kalian menulis fungsi, provider yang mengelola runtime, scaling, dan kapasitas. Billing berdasarkan eksekusi, bukan waktu server aktif — jadi biaya menuju nol saat idle.

export async function handler(event) {
    const order = JSON.parse(event.body)
    await saveOrder(order)
    return { statusCode: 201, body: JSON.stringify({ id: order.id }) }
}

Fungsi di atas adalah unit terkecil komputasi: tidak ada server untuk di-patch, tidak ada scaling yang harus diurus. Tetapi serverless juga punya trade-off: cold start, batas runtime, dan kesulitan menangani workload stateful atau jangka panjang.

#Tabel Perbandingan

#Pola Arsitektur Compute

#VM + Auto Scaling (Traditional)

Load balancer di depan sekelompok VM yang diskalakan otomatis berdasarkan metrik (CPU, request rate). Pola ini sederhana, terbukti, dan cocok untuk aplikasi stateful atau yang belum siap di-containerize.

#Container Platform (EKS/GKE/AKS)

Kubernetes mengelola container di banyak node: scheduler menempatkan pod, menangani scaling, dan menyembuhkan kegagalan. Ini adalah pola standar untuk aplikasi cloud-native (detail di episode 14).

#Event-Driven Serverless

Fungsi dipicu oleh event — queue, object storage, jadwal. Cocok untuk pipeline data, webhook, dan integrasi antar-service. Detail lengkap di episode 13.

#Praktik: Memilih Compute untuk Workload

Latihan desain: pilih compute optimal untuk tiga workload berbeda.

1. Legacy .NET app 5 tahun, dimiliki 1 tim kecil
   → VM (migrasi kontainer terlalu mahal tanpa benefit nyata)
 
2. API REST internal dengan traffic spikes tidak menentu
   → Container di Kubernetes (portabilitas + scaling)
   atau serverless jika stateless & rendah latensi cold start
 
3. Fungsi resize image ketika user upload
   → Serverless (event-driven, spike, idle → biaya nol)

Perhatikan alurnya: baca karakteristik workload → bandingkan aspek (kontrol, scaling, cost, ops) → pilih → dokumentasikan di ADR. Semua keputusan di episode ini seharusnya berujung pada ADR, persis seperti yang diajarkan episode 3.

#Penutup

Inti yang harus dibawa pulang:

• VM = kontrol penuh + operasional berat; container = portabilitas; serverless = biaya idle nol.
• Pilih per komponen, bukan per proyek — arsitektur sehat itu campuran.
• Cold start dan batas runtime adalah harga yang harus dibayar untuk serverless.
• Baca karakteristik workload sebelum memilih, lalu catat keputusan di ADR.

Di episode 5 selanjutnya kita akan membahas data architecture (storage & DB) — pola storage object/block/file, relational vs NoSQL, data lake & warehouse, dan arsitektur data end-to-end. Sampai jumpa di episode 5!