Belajar Software Architect - Cloud-Native Architecture

#Pendahuluan

Setelah di episode 13 kalian menguasai event-driven architecture — Kafka, delivery semantics, outbox, dan event sourcing — pada episode ini kita naik satu lapis ke infrastruktur eksekusi: cloud-native architecture.

Perlu diluruskan sejak awal: cloud-native bukan berarti "aplikasi yang dipindah ke cloud". Aplikasi monolitik yang di-lift-and-shift ke EC2 tetap bukan cloud-native. Cloud-native adalah properti desain: aplikasi yang diasumsikan elastis, sekali-jalan (disposable), dan dikelola lewat API deklaratif. Dua sistem bisa berjalan di provider sama; hanya satu yang benar-benar memanfaatkan awan.

#12-Factor App: Fondasi yang Masih Relevan

Metodologi 12-factor lahir 2011 di Heroku, dan mengejutkan banyak orang: lebih dari satu dekade kemudian ia masih menjadi ujian kelayakan aplikasi untuk dunia container & serverless. Faktor-faktor paling struktural:

Tiga faktor sering dilanggar diam-diam: config tertanam di application.yml per environment (melanggar build-once), log ditulis ke file lokal (hilang saat pod mati), dan graceful shutdown tidak diimplementasikan sehingga setiap deploy memutus request aktif.

#Container: Unit Packaging Modern

Container membungkus aplikasi + dependensi menjadi image immutable. Bagi architect, tiga keputusan penting:

#Image Discipline

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev=false
COPY . .
RUN npm run build
 
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/main.js"]

Aturan yang menjaga kualitas image: multi-stage build agar compiler tidak ikut ke runtime; base image minimal (alpine/distroless) memperkecil permukaan serangan; tag latest dilarang di produksi — deploy selalu pin digest spesifik agar rollback deterministik; dan image wajib discan kerentanan di CI (diperdalam episode 19 tentang supply chain).

#Registry & Promosi

Satu image dibangun sekali (build-release-run), lalu dipromosikan antar environment hanya dengan mengganti config. Membangun ulang image per environment adalah sumber klasik bug "tapi di staging jalan".

#Kubernetes dari Mata Architect

K8s adalah API deklaratif atas datacenter: kalian menyatakan state yang diinginkan, controller yang mengejar. Konsep inti yang wajib dipahami architect (bukan detail operasionalnya):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ordering-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: registry.acme.io/ordering@sha256:abc123
          resources:
            requests: { cpu: "500m", memory: "512Mi" }
            limits:   { cpu: "1",    memory: "1Gi" }
          readinessProbe:
            httpGet: { path: /health/ready, port: 8080 }

Pemetaan konsep ke masalah yang sudah kalian pelajari:

• Deployment + HPA = mesin horizontal scaling dari episode 11.
• readinessProbe/livenessProbe = disposability 12-factor; traffic hanya ke instance siap.
• ConfigMap/Secret = faktor config; secret terintegrasi vault/provider (episode 10).
• Service + Ingress = load balancing L7 dan routing.
• Resource requests/limits = bulkhead resource; tanpa ini satu pod rakus merampas tetangganya.

Keputusan build vs buy juga urusan architect: managed K8s (EKS/GKE/AKS) vs alternatif lebih tipis (ECS/Fargate, Fly.io, Nomad). K8s layak ketika tim punya kapabilitas platform dan kebutuhan multi-workload; untuk satu aplikasi kecil, kompleksitas kontrol-plane-nya belum dibayar.

#Serverless: Sewa Eksekusi Per Permintaan

FaaS (Lambda, Cloud Functions) menukar kontrol dengan kenyamanan operasional:

Model biayanya jujur untuk pola trafik tertentu: fungsi yang dipanggil sporadis (webhook malam hari, generate laporan mingguan) hampir gratis; fungsi steady high-throughput justru lebih mahal daripada container yang selalu hangat — hitungannya akan kita rapikan di episode 17 tentang cost architecture.

#Praktik: Keputusan Cloud-Native Studi Kasus

Mari terapkan pada e-commerce kita dengan analisis per workload:

Monolith core (API + worker)
  → Container di managed K8s
  → alasan: jalur checkout latency-kritis, butuh pre-scaling
     terjadwal flash sale (episode 11), koneksi pooling persist
 
Inventory service (hasil ekstraksi ep12)
  → Container, HPA custom metric queue-depth
 
Image resize produk (sporadis, CPU-bound)
  → FaaS triggered by object storage event
  → idle = Rp0, spike upload otomatis terserap
 
Laporan penjualan mingguan (batch, toleran lambat)
  → FaaS / scheduled job
  → tidak layak bayar instance standby 24/7
 
Webhook payment gateway
  → tetap di monolith core: jalur uang, idempotency
     & audit butuh akses penuh modul payment

Pola yang muncul adalah hybrid pragmatis: inti transaksional di container yang dikontrol penuh, workload sporadis di serverless. Ini konsisten dengan seluruh keputusan sebelumnya — pre-scaling episode 11 hanya mungkin di container, sementara biaya nol-saat-idle hanya mungkin di FaaS.

Checklist 12-factor untuk monolith kita juga dievaluasi: config via env ✓, logs ke stdout dikumpulkan Loki ✓, graceful shutdown SIGTERM ✓, health endpoints ✓ — artinya aplikasi siap hidup di orchestrator mana pun.

#Kesalahan Umum

• Lift-and-shift lalu mengaku cloud-native — VM besar yang jarang direstart, config tertanam, scale manual: biaya cloud, mentalitas datacenter.
• Serverless semua hal — jalur latency-kritis dan stateful workflow dipaksakan FaaS; cold start dan orkestrasi manual jadi hutang harian.
• Kubernetes untuk satu aplikasi kecil — kompleksitas operasional melebihi nilai; PaaS/container platform sederhana lebih jujur.
• Tag latest di produksi — deploy tak reproducible, rollback jadi tebak-tebakan.
• Logs ke disk pod — hilang bersama instance; logging adalah tanggung jawab platform, aplikasi cukup memancarkan stream.
• Lupa graceful shutdown — deploy tiap sore memutus request pengguna; disposability butuh SIGTERM handler.

#Penutup

Inti yang harus dibawa pulang:

• Cloud-native = desain untuk elastisitas, disposability, dan API deklaratif — lokasi server bukan penentu.
• 12-factor masih menjadi ujian portabilitas paling murah; tiga pelanggaran favorit: config tertanam, log ke file, shutdown kasar.
• Container dengan disiplin (multi-stage, pin digest, scan) adalah unit packaging standar.
• K8s dipahami sebagai pemenuhan kebutuhan yang sudah kalian rancang: scaling, probe, config, bulkhead; pakai bila kompleksitasnya terbayar.
• Serverless unggul untuk beban sporadis; mahal untuk throughput steady dan buruk untuk latency-kritis.
• Studi kasus: hybrid pragmatis — core di K8s dengan pre-scaling, FaaS untuk image & laporan.

Di episode 15 selanjutnya kita kembali ke pilihan style episode 3 dengan lensa lebih tajam: modular monolith & evolusi — kenapa pendekatan ini mendominasi 2026, bagaimana menjaga modulnya sehat, dan jalur evolusi bertahap ke services tanpa rewrite. Sampai jumpa!