Belajar Infrastructure Engineer - Arsitektur Infrastruktur
Membedah arsitektur infrastruktur dari lapisan physical hingga platform, membandingkan on-prem vs cloud vs hybrid, memahami abstraksi dan trade-off di setiap lapisan, serta menyusun peta arsitektur untuk lingkungan sendiri
#Pendahuluan
Setelah di episode 1 kita memahami peran dan tanggung jawab Infrastructure Engineer, kini saatnya membangun alat berpikir paling penting dalam profesi ini: arsitektur infrastruktur. Arsitektur adalah bahasa umum yang dipakai untuk merancang, mendokumentasikan, dan mendiskusikan sistem — tanpa kerangka ini, setiap keputusan infrastruktur terasa acak.
Mengapa penting? Karena hampir semua keputusan engineering adalah trade-off antara tingkat abstraksi. Apakah beban kerja jalan di bare metal atau VM? VM atau container? Cloud publik atau on-prem? Jawabannya tidak pernah "selalu A", melainkan "tergantung". Episode ini memberi kalian kerangka untuk menjawab "tergantung apa".
#Lapisan Arsitektur Infrastruktur
#Lapisan 1: Physical
Fondasi paling bawah: server (rack), storage array, switch, router, UPS, pendingin, dan data center secara fisik. Di lapisan ini kita berbicara soal kapasitas fisik, redundansi hardware (PSU ganda, disk RAID, NIC teaming), dan rack layout.
Di lapisan ini juga muncul konsep hyperconverged infrastructure (HCI): menggabungkan compute, storage, dan networking dalam satu node modular — pola yang populer di 2020-an dan masih relevan di 2026.
#Lapisan 2: Virtualization
Hypervisor (KVM, Proxmox, ESXi) mengabstraksi hardware menjadi VM yang bisa di-create, di-resize, dan dipindah dengan mudah. Nilai utamanya: utilisasi (satu host dipakai banyak VM) dan portability (VM bisa dipindah antar host).
#Lapisan 3: Platform
Container runtime, Kubernetes, database managed, message broker — lapisan tempat beban kerja sebenarnya hidup. Di sinilah abstraksi paling tinggi: developer tidak perlu tahu di host mana pod berjalan.
Baca diagramnya dari bawah ke atas: setiap lapisan di atas menyembunyikan kompleksitas lapisan di bawahnya. Data center tidak perlu tahu bahwa aplikasi berjalan di container; aplikasi tidak perlu tahu berapa banyak disk yang dipakai server.
#On-Prem vs Cloud vs Hybrid
#On-Prem
Semua di tangan kalian: hardware, jaringan, pendingin, keamanan fisik. Kelebihannya kontrol total dan biaya tetap (capex) yang bisa diprediksi. Kekurangannya: lead time panjang (order server butuh berminggu-minggu) dan skalabilitas terbatas oleh apa yang kalian beli.
| Aspek | On-Prem | Cloud | Hybrid |
|---|---|---|---|
| Capex/Opex | Capex dominan | Opex dominan | Campuran |
| Scalability | Terbatas hardware | Hampir tak terbatas | Elastic (cloud) + tetap (on-prem) |
| Kontrol | Total | Bergantung provider | Kompromi |
| Compliance | Paling mudah dipenuhi | Perlu kajian | Paling fleksibel |
| Time-to-market | Lambat | Cepat | Sedang |
#Cloud
Compute, storage, dan network disewakan sebagai layanan API. Keunggulannya: elastic scalability, global reach, dan banyak managed service yang menghemat tenaga kerja. Kekurangannya: vendor lock-in, biaya tak terduga jika tidak dipantau (episode 24), dan kontrol terbatas di lapisan fisik.
#Hybrid
Menggabungkan keduanya: beban kerja yang sensitif atau legacy tetap on-prem, sementara yang elastis dan baru di cloud. Arsitektur hybrid 2026 tidak lagi sekadar "punya dua tempat" — ia harus punya koneksi terenkripsi yang andal (VPN/Direct Connect), identity yang federasi (episode 13), dan jaringan yang seragam.
Note
Aturan praktis: mulai dari kebutuhan. Data yang harus tetap di lokasi (regulasi, latensi) menentukan apa yang on-prem; beban yang naik-turun drastis menentukan apa yang cloud. Jangan mulai dari "gengsi cloud" atau "cinta on-prem" — mulai dari batasan, baru pilih teknologi.
#Abstraksi dan Trade-off
Setiap lapisan abstraksi menjual sesuatu dan memungut harga. Memahami kedua sisinya adalah inti arsitektur infrastruktur:
| Abstraksi | Keuntungan | Harga yang Dibayar |
|---|---|---|
| Bare metal | Performa penuh, tanpa overhead | Ops manual, migrasi susah |
| VM | Isolasi kuat, portability | Overhead hypervisor, boot lambat |
| Container | Ringan, cepat, reproducible | Isolasi lebih lemah dari VM |
| Managed service | Nol pemeliharaan | Biaya premium, kontrol terbatas |
Contoh nyata: database. Database self-managed di VM memberi kontrol penuh atas konfigurasi tetapi menuntut backup, patching, dan failover dikerjakan sendiri. Database managed (RDS, Cloud SQL) membebaskan semua itu tetapi memungut biaya lebih dan membatasi versi tertentu. Keduanya benar — tergantung skala tim dan keparahan dampaknya.
#Menyusun Peta Arsitektur
Sebagai praktik, buat peta arsitektur infrastruktur di lingkungan lab atau tempat kerja. Metode yang dipakai tim infra profesional:
- Inventori semua aset: server, VM, storage, perangkat network, database, layanan cloud.
- Kelompokkan per fungsi: web, app, database, cache, queue, storage, monitoring.
- Gambar alur data: dari user sampai ke database, lewat load balancer dan firewall.
- Tandai dependensi: layanan mana bergantung pada layanan mana.
- Tandai titik lemah: single point of failure, kapasitas kritis, komponen tanpa backup.
Hasilnya dokumen satu halaman yang menjawab "di mana sistem ini berjalan dan apa yang terjadi jika satu bagian mati". Contoh mapping sederhana:
| Fungsi | Teknologi | Lokasi |
|---|---|---|
| Load Balancer | Nginx | On-prem edge |
| Web | VM di Proxmox | On-prem |
| App | Container di K8s | Cloud (GKE) |
| Database | Managed PostgreSQL | Cloud (GCP) |
| Backup | Rsync + Object storage | On-prem → S3 |
Perhatikan pola hybrid: edge dan web di on-prem, sementara platform dan data di cloud. Ini adalah pola yang sangat umum di 2026.
#Common Pitfalls
- Over-abstraksi: membuat semua hal jadi container/microservice padahal bebannya sederhana. Container tidak menyembuhkan desain buruk.
- Bawah-abstraksi: mengelola 200 server manual karena "takut cloud mahal" — biaya tenaga kerja jauh lebih mahal.
- Tidak ada peta arsitektur: sistem berjalan di mana-mana tapi tidak ada yang tahu gambaran besarnya. Ini penyebab utama incident di menit-menit kritis.
- Mengabaikan data gravity: memindahkan aplikasi ke cloud tapi data tetap on-prem membuat koneksi lintas lokasi jadi bottleneck.
#Penutup
Pada episode 2 ini kalian telah membangun kerangka berpikir arsitektur infrastruktur:
- Empat lapisan: physical → virtualization → platform → aplikasi, masing-masing menyembunyikan kompleksitas di bawahnya.
- Tiga model: on-prem, cloud, hybrid — masing-masing dengan trade-off capex, kontrol, dan skalabilitas.
- Setiap abstraksi menjual kemudahan dan memungut harga: pilih sesuai kebutuhan, bukan gengsi.
- Peta arsitektur satu halaman adalah dokumen wajib setiap tim infra.
Di episode 3 selanjutnya kita masuk ke lapisan paling konkret: compute & servers — perbedaan bare metal, VM, dan container, cara mengelola lifecycle server, serta praktik memilih ukuran yang tepat. Sampai jumpa di episode 3!