Belajar Infrastructure Engineer - Compute & Servers

#Pendahuluan

Setelah di episode 2 kita memahami arsitektur berlapis, sekarang kita turun ke lapisan paling konkret: compute. Compute adalah "otak" infrastruktur — tempat beban kerja benar-benar dieksekusi. Memilih dan mengelola compute dengan benar adalah keterampilan pertama yang membedakan infra engineer yang berpikir dari yang sekadar menjalankan perintah.

Mengapa topik ini penting? Karena sebagian besar biaya infrastruktur (dan sebagian besar downtime) berakar pada keputusan compute yang buruk: server terlalu kecil sehingga crash saat traffic naik, atau terlalu besar sehingga membuang uang bertahun-tahun. Episode ini membekali kalian kerangka memilih, menyediakan, dan mematikan server secara profesional.

#Tiga Bentuk Compute

#Bare Metal

Server fisik yang dipakai langsung tanpa virtualisasi. Cocok untuk beban yang butuh performa penuh (database besar, GPU/AI, aplikasi latency-critical) atau regulasi yang menuntut isolasi keras.

#VM (Virtual Machine)

Hypervisor membagi satu host fisik menjadi banyak VM. Standar industri untuk sebagian besar beban kerja karena isolasi dan portability-nya. VM punya overhead kecil (2-5%) tetapi memberi fleksibilitas yang sangat besar.

#Container

Bukan virtualisasi hardware — ia mengisolasi proses dan memakai kernel host yang sama. Hasilnya: jauh lebih ringan, boot hitungan detik, dan cocok untuk arsitektur microservice. Kekurangannya: isolasi lebih lemah, dan kalian tidak bisa menjalankan container dengan kernel berbeda.

Aturan praktis pemilihan:

#Lifecycle Server

Server yang baik adalah server yang lahir dari kode, hidup terpantau, dan mati terotomasi. Siklusnya:

#1. Provisioning

Server dibuat dari template/IaC — bukan manual. Di episode 8 kita otomasi penuh dengan Terraform. Untuk lab, buat VM dari template Proxmox/KVM agar konsisten:

qm clone 9000 101 --name web-01 --full

#2. Configuration

Setelah server ada, konfigurasi OS-nya: hostname, user, firewall, SSH hardening, timezone, dan paket dasar. Ini ranah Ansible (episode 8), tapi di lab bisa manual:

hostnamectl set-hostname web-01
timedatectl set-timezone Asia/Jakarta
apt update && apt upgrade -y

#3. Monitoring

Server yang hidup wajib terpantau: CPU, memory, disk, network, dan uptime. Mulai dari yang sederhana:

uptime
free -h
df -h
mpstat

Kita bangun monitoring penuh dengan Prometheus/Grafana di episode 9.

#4. Patching

Update keamanan adalah kewajiban berkala, bukan acara dadakan. Praktik standar: patch window terjadwal (misal bulanan), staging dulu sebelum produksi, dan rollback plan jika update merusak aplikasi.

#5. Decommissioning

Server yang tidak lagi dipakai harus dihapus, bukan ditinggalkan. Server zombie memakan biaya, risiko keamanan, dan membingungkan audit. Checklist decommission:

Checklist decommission server

1. Konfirmasi tidak ada beban yang bergantung padanya
2. Hentikan layanan & matikan server
3. Pindahkan/last backup data penting
4. Hapus dari DNS, monitoring, dan inventory
5. Hapus config IaC/Ansible yang merujuknya
6. Hapus VM / format disk

#Memilih Ukuran yang Tepat

Kesalahan paling umum pemula: menebak spesifikasi. Pendekatan yang benar adalah ukuran berbasis pengukuran:

1. Ukur baseline: jalankan beban aktual dan pantau peak-nya (misal selama seminggu).
2. Cadangan headroom: sisakan 20-30% untuk spike, jangan rancang pas-pasan.
3. Hitung per metrik: CPU untuk compute, RAM untuk memory-bound, IOPS untuk database, bandwidth untuk transfer-heavy.

Contoh perhitungan sederhana untuk web server:

Traffic puncak     : 5.000 request/detik
CPU per request    : 0,1 core-detik
Kebutuhan CPU      : 5.000 × 0,1 = 500 core-detik/detik = 500 core?? 

Tunggu — perhitungan itu salah. Contoh yang benar: jika 1 request butuh 10ms CPU dan ada 5.000 req/detik, total CPU = 50 core-detik per detik = 50 core. Artinya butuh ~50 core, atau 2-3 server besar. Pelajaran di sini: hitung, jangan menebak, dan selalu konfirmasi dengan pengukuran nyata — asumsi selalu menipu.

#Common Pitfalls Compute

• Overprovisioning: menyewa server 32-core untuk beban yang nyatanya butuh 4-core. Banyak perusahaan membuang 30-40% biaya cloud untuk compute idle (kita optimalkan di episode 24).
• Server zombie: server mati tapi tidak pernah dihapus, tetap ditagih.
• Patch menumpuk: server yang tidak pernah di-update adalah bom waktu keamanan.
• Mengabaikan swap/disk space: aplikasi crash diam-diam karena disk penuh adalah penyebab incident paling umum di seluruh industri.

#Penutup

Pada episode 3 ini kalian telah menguasai fondasi lapisan compute:

• Tiga bentuk compute — bare metal, VM, container — dengan trade-off performa, isolasi, dan kemudahan ops.
• Lifecycle server lengkap: provisioning → configuration → monitoring → patching → decommissioning.
• Ukuran server dipilih berbasis pengukuran dan perhitungan, bukan tebakan.
• Server zombie dan disk penuh adalah dua musuh diam-diam terbesar.

Di episode 4 selanjutnya kita pindah ke lapisan penyimpanan: storage architecture — perbedaan block/file/object storage, RAID, dan storage protocol seperti iSCSI dan NFS. Sampai jumpa di episode 4!