Belajar Backend Developer - Cloud Services Backend

#Pendahuluan

Setelah pipeline CI/CD di episode 15 siap, pertanyaan berikutnya: ke mana kode itu dideploy? Jawaban di 2026 hampir selalu cloud — bukan karena tren, tapi karena menyediakan sendiri server fisik berarti mengurus hardware, jaringan, listrik, dan keamanan data center. Cloud mengubah itu semua menjadi layanan yang bisa dipesan dan diskalakan.

Mengapa backend developer harus paham cloud? Karena hampir semua lowongan backend menyebut minimal satu cloud provider, dan keputusan "pakai layanan mana" menentukan biaya, ketersediaan, dan beban operasional tim. Episode ini memetakan tiga kategori layanan inti — compute, managed database, dan storage — dengan perbandingan AWS, GCP, dan Azure.

#Compute: Tempat Kode Berjalan

#1. VM (Virtual Machine)

Kontrol penuh atas OS — seperti menyewa komputer jarak jauh.

Cocok untuk: aplikasi legacy, kebutuhan kontrol penuh, workload yang tidak cocok di-container. Tapi kalian bertanggung jawab atas OS update, patching, dan keamanan VM sendiri.

#2. Container Service

Cara modern menjalankan image Docker (episode 14) tanpa mengelola server:

Cloud Run (GCP) dan Container Apps (Azure) adalah pilihan menarik: kalian beri image, platform yang menangani scaling otomatis hingga nol — kalian hanya membayar saat dipakai.

#3. Serverless / FaaS

Fungsi yang dijalankan per-event, tanpa memikirkan server sama sekali:

export async function handler(event: OrderCreatedEvent) {
  await sendOrderConfirmation(event.orderId)
  return { statusCode: 200 }
}

Cocok untuk event-driven: respon webhook, pemrosesan queue, trigger S3. Tidak cocok untuk API yang butuh koneksi persistent (WebSocket) atau workload CPU berat yang panjang.

#Managed Database: Beban Operasional Diambil Alih

Self-host PostgreSQL berarti kalian mengurus backup, replika, patching, dan failover. Managed database mengalihkan semua itu ke cloud:

Keuntungan yang langsung terasa:

• Backup otomatis dan point-in-time recovery.
• Replika untuk membaca dan failover otomatis.
• Patching dan upgrade tanpa downtime oleh provider.
• Monitoring bawaan untuk performa.

Biaya managed database lebih mahal dari self-host, tapi untuk produksi hampir selalu sepadan: satu backup yang hilang menghabiskan lebih banyak daripada selisih harga setahun.

DATABASE_URL=postgres://shop_user:...@shop-db.rds.amazonaws.com:5432/shop

#Object Storage: Rumah File

Image produk, file upload, dan backup memerlukan penyimpanan besar yang murah dan tahan lama. Object storage adalah standarnya:

Karakteristiknya: data disimpan sebagai objek (file + metadata + key), bisa diskalakan tak terbatas, dan murah per GB. File tidak disimpan di VM — aplikasi membaca/menulis lewat SDK:

import { PutObjectCommand, S3Client } from "@aws-sdk/client-s3"
 
const s3 = new S3Client({ region: "ap-southeast-1" })
 
await s3.send(new PutObjectCommand({
  Bucket: "shop-product-images",
  Key: `products/${productId}.jpg`,
  Body: buffer,
  ContentType: "image/jpeg",
}))

Object storage juga menjadi dasar static hosting (website statis) dan backup destination.

#Memilih Provider

Tidak ada "terbaik" — pilihan dipengaruhi ekosistem perusahaan, bahasa (Azure dekat .NET), dan tim. Konsepnya sama di semua provider: compute, managed DB, storage, dan network — yang berbeda hanya nama dan konsolnya.

#Praktik: Deploy Toko Online di Cloud

Arsitektur referensi yang realistis untuk sistem kita:

1. Compute: image Docker di ECS/Cloud Run dengan scaling otomatis.
2. Managed DB: PostgreSQL RDS/Cloud SQL untuk data inti.
3. Cache: ElastiCache/Memorystore (Redis managed) — episode 9.
4. Queue: SQS/Pub/Sub (managed) — episode 10.
5. Storage: S3/Cloud Storage untuk gambar produk.
6. Load balancer: ALB/TCP load balancer di depan compute — episode 21.
7. CDN: CloudFront/Cloud CDN untuk konten statis — episode 9.

User → CDN → Load Balancer → Container Service (auto-scale)
                              ├── Managed PostgreSQL
                              ├── Managed Redis
                              ├── Managed Queue
                              └── Object Storage

Semua komponen managed — tim fokus ke fitur, bukan operasional server.

#Common Pitfalls

#VM Berjalan 24/7 Tanpa Scaling

VM yang selalu hidup dan tidak di-schedule = uang terbakar untuk resource yang menganggur. Pakai container/scaling otomatis yang bisa turun ke nol.

#Database Tanpa Backup (atau Backup Tak Pernah Diuji)

"Backup jalan" ≠ "restore bisa". Uji restore secara berkala — backup tanpa restore teruji sama dengan tidak ada backup.

#Credential di Kode

ACCESS_KEY di repository = kebocoran. Pakai IAM role untuk service yang berjalan di cloud, dan simpan secret di Secret Manager (episode 17).

#Region yang Salah

Data center jauh dari user = latency tinggi (episode 9). Pilih region dekat mayoritas user; data di satu region biasanya tidak bisa sembarangan dipindah.

#Penutup

Episode 16 men-deploy backend ke cloud: tiga kategori compute (VM, container, serverless), managed database yang mengambil alih operasional, object storage untuk file, perbandingan AWS/GCP/Azure, dan arsitektur referensi toko online.

Inti yang harus dibawa pulang:

• Compute: VM untuk kontrol penuh, container sebagai standar, serverless untuk event.
• Managed database mengambil alih backup, replika, dan patching.
• Object storage (S3/Cloud Storage) untuk file dan backup.
• Provider berbeda, konsep sama — pilih berdasarkan ekosistem dan tim.
• Backup wajib diuji restore; pasang budget alert sejak awal.

Di episode 17 selanjutnya kita akan mengamankan seluruh lapisan: security backend — OWASP Top 10, input validation, dan pengelolaan secrets. Sampai jumpa di episode 17!