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

[GN⁺]

Komentar Hacker News

• Salah satu masalah terbesar dari biaya cloud (Cloud Tax) adalah bahwa hal itu secara artifisial membatasi cakupan solusi yang bisa dipikirkan para engineer. Misalnya, dengan membayar sekitar $200/bulan ke AWS, kita mendapat server 4 vCPU dan RAM 16GB, yang kurang lebih setara laptop pengembangan dari 5 tahun lalu. Sementara di Hetzner, dengan biaya yang sama kita bisa menyewa server 48 core dan RAM 128GB. Kesenjangan performa komputasinya sangat besar. Metodologi yang cukup efektif jika kapasitasnya 10 kali lebih besar jadi tidak berarti di node kecil. Kondisi seperti ini kadang juga menjadi cara untuk menghemat waktu engineering yang dibutuhkan untuk membangun sistem yang lebih rumit. Tentu ada pertimbangan lain seperti durabilitas, tetapi di sisi lain server dedicated menjamin performa yang konsisten tanpa kekhawatiran noisy neighbor
  • Pada 2025, untuk keperluan umum kita bisa memakai layanan seperti fly.io tanpa prosedur rumit, dan untuk framework tertentu juga ada opsi seperti Vercel (opsi bagus yang memang dioptimalkan untuk stack tertentu). Kalau butuh lebih dari itu, kita bisa menyewa mesin kelas monster sungguhan dengan murah di OVH/Hetzner/Latitude. Kalau cuma untuk menjalankan blog, pilihan VPS juga sangat banyak. Cloud tradisional sekarang praktis hanya dipakai untuk regulasi, proses internal perusahaan, atau inefisiensi. Rasanya produktivitas pengembang maupun harga per mesin itu nol. Kecuali tim benar-benar tidak punya batasan apa pun dan entah kenapa suka sistem perizinan ala DMV, node Intel yang berisik, margin mahal, dan dukungan buruk, sebagian besar sudah tidak masuk akal
  • Ini bahkan lebih dari itu—dengan memakai server bare metal, kita tidak perlu memikirkan latensi jaringan, latensi/pertentangan bandwidth memori pada VM, atau struktur caching terpisah; misalnya kita bisa memberi RAM sangat besar ke Postgres dan hanya mengandalkan caching disk Linux. Jauh lebih sederhana sekaligus lebih cepat
  • Saya tidak paham kenapa layanan kecil pun langsung diarahkan ke AWS. Saya tidak serumit Anda, tetapi klien saya memakai kombinasi webapp PHP kecil + AWS server/SQS/S3 dengan biaya $100/bulan. Saya membangunnya ulang dengan Python/Django/PostgreSQL (awalnya SQLite) lalu memindahkannya ke VPS $25/bulan. OCR PDF, pembaruan harga, pencarian produk yang hilang, layanan situs, semuanya berjalan baik di 4 core dan RAM 6GB. Ini aplikasi internal yang tidak akan punya jauh lebih dari 100 pengguna, jadi kalau nanti membesar pun migrasinya sangat mudah. Pada skala sekarang, tidak ada alasan memakai server AWS $100, setidaknya sampai benar-benar perlu skala besar
  • Sangat setuju. Dengan memakai database embedded seperti sqlite dan mengoptimalkan write batch, kita bisa melangkah sangat jauh hanya dengan Hetzner. Klaim soal "pemesanan kapasitas berlebihan lalu terbuang" tidak masuk akal begitu keluar dari AWS (value for money-nya beda kelas). Bahkan, makin kompleks sistemnya, kadang justru keandalan dan ketahanannya lebih buruk dibanding single node. Jarang ada situasi di mana hanya satu hal terisolasi lalu rusak sendiri
  • Saya justru berpandangan sebaliknya. Saya suka Hetzner untuk situs kecil, tetapi untuk proyek besar cloud terasa nyaris tanpa batasan. Kalau proyeknya cukup bernilai bagi waktu saya, biaya hosting $200 atau $2000 jadi tidak berarti. Saya juga tidak merasa ada perbedaan besar dalam waktu pengembangan antara AWS CDK/Terraform+GitHub Actions dan Docker/K8s/Ansible+pipeline CI. Saya tidak merasa pendekatan bare metal jauh lebih menghemat waktu engineering. IaC seperti Fargate+RDS juga nyaman. Kalau kita benar-benar butuh pemisahan, skalabilitas, dan durabilitas untuk file storage, atau pembuatan subdomain dinamis, atau perlu mengintegrasikan banyak layanan dedicated di berbagai lapisan infrastruktur, justru beban mempelajari dan mengintegrasikan layanan baru itu jauh lebih besar. Sebenarnya saya sudah melakukan hal seperti ini sejak sebelum era cloud, dan untuk proyek yang menghasilkan uang, saya rasa biaya cloud layak sebagai investasi. Kalau biayanya terasa terlalu membebani, mungkin itu lebih cocok disebut hobi daripada bisnis. Mengelola RAID atau berbagai clustered file system bukan sesuatu yang ingin saya lakukan dengan sumber daya startup/perusahaan biasa atau waktu saya sendiri. Rasanya seperti preferensi suka mengutak-atik Arch+Emacs versus puas dengan MacBook. Kalau Anda ingin mengganti scheduler kernel, saya akan bilang pakai Arch, kalau tidak ya saya sarankan MacBook. Di sisi lain, kalau benar-benar tidak ada anggaran dan yang dibutuhkan adalah raw throughput, saya juga pernah merasa server dedicated memang sangat tepat (menghemat ribuan dolar). Kalau proyeknya berhasil, mungkin setelah itu saya akan beralih ke vertical scaling, tetapi ini kasus yang jarang
