Gunakan Satu Server Besar (2022)

• Inti perdebatan bukanlah monolitik vs mikroservis, melainkan apakah sistem terdistribusi sepadan dengan nilai yang diberikannya dibanding overhead pengembangan/operasional
• Server tunggal modern memiliki puluhan hingga ratusan core, memori kelas TB, dan I/O puluhan hingga ratusan Gbps, sehingga mempunyai cadangan performa yang cukup untuk menangani sebagian besar layanan web
• Benchmark nyata menunjukkan bahwa satu server dapat memberikan pemrosesan berperforma tinggi seperti Nginx 500 ribu RPS, PostgreSQL 70 ribu IOPS, NoSQL 1 juta IOPS, encoding 4K 75 FPS
• Menggunakan cloud meningkatkan kemudahan dan ketersediaan, tetapi premi biayanya besar sehingga efisiensi terhadap investasi perlu dihitung cermat
• Hanya ketika pola penggunaan sangat fluktuatif arsitektur cloud-native dan serverless memberi keuntungan biaya
• Namun premi biaya konfigurasi serverless/micro VM besar, dan jika beban kerja berkelanjutan/dapat diprediksi, maka vertical scaling lebih ekonomis
• Ketersediaan dapat sangat banyak diatasi dengan redundansi primer/sekunder (atau 2×2) dan kombinasi hardware yang berbeda, dan strategi yang masuk akal adalah membeli distribusi hanya untuk CDN dan backup

---

Gambaran umum: nilai dari “satu server besar” dibanding sistem terdistribusi

• Inti perdebatan “monolithic vs. microservices” adalah menilai apakah pengadopsian sistem terdistribusi benar-benar layak terhadap waktu developer dan biaya yang dikorbankan
• Perangkat lunak modern berjalan di atas virtualisasi server dan berbagai lapisan abstraksi, dan bahkan “serverless” maupun “bare metal” pada akhirnya dibangun di atas sumber daya server fisik
• Server masa kini memiliki efisiensi biaya terhadap performa yang jauh lebih tinggi daripada yang dibayangkan banyak orang
  • Dibanding masa lalu, spesifikasi server telah melonjak dalam hal jumlah core, bandwidth memori, lane PCIe, dan penyimpanan NVMe, sehingga banyak layanan dapat mencapai target QPS tanpa perlu distribusi

Performa kuat dari hardware server

• Server contoh dari Microsoft Azure memiliki konfigurasi 2 CPU server AMD generasi ke-3, total 128 core dan 256 thread
• Satu server dapat mencapai performa komputasi sekitar 4 TFLOPs, melampaui performa superkomputer awal tahun 2000-an
• Dengan 16 slot DDR4-3200 per soket RAM, skalabilitas memori mencapai maksimal 8TB, dan bahkan di pasar pembelian praktis tersedia dukungan memori 1TB
• Total ada 128 lane PCIe Gen4, serta koneksi storage dan jaringan berperforma tinggi melalui 30 SSD NVMe dan kartu jaringan 50~100Gbps

Hal-hal yang bisa dilakukan dengan satu server seperti ini (mengutip benchmark)

• Dapat mencapai transfer video 400–800 Gbps, NoSQL 1 juta IOPS, PostgreSQL 70 ribu IOPS, dan Nginx 500 ribu RPS
• Juga menunjukkan throughput tinggi pada pekerjaan intensif CPU, memori, dan I/O seperti build kernel Linux dalam 20 detik dan encoding x264 4K 75FPS

Perbandingan biaya sewa dan pembelian server

• OVHCloud: server 128 core/512GB RAM dapat disewa sekitar $1,318 per bulan
• Hetzner: menyediakan server 32 core/128GB RAM seharga €140 per bulan, dengan harga berbeda tergantung ukuran
• AWS m6a.metal: server 96 core fisik/768GB RAM seharga $8.29 per jam, sekitar $6,055 per bulan, menunjukkan premi cloud yang besar
• Jika membeli langsung server dengan spesifikasi serupa dari Dell, biayanya sekitar $40,000, dan modal dapat kembali dibanding cloud dalam sekitar 8 bulan
• Jika mengasumsikan throughput yang sama dengan serverless, diperkirakan ada premi biaya 5,5 kali dibanding instance dan 25 kali dibanding hosting murah

Mengapa sistem terdistribusi sempat begitu populer

• Di masa lalu (sekitar 2010), keterbatasan performa CPU, memori, dan storage membuat layanan berskala besar memerlukan gabungan beberapa server
• Belakangan, server tunggal besar, SSD NVMe, dan bandwidth memori tinggi sangat meningkatkan batas pemrosesan satu node, tetapi unit VM dan container masih didesain berdasarkan sumber daya server yang relatif kecil

Ketika satu server besar saja sudah cukup

• Sebagian besar layanan web di bawah 10k QPS cukup dengan satu server, dan layanan sederhana bahkan bisa mencapai skala jutaan QPS
• Bahkan untuk streaming video, control plane pada satu server tetap realistis, dan ukuran server yang tepat dapat dihitung melalui benchmark dan tabel performa umum
• Di luar situasi khusus, ketersediaan juga cukup dijamin hanya dengan konfigurasi server utama dan backup

“Lebih tinggi” daripada “lebih lebar”: memilih sedikit server besar dibanding banyak server kecil

• Bahkan bila cluster diperlukan, beberapa server besar memiliki overhead koordinasi O(n) yang lebih rendah dibanding banyak server kecil
  • Artinya, dalam jangka panjang lebih efisien mengurangi jumlah server dan menaikkan spesifikasinya
