Belajar Solution Architect - Cloud Solution Design

#Pendahuluan

Setelah di episode 4 kalian memilih gaya arsitektur secara objektif lewat weighted scoring matrix dan membekukannya dalam ADR, sekarang saatnya menurunkan keputusan itu ke desain fisik di cloud. Di sinilah kotak-kotak abstrak "app server" dan "database" berubah menjadi subnet, instance group, managed database, dan angka di invoice bulanan.

Mengapa level ini menentukan? Karena mayoritas insiden produksi bukan disebabkan kode yang jelek, melainkan desain infrastruktur yang salah asumsi: semua komponen di satu AZ, database tanpa failover, security group terbuka, atau autoscaling yang tidak pernah diuji. Desain fisik yang baik membuat kegagalan satu komponen tidak menjadi kegagalan sistem.

#Mulai dari Reference Architecture, Bukan Nol

Kesalahan pemula paling umum: mendesain dari kertas kosong padahal ketiga provider besar sudah menyediakan reference architecture yang teruji untuk pola-pola umum (web app, microservices, data lake, serverless web). Gunakan sebagai titik awal, lalu sesuaikan dengan requirement kalian:

Cara kerjanya yang benar: baca requirement → cari reference architecture terdekat → daftar penyimpangan kalian dari referensi → setiap penyimpangan harus punya alasan tertulis. Jika kalian tidak bisa menjelaskan mengapa menyimpang, ikuti saja referensinya.

#Well-Architected sebagai Checklist

Keenam pilar Well-Architected (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability) adalah checklist review gratis. Saat desain kalian selesai, lewati tiap pilar dan tanya: apa kontrol eksplisit kita di sini? Kolom kosong berarti risiko — tulis di bagian Risiko pada SDD.

#Mendesain VPC Multi-AZ yang Benar

Tulang punggung solusi cloud klasik adalah network design. Untuk aplikasi three-tier di AWS, pola standarnya begini:

Aturan-aturan yang harus dipatuhi:

• Minimal dua AZ untuk semua tier stateless dan stateful. Satu AZ berarti satu kegagalan datacenter meruntuhkan semuanya.
• App tier di private subnet — tanpa IP publik, akses keluar via NAT gateway.
• Database di subnet terpisah dengan route table sendiri, tidak ada route ke internet.
• Ukuran subnet rencanakan sejak awal (misal /24 per subnet); menambah CIDR belakangan merepotkan karena peering dan firewall lain ikut berubah.

Di Azure padananya VNet + subnet + Availability Zone; di GCP VPC bersifat global dengan subnet regional. Konsepnya identik: pisahkan tier, sebarkan zona, minimalkan permukaan publik.

#Infrastructure as Code Sejak Hari Pertama

Desain fisik modern wajib lahir dalam bentuk kode — bukan klik-klik console. Minimal untuk latihan series ini, definisikan jaringan dengan Terraform agar bisa direview seperti kode:

resource "aws_subnet" "app_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = "ap-southeast-3a"
  tags = { Name = "app-private-a", Tier = "app" }
}
 
resource "aws_subnet" "app_b" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.12.0/24"
  availability_zone = "ap-southeast-3b"
  tags = { Name = "app-private-b", Tier = "app" }
}

Manfaatnya ganda bagi SA: diagram kalian selalu sinkron dengan realita (IaC adalah sumber kebenaran), dan review arsitektur bisa dilakukan lewat pull request. Kedalaman IaC operasional dibahas di learn-cloud-engineer; di sini cukup kemampuan membaca dan menulis definisi level ini.

#Pola High Availability Standar

Untuk target availability 99,9%+ (ingat tabel episode 3), pola minimal yang harus ada:

• Load balancer di depan semua tier stateless, dengan health check aktif.
• Autoscaling berbasis CPU/target request — plus pre-warming sebelum event trafik dikenal (studi kasus tiket!).
• Managed database dengan failover otomatis: RDS Multi-AZ, Azure SQL zone redundant, atau Cloud SQL HA.
• State di layanan managed, bukan di disk instance: session di Redis, file di object storage. Instance boleh mati kapan saja tanpa kehilangan data.
• Multi-region hanya jika requirement menuntut — ingat, tiap sembilan tambahan mahal; region kedua biasanya baru masuk hitungan untuk target 99,99%+ atau kebutuhan DR ketat (episode 15).

#Estimasi Biaya Awal

Bagian yang paling sering ditunda padahal menentukan persetujuan solusi: estimasi biaya. Ketiga provider punya calculator resmi (AWS Pricing Calculator, Azure Pricing Calculator, GCP Pricing Calculator). Susun skenario tiga tingkat:

Skenario normal   : traffic harian rata-rata      -> Rp X/bln
Skenario puncak   : window sale 50k user serentak -> Rp Y/bln
Skenario idle/dev : environment non-produksi      -> Rp Z/bln

Lampirkan ke SDD bagian 5 beserta asumsi traffic-nya. Angka kasarnya tidak harus presisi — yang dinilai stakeholder adalah apakah kalian berpikir tentang biaya sejak desain, bukan setelah tagihan datang.

#Penutup

Inti yang harus dibawa pulang:

• Mulailah dari reference architecture resmi provider dan dokumentasikan setiap penyimpangan — jangan mendesain dari nol tanpa alasan.
• Network design dasar: multi-AZ, app tier privat, database di subnet terisolasi, ukuran CIDR direncanakan sejak awal.
• Desain fisik lahir sebagai kode (IaC) supaya bisa direview dan tetap sinkron dengan realita.
• High availability minimum: load balancer, autoscaling, database failover, state di layanan managed.
• Estimasi biaya tiga skenario adalah bagian dari desain, bukan lampiran belakangan.

Di episode 6 selanjutnya kita akan membahas integration architecture — cara menyambungkan solusi kalian dengan dunia luar: REST vs event streaming, pola integrasi enterprise, ETL, idempotency, dan desain kontrak API yang tahan lama. Sampai jumpa di episode 6!