• HN (Hacker News) menjalankan 2 server: satu untuk layanan produksi dan satu lagi untuk backup. Ini pola yang berguna karena memungkinkan failover seketika saat ada masalah hardware atau perlu upgrade. Namun, kalau kedua server itu benar-benar klon identik, ada risiko keduanya mati bersamaan
  • Tidak sefatal SSD, tetapi pernah juga ada error menarik pada CPU AMD. Setelah sekitar 1044 hari, core tertentu bisa benar-benar berhenti total kasus CPU AMD EPYC Rome Hang
  • Saya penasaran apakah ada statistik tentang downtime HN (Hacker News). Dalam 10 tahun terakhir saya cuma ingat satu atau dua kali down, jadi rasanya uptime-nya di atas 99,99%
• Saya sudah lebih dari 10 tahun memakai hybrid colo + public cloud, dan mulai dari skala tertentu itu selalu menjadi yang terbaik untuk optimasi biaya. Efisiensi hardware juga terus membaik. Kita memang butuh admin jaringan/infrastruktur, tetapi sekarang pengelolaannya sebenarnya sangat mudah dan, pada praktiknya, kita juga tetap butuh admin "cloud", jadi penghematan biaya tenaga kerja nyaris tidak ada. Opsi colocation beragam, dan penyedia biasanya menjual bandwidth dalam bundel. Saya pernah menjalankan 8 cluster Dell VRTX, SAN, dan 500+ VM (dari msSQL besar sampai kube); kalau itu dijalankan di public cloud, bahkan dengan diskon reservasi pun tagihannya akan menembus 6 digit. Sementara biaya colo saat itu hanya $2.400/bulan (didominasi biaya listrik). Penurunan kecepatan yang signifikan pada node public cloud juga selalu mengejutkan (meski generasi CPU/VCPU-nya sama). Memang perlu cermat soal deal perangkat, update, lisensi, dan kontrak dukungan, tetapi secara realistis semuanya bisa dikelola. Dan sekarang koneksi antara cloud dan jaringan juga mudah—tinggal pasang fiber drop lalu hubungkan ke VPC, selesai
  • Pemahaman saya, colocation itu berarti membeli hardware sendiri lalu menyewa listrik/rak/jalur koneksi di data center. Saya penasaran apakah memang begitu, dan apa kelebihannya dibanding menyewa server bare metal biasa