• Pada serverless dan lingkungan berbasis container berumur pendek, proporsi overhead ini menjadi lebih besar
• Kekurangannya adalah single point of failure, tetapi ini bisa banyak diatasi hanya dengan konfigurasi primer/sekunder (DC berbeda)
• Agar lebih tangguh, gunakan konfigurasi 2×2 (2 server di DC utama + 2 server di DC cadangan) dan penyebaran hardware/pabrikan yang berbeda untuk menghindari kegagalan berkorelasi
• Saat menyewa, mendiversifikasi model server dapat menurunkan risiko kegagalan berantai pada disk atau SSD dari batch yang sama

Kelebihan dan batas penggunaan cloud

• Cloud unggul dalam ketersediaan, kecepatan pemulihan, dan kemudahan operasional, sehingga layak dibayar dengan premi biaya
  • Dapat melakukan restart cepat dalam batas biaya tanpa mengalami downtime, serta memanfaatkan pool sumber daya besar yang dikelola seperti grid
  • Penyedia server sewaan memang lebih murah, tetapi memiliki keterbatasan dalam hal kualitas, jaringan, dan dukungan premium
• Namun, penjualan cloud cenderung mendorong arsitektur yang bergantung vendor seperti VM autoscaling, serverless, managed HA DB, sehingga biaya dan kompleksitas perlu diwaspadai
• Menangani trafik besar itu sendiri bukan alasan utama memilih cloud-native, dan ada banyak contoh server tunggal besar yang tetap mampu melayani jutaan pengguna secara bersamaan

Biaya beban puncak dan kriteria beban bursty

• Seseorang tetap harus menyiapkan kapasitas untuk puncak, sehingga pada akhirnya biaya puncak akan ditagihkan di suatu titik dalam rantai pasok
• Untuk pekerjaan bursty dan sementara (misalnya simulasi besar sekali jalan), serverless/autoscaling ekonomis, tetapi untuk beban berkelanjutan dan dapat diprediksi, operasi tetap dengan server besar lebih efisien dari sisi biaya
• Dengan memanfaatkan kontrak 1 tahun/spot/negosiasi penjualan, biaya instance bisa turun lebih jauh, dan premi dibanding serverless menjadi makin besar

Evaluasi kuantitatif atas “premi cloud”

• Serverless computing seperti AWS Lambda dapat menimbulkan premi biaya 5 hingga 30 kali dibanding server yang setara
• Asumsi: jika server $8.2944/jam menyediakan 1k QPS, 768GB RAM, maka mengganti throughput yang sama dengan Lambda akan menelan biaya sekitar $46/jam, yaitu premi 5,5 kali
• Diperkirakan ada premi 25 kali dibanding sewa OVH, dan bahkan pada utilisasi 5% sekalipun, hosting murah masih lebih ekonomis daripada serverless
  • Jika memanfaatkan kontrak jangka panjang, instance spot, dan sebagainya, selisih premi bisa lebih besar lagi
• Sekalipun QPS berbeda, melalui konversi memory-time kelipatan premi tetap mirip, dan kuncinya adalah menskalakan server sesuai ukuran workload

Sanggahan dan kesalahpahaman yang umum

• “Kalau pakai cloud, tidak perlu personel operasi sistem”: yang berubah hanya nama peran menjadi Cloud Ops; tetap dibutuhkan kemampuan dokumentasi, pelacakan perubahan, dan penanganan deprecation, sehingga justru bisa menaikkan biaya tenaga kerja
• “Di cloud tidak perlu update keamanan”: sebagian memang ditangani, tetapi terbatas pada area yang mudah diautomasi; audit library dan verifikasi konfigurasi tetap diperlukan
• “Cloud aman karena dirancang high availability”: kompleksitas yang meningkat menciptakan kerentanan baru, dan bahkan redundansi lintas region maupun provider tidak sepenuhnya menghilangkan kegagalan berkorelasi
• “Cloud mempercepat pengembangan”: kelincahan awal memang kelebihan yang layak dimanfaatkan, tetapi titik belok biaya perlu dipantau agar transisi di waktu yang tepat bisa dilakukan
• “Trafik kami sangat bursty”: dalam kasus ini, serverless dan autoscaling memang cocok
• “Bagaimana dengan CDN?”: pengurangan latensi dan bandwidth adalah target distribusi yang wajib dibeli, dan backup juga termasuk area yang layak dibeli sebagai layanan

Monolitik vs. mikroservis dan struktur server

• “Server besar” memang terkait dengan arsitektur monolitik, tetapi satu server juga tetap bisa menjalankan mikroservis dalam bentuk beberapa container
  • Namun overhead komunikasi antarproses, deployment, dan observabilitas tetap menjadi beban bahkan pada satu host, sehingga keuntungan performa nyata dibanding kompleksitas menjadi jauh berkurang
• Untuk skala awal hingga menengah, monolitik atau sejumlah kecil layanan lebih unggul dari sisi kesederhanaan operasional

Kesimpulan

• Dalam sebagian besar kasus, memilih vertical scaling (satu server besar) lebih sederhana dan ekonomis daripada horizontal scaling atau arsitektur berpusat pada cloud
• Dengan menggabungkan redundansi primer/sekunder, hardware heterogen, dan eksternalisasi CDN/backup, kita dapat memperoleh keandalan yang praktis untuk kebutuhan nyata, sekaligus unggul dalam total cost of ownership (TCO) pada lingkungan dengan beban berkelanjutan
• Selama tersedia strategi redundansi hardware yang kokoh, pendekatan “satu server besar” adalah pilihan yang sangat cocok untuk layanan nyata