Belajar Data Center Engineer - Cloud & Hybrid Integration

#Pendahuluan

Setelah di episode 13 kita menyiapkan payung DR, episode ini menjawab realitas 2026: hampir tidak ada organisasi yang 100% on-prem atau 100% cloud. Kebanyakan hidup di hybrid — sebagian beban di DC sendiri/colo, sebagian di public cloud, saling terhubung permanen. Peran Data Center Engineer berubah: kini ia juga merancang jembatan antara kedua dunia.

Kita susun kerangka keputusan (kapan apa), mekanisme interconnect privat lewat MMR, pola-pola desain hybrid yang lazim, lalu praktik membangun jalur VPN sebagai cadangan link privat.

#On-Prem, Colocation, atau Cloud?

Tiga model penempatan workload dengan trade-off berbeda:

Aturan praktis yang sering berhasil:

Baseline stabil 24/7   → colo/on-prem (biaya per unit lebih murah)
Burst & eksperimen     → cloud (bayar saat dipakai)
Data besar & I/O berat → dekat datanya (data gravity)
Regulasi data lokal    → on-prem/colo di yurisdiksi sesuai

Data gravity adalah gaya tak terlihat yang menggerakkan banyak keputusan: dataset 200 TB sulit dipindah — aplikasi yang butuh datanya justru yang mendekat. Inilah alasan hybrid bukan fase transisi, melainkan keadaan permanen.

#Interconnect Privat: Peran MMR dan Cross-Connect

Menyambung DC ke cloud ada dua cara besar: internet publik (VPN) atau interconnect privat. Jalur privat lahir di MMR (episode 2): provider cloud punya point-of-presence di banyak carrier hotel/data center; satu cross-connect fisik (sering fiber OM4/OS2 beberapa meter saja) menyambung patch panel kalian ke port mereka.

Manfaat jalur privat:

• Bandwidth deterministik — 1/10/100 Gbps terjamin, tidak bersaing dengan traffic internet.
• Latensi & jitter rendah — path pendek, hop minim.
• Keamanan transport — traffic tak melewati internet publik.
• Biaya data transfer biasanya jauh lebih murah daripada egress via internet.

Produk tipikalnya: Direct Connect (AWS), ExpressRoute (Azure), Cloud Interconnect (Google). Di sisi kalian, router DC ber-BGP ke edge cloud — routing dinamis, failover otomatis.

#Pola Desain Hybrid

Empat pola yang mencakup mayoritas kasus nyata:

1. Cloud burst — baseline di DC; saat puncak (campaign, batch analitik), overflow ke cloud. Syaratnya aplikasi stateless atau dengan replikasi data cepat.
2. DR ke cloud — tier DR warm-site diganti region cloud; lebih elastis daripada membangun gedung kedua. Menyatu dengan episode 13.
3. Data lake di cloud — produksi tetap di DC, telemetry/arsip dikirim ke object storage untuk analitik.
4. Landing zone enterprise — cloud diperlakukan seperti DC baru: network design (VPC/hub-spoke), IAM, logging, dan compliance ditetapkan lebih dulu, baru workload masuk.

#Praktik: VPN IPSec sebagai Jalur Cadangan

Link privat harus selalu punya rencana B. Standar de facto backupnya: IPsec site-to-site via strongSwan. Konfigurasi sisi DC (/etc/ipsec.conf):

config setup
    uniqueids=yes
 
conn to-cloud
    type=tunnel
    auto=start
    keyexchange=ikev2
    left=203.0.113.10          # ip publik dc
    leftsubnet=10.10.0.0/16    # lan dc
    leftfirewall=yes
    right=198.51.100.20        # gateway cloud
    rightsubnet=172.16.0.0/16  # vpc cidr
    ike=aes256gcm16-prfsha384-ecp384!
    esp=aes256gcm16-ecp256!
    ikelifetime=60m
    lifetime=20m
    dpdaction=restart
    dpddelay=30s

Poin pentingnya:

• auto=start — tunnel naik sendiri saat boot; jalur darurat tidak boleh butuh tangan manusia untuk bangun.
• dpdaction=restart — dead peer detection memulihkan tunnel mati secara mandiri.
• IKEv2 + AES-GCM — cipher suite modern; jangan warisi proposal usang.

Sisi routing, pastikan BGP privat (jika ada) lebih dipilih dan VPN hanya fallback — atau gunakan IPsec ini sebagai utama untuk workload non-kritikal. Uji failover sungguhan: matikan cross-connect di maintenance window, amati konvergensi, catat durasinya di dc-docs/network/failover-test.md.

Verifikasi tunnel dan trafik:

sudo swanctl --list-sas
ping -c 5 -I eth-vpn 172.16.5.20

#Jebakan Egress Cost

Biaya yang mengubah banyak keputusan hybrid: egress fee — biaya keluar data DARI cloud (masuk umumnya gratis). Konsekuensi arsitekturalnya:

Backup 50 TB di cloud, restore saat bencana:
Egress 50 TB x ±$0.08-0.12/GB ≈ USD 4.000-6.000
+ waktu transfer hari-an → RTO rusak

Pelajaran desainnya: data yang wajib cepat kembali (backup tier-0/1, database replika) sebaiknya direplikasi ke site kedua milik sendiri; cloud cocok untuk arsip dingin yang restore-nya sabar. Selalu modelkan biaya skenario bencana, bukan biaya kondisi normal saja.

#Common Pitfalls Hybrid

• Menganggap cloud otomatis HA — region cloud juga outage; desain multi-AZ/multi-region tetap tanggung jawab kalian.
• Latensi diabaikan — aplikasi chatty (ribuan query per transaksi) lintas-link WAN akan melambat drastis; ukur RTT sebelum menempatkan komponen.
• Security model terpisah dua dunia — identitas dan logging harus menyatu (SSO, central SIEM); dua standar = celah.
• Cross-connect tanpa dokumentasi — panel MMR yang tak tercatat adalah labirin saat vendor berganti teknisi.

#Penutup

Inti yang harus dibawa pulang:

• Hybrid adalah keadaan permanen; keputusan penempatan didasarkan baseline vs burst, data gravity, dan regulasi — tertulis dalam placement policy.
• Interconnect privat via cross-connect di MMR memberi bandwidth/latensi deterministik; internet VPN tetap wajib sebagai jalur cadangan.
• Empat pola utama: cloud burst, DR ke cloud, data lake, landing zone.
• Egress cost adalah pemungkas desain: modelkan biaya saat bencana, bukan hanya saat tenang.

Di episode 15 selanjutnya kita mengecilkan skala tapi memperbanyak titik: edge data centers — micro DC di ujung jaringan, use case CDN hingga MEC 5G, kendala operasi tanpa personel lokal, desain prefabricated modular, dan prinsip monitoring-first yang membuat puluhan edge site bisa dikelola tim kecil. Sampai jumpa di episode 15!