• Sudah bertahun-tahun saya membahas topik ini dengan teman-teman. Kekurangan terbesar infrastruktur lokal adalah kita perlu tenaga ahli yang benar-benar tahu cara mengoperasikannya dengan baik. Artikel ini fokus pada skala atas, tetapi di pasar bawah, kalau kita sudah punya sedikit perangkat, dengan rak kecil atau jaringan sederhana saja kita bisa balik modal dalam setahun. Dengan premi cloud saat ini, rasanya bahkan setelah mempekerjakan satu administrator pun infrastruktur lokal masih lebih ekonomis
• Di perusahaan tempat saya ikut mendirikan startup, kami membuat mesin otomasi enterprise, dan tim ingin mendistribusikan solusi itu sebagai SaaS untuk memaksimalkan pendapatan. Padahal sebenarnya skema DB multi-tenant + VPS sudah cukup, tetapi tim malah tenggelam mempelajari kubernetes dan stack cloud-native, lalu menghabiskan satu tahun penuh untuk lingkungan pengembangan dan otomasi operasional. Akhirnya perusahaan tidak bertahan lama dan bangkrut
  • Tetapi para engineer jadi punya pengalaman k8s di CV mereka, sehingga bisa membuka jalan ke pekerjaan berikutnya
  • Saya juga punya pengalaman serupa—terlalu banyak waktu terbuang untuk menyelesaikan lebih dulu masalah yang mungkin baru muncul 5 tahun lagi. Untuk kebanyakan proyek dan startup tahap awal, PaaS atau sekadar nginx+container docker saja sudah cukup. Nanti kalau benar-benar ada pain point, baru dipikirkan saat itu
  • Karena itu saya suka PaaS sampai "tagihannya benar-benar mulai terasa sakit". Bayar heroku/render/fly sambil fokus ke PMF (Product-Market Fit). Atau, ada juga jalur menghabiskan uang VC untuk K8s demi kesenangan server, lalu pindah kerja berulang ke pekerjaan berikutnya
• Banyak bisnis sebenarnya tidak sepenting itu. Orang sering stres berlebihan soal layanan yang berhenti berjalan, padahal layanan yang mereka tangani tidak sedemikian kritis. Bahkan jika lingkungan produksi hilang di siang hari, memang merepotkan, tetapi dunia tidak akan kiamat. Perusahaan seperti ini dulu bisa melayani 250 orang dengan server kantor yang sederhana, tetapi setelah dipindah ke cloud anggarannya justru meledak. Cloud memang luar biasa untuk tugas tertentu, tetapi selain itu banyak yang mendekati hype pemasaran. Namun banyak engineer terobsesi pada "skalabilitas sempurna", sehingga mencari arsitektur ideal alih-alih solusi yang cukup baik
  • Salah satu rekan tim yang dulu pernah bekerja dengan saya selalu berkata begini saat kerja: "Setidaknya kalau kita bikin kesalahan, tidak akan ada yang mati, jadi tak perlu terlalu khawatir." Dia pernah menangani pekerjaan dengan tanggung jawab jauh lebih besar, dan pola pikir itu sangat membantu dalam situasi sulit
• Saat membangun struktur kompleks demi mengejar target uptime 100%, kita justru sering membuat kesalahan yang menurunkan keandalan. Mayoritas bisnis sebenarnya mampu menoleransi downtime 1–2 jam sesekali, bahkan kehilangan data pun kadang masih bisa diterima. Kalau ekspektasi ini disampaikan sejak awal, kita bisa merekayasa sistem yang jauh lebih sederhana sekaligus lebih andal
  • Biayanya juga jauh lebih murah. Hanya saja, ekspektasi seperti ini sering tidak bisa diterima oleh eksekutif nonteknis (terutama kehilangan data hampir tidak pernah bisa ditoleransi). Engineer mungkin berkata mereka hanya mengelola lingkungan, tetapi dalam kenyataannya hal itu sulit dipisahkan, dan kalau terjadi kesalahan kita bisa terlihat tidak kompeten
• Artikel yang cukup bagus. Saat men-scale dengan pendekatan seperti ini (non-cloud), layak juga mempertimbangkan menambahkan CDN. Dengan CDN, kita juga mendapat efek WAF dan failover DNS. Namun, sedikit disayangkan karena pendekatan non-cloud berarti harus mengelola DB sendiri. Karena itu, mungkin masuk akal mempertimbangkan penyedia yang juga menawarkan DB cloud sebagai opsi, atau kalau arsitekturnya active/passive, node pasif bisa dijalankan lebih murah di cloud VM + autoscale. Harga sewa server sekarang benar-benar murah; VPS 4GB sekitar $6, dan bare metal quad-core 32GB di kisaran $90. Situs pembanding harga seperti serversearcher.com juga berguna
  • Saya pernah menjalankan Postgres di container Docker dan hanya melakukan backup berkala, dan tidak ada masalah berarti. Operasionalnya juga sederhana, jadi tidak ada yang benar-benar merepotkan
  • Di mesin tunggal, sqlite bisa memberi performa yang jauh lebih tinggi dan pengelolaan yang lebih mudah dibanding Postgres/MySQL
• Saya juga menjalankan layanan di VPS. Cloud sudah lama saya tinggalkan. Kalau proyek saya mulai menghasilkan uang, rencananya saya akan membeli perangkat lalu menaruhnya di colo. Cloud rasanya seperti aplikasi kencan—fase serunya sudah selesai, sekarang saya ingin melakukan sesuatu yang benar-benar produktif
  • Colo sendiri juga penuh masalah. Hardware mati karena gangguan listrik data center itu sangat umum. Ironisnya, listrik rumah saya justru lebih stabil. Kalau bisnisnya bukan tipe yang kehilangan ratusan juta rupiah hanya karena downtime beberapa menit, kebanyakan orang sebenarnya tidak masalah menjalankan server dari basement rumah. Banyak orang sangat melebih-lebihkan kebutuhan akan uptime 99.999% atau bandwidth besar. Colo juga tidak semurah yang dibayangkan. Tarif listrik data center sering lebih mahal daripada tarif listrik umum/bisnis maupun rumah tangga. Yang benar-benar murah hanyalah internet/fiber, dan sekarang di banyak negara koneksi bisnis 5–10Gbit bisa didapat sekitar 100 euro (dulu 1Gbit saja bisa lebih dari 2.000 euro)
• Terlepas dari analisis biaya atau kapasitas, tidak mudah melawan tren industri. Memang ada keuntungan nyata dari "tidak perlu memikirkan hardware sama sekali". Selain itu, ada juga pola pikir kuat bahwa capex (belanja modal) harus dihindari bagaimanapun caranya, karena hardware server menuntut biaya awal yang besar. Dan ketika region AWS mengalami gangguan, itu tidak terasa sebagai "kesalahan kita", sedangkan jika server internal gagal, rasanya seperti "kesalahan kita"
  • Keengganan ekstrem terhadap capex (belanja modal) hampir pasti dipengaruhi struktur pendanaan VC—kalau investor hanya menuntut pertumbuhan cepat, investasi awal seperti membeli server memang sulit dibenarkan secara logis. Sebaliknya, bisnis yang stabil biasanya bisa menyerap capex kecil tiap tahun tanpa masalah
  • Kita juga tidak selalu harus membeli hardware server—menyewa dari tempat seperti Hetzner sudah cukup. Saya ingin mendengar lebih jelas apa yang dimaksud dengan keuntungan "tidak perlu memikirkan hardware"
  • Pola pikir menghindari capex itu memang nyata. Siapa pun yang bisa memakai kalkulator akan tahu bahwa sekarang harga server sebenarnya tidak terlalu berarti bagi keseluruhan bisnis. Yang mahal justru "ruang" di sekitar server, jadi kebanyakan orang sebenarnya bukan menyewa server, melainkan menyewa ruang (rak/daya)
  • Pada akhirnya, yang benar-benar dibayar perusahaan adalah "abstraksi tanggung jawab". Para eksekutif perusahaan besar merasa tenang jika memilih solusi dari vendor besar seperti MS atau AWS
  • Kalau menyewa server bare metal, kita tidak perlu khawatir soal capex maupun maintenance