- Pengalaman seorang developer yang memindahkan infrastruktur dari AWS ke server sendiri dan memangkas biaya infrastruktur bulanan hingga sepersepuluh, dari $1.400 menjadi $120 per bulan sambil mendapatkan performa server yang lebih kuat
- Server bare metal yang ditawarkan penyedia seperti Hetzner berharga sekitar $190 per bulan untuk 80 core, 7–18 kali lebih murah dibanding instance AWS dengan spesifikasi serupa
- Alasan para engineer cloud menentang pengelolaan server sendiri adalah karena keamanan kerja dan ketergantungan pada infrastruktur yang kompleks, sementara beban biaya nyata ditanggung oleh perusahaan
- Sebagian besar bisnis kecil tidak membutuhkan fitur kelas enterprise seperti high availability, replikasi multi-zone, atau failover otomatis, dan satu server saja sudah bisa menangani jutaan request per hari
- Pengelolaan server cenderung stabil setelah konfigurasi awal, dan dengan bantuan alat AI, hambatan masuk untuk mengelola server Linux kini lebih rendah daripada sebelumnya
Contoh penghematan biaya cloud
- Baru-baru ini semua proyek dipindahkan keluar dari cloud, menghasilkan pengurangan biaya AWS bulanan hingga 10 kali lipat dan penghematan ribuan dolar
- Tagihan AWS bulanan turun dari sekitar $1.400 menjadi kurang dari $120
- Mendapatkan infrastruktur server yang lebih kuat dengan biaya lebih rendah
- Performa meningkat 2 kali lipat dan terbebas dari vendor lock-in
- Setelah tweet ini viral, ada dua temuan: banyak developer tertarik pada caranya, dan banyak lainnya menunjukkan penolakan keras serta sikap konfrontatif terhadap ide ini
- Dari sudut pandang bisnis, penghematan biaya 10 kali lipat, peningkatan performa 2 kali lipat, dan lepas dari vendor lock-in adalah keuntungan yang jelas, tetapi tetap memicu reaksi keras
Kepentingan para pendukung cloud
- Sebagian besar orang yang menentang memiliki kata kunci seperti "devops", "cloud engineer", "serverless guy", "AWS certified" di profil mereka
- Mereka tidak menjalankan proyek mereka sendiri di cloud, dan tidak membayar sendiri biaya cloud tersebut
- Mereka tidak peduli pada tagihan AWS perusahaan, dan tidak merasakan langsung sakitnya ketika ribuan dolar terbuang setiap bulan
- Mengapa AWS nyaman bagi mereka
- Secara teknis terlihat rumit sehingga membuat mereka tampak pintar di depan developer lain
- Menciptakan efek ketergantungan dan lock-in sehingga mereka terasa tak tergantikan sebagai karyawan
- Karena penggunaan cloud menjamin gaji yang tinggi, mereka tidak punya insentif untuk mengambil keputusan yang efisien bagi bisnis
- Justru semakin rumit dan sulit dipahami infrastruktur bisnis, semakin aman posisi pekerjaan mereka
- Mereka tidak akan mengatakan kebenaran bahwa server sebenarnya murah
Opsi sewa server murah
- Pindah ke Hetzner (tanpa afiliasi, hanya menawarkan server murah)
- Bisa menyewa server bare metal 80 core dengan harga di bawah $190 per bulan
- Instance AWS seri C5-C6 dengan spesifikasi serupa berharga $2.500–$3.500 per bulan, 13–18 kali lebih mahal
- Bahkan dengan reserved instance, biayanya masih sekitar $1.300 per bulan, tetap 7 kali lebih mahal, dan perlu pembayaran di muka $46.000 serta kontrak 3 tahun
- Opsi VPS juga menarik
- Mesin 48 vCPU tersedia seharga $300 per bulan, tanpa biaya setup atau kontrak jangka panjang, dengan fleksibilitas penuh
- Mesin 8 core, RAM 32GB seharga $50 per bulan, cukup untuk menjalankan semua proyek sekaligus kecuali jika harus menangani jutaan request per hari
Membeli server dan memanfaatkan data center
- Dalam jangka panjang, membeli server lebih murah
- Bisa membeli server rack-mount dengan 44 CPU, RAM 256GB, dan SSD NVMe 2TB dengan harga di bawah $1.000
- Dengan harga lebih murah dari biaya cloud bulanan, aplikasi bisa dijalankan selama bertahun-tahun
- Opsi menyewa ruang rack di data center
- Bisa menyewa cage data center atau ruang rack bersama yang menyediakan listrik, internet, pendinginan, dan keamanan
- Bisa mencari data center lokal lewat situs seperti DatacenterMap
- Untuk developer kecil, ini terlalu rumit
- Perlu merekrut engineer, bernegosiasi soal harga, dan melalui proses yang merepotkan
- Umumnya ditujukan untuk perusahaan menengah hingga besar, sehingga tidak praktis untuk tim kecil
- Pada praktiknya sama saja dengan menyewa server yang sudah dipasang oleh penyedia seperti Hetzner, sambil mengurangi beban pengelolaan hardware
Bantahan terhadap kritik "bukankah itu masih cloud?"
- Kritik paling umum: "Bukankah itu masih cloud?" atau "Kamu tidak keluar dari cloud, cuma ganti penyedia cloud"
- Kritik ini meleset dari inti persoalan
- Yang penting adalah nilai dari mengelola server sendiri vs menganggap cloud sebagai default
- Menjalankan mesin Linux kecil untuk menggantikan layanan terkelola mahal seperti RDS bisa memangkas biaya 10 hingga 100 kali
- Sebagian besar developer takut pada server, padahal mereka hanya butuh sedikit dorongan untuk sadar bahwa server sendiri bisa dikonfigurasi dengan murah
- Di dunia nyata, hampir tidak ada yang benar-benar membutuhkan layanan terkelola cloud yang mahal; beberapa box Linux dengan software biasa sudah cukup
- Perdebatan soal penamaan mengaburkan substansi
- Entah itu VPS, bare metal, on-premise, atau colo, namanya tidak penting
- Faktanya server memang harus ditempatkan di suatu tempat, dan yang penting adalah apakah lebih banyak uang tersisa di kantongmu atau diserahkan ke pemegang saham Amazon
- Orang yang berargumen seperti ini pada dasarnya bertindak sebagai penjaga gerbang (gatekeeper)
- "Itu belum dilakukan dengan benar, kamu harus beli switch sendiri, bikin rack sendiri, dan colok kabel Ethernet sendiri"
- Ini argumen yang toksik dan malas, terobsesi pada detail dangkal untuk menghindari inti pembahasan
Biaya cloud pada dasarnya memang mahal
- Upaya gaslighting dari para pendukung cloud
- "Kamu pakai cloud dengan cara yang salah", "Mahal karena kamu salah melakukannya", "Kamu harus tahu cara menggunakan cloud"
- Mereka sendiri tidak pernah benar-benar mencoba alternatif, dan tidak punya pengalaman nyata mengelola server untuk proyek mereka sendiri
- Penulis sendiri akrab dengan AWS dan pernah mempelajari sertifikasi AWS
- Memastikan infrastrukturnya tidak overprovisioned
- Memeriksa apakah ada biaya untuk layanan yang tidak digunakan
- Sudah menghabiskan banyak sekali waktu untuk optimasi biaya AWS, bahkan pernah berhasil memangkas tagihan AWS bulanan lebih dari setengah dari angka di atas $5.000
- Serverless computing, reserved instance, dan lainnya semuanya sudah dipahami
- Reserved instance justru memperburuk masalah: menciptakan vendor lock-in dan mengikat diri ke kontrak 3 tahun
- Jika sedang mempertimbangkan keluar dari cloud, kontrak 3 tahun adalah pilihan terburuk
- Kesimpulan setelah mencoba semuanya: cloud memang terlalu mahal
Penyebab reaksi keras
- Mengapa begitu banyak orang peduli soal penghematan biaya ini?
- Ada dua kesimpulan utama
- Penghidupan mereka dipertaruhkan: jika cukup banyak orang terbujuk oleh pandangan seperti ini, mereka bisa kehilangan pekerjaan
- Perdebatan irasional karena rasa takut: selama 10 tahun terakhir membangun di cloud menjadi tren dan melahirkan jutaan peran "devops" dan "cloud engineers"; jika keluar dari cloud menjadi tren berikutnya, karier banyak ahli cloud bisa berakhir
- Banyak developer diam-diam tahu bahwa cloud tidak sebaik janji awalnya
- Mereka melihat pengeluaran AWS perusahaan 10 kali lebih besar dari yang semestinya, tetapi tetap menganggapnya "ya sudahlah"
- Mereka tidak ingin mengambil risiko membuat manajer marah atau memikul tanggung jawab
- Mereka takut pada biaya politik ketika pendapat mereka berbeda dengan orang paling vokal di tim
- AWS memiliki pengikut seperti kultus yang kuat
- Sertifikasi melatih orang untuk menghafal halaman penjualan dan deskripsi produk yang sebenarnya
- Ada evangelist yang mendorong dogma alih-alih pragmatisme
- Menanamkan ketakutan terhadap dunia luar (server itu berbahaya! tidak bisa diskalakan!)
- Menjadikan "cloud engineer" sebagai identitas, memudahkan orang masuk tetapi sulit keluar
- Karena penghidupan mereka dipertaruhkan, para pengikut AWS terjebak dalam dogma dan terus mengulang argumen yang tidak rasional
- Mereka mengulang poin-poin dari landing page penjualan AWS satu per satu tanpa berpikir apakah itu benar-benar dibutuhkan
- Karena ini perdebatan soal sistem kepercayaan, orang jadi irasional
Sejarah cloud
- Dulu semua orang menjalankan server mereka sendiri
- Di VPS, layanan hosting, bare metal di data center, ruangan gelap di kantor, atau bahkan di rumah
- Semua orang terbiasa dan nyaman SSH ke mesin
- Pada awal 2010-an dimulailah kampanye psyops pemasaran cloud
- Ini gerakan yang disengaja untuk menjual teknologi enterprise kepada startup tahap awal
- Strateginya adalah membuat mereka terkunci sedini mungkin agar bisa dieksploitasi saat mereka mendapat pendanaan
- Strategi AWS
- Mulai menawarkan kredit khusus startup
- Berkeliling accelerator startup untuk mencoba meng-onboard semua startup
- Triknya sederhana: buat semuanya terasa sangat murah (bahkan gratis!) saat startup sedang membangun infrastruktur, lalu ketika mereka tumbuh, buat semuanya menjadi sangat mahal, sehingga mereka terjebak dan sulit keluar dari ekosistem
- IBM cloud juga punya strategi serupa (acara tahun 2014)
- Saat itu semua dijalankan di Heroku dan semuanya bekerja baik-baik saja
- Muncul pertanyaan, "Apa sebenarnya semua cloud ini dan bagaimana cara memakainya?"
- Rasanya seperti sedang dijual sesuatu yang memang tidak dirancang untuk mereka
- Selama beberapa tahun terakhir, perusahaan-perusahaan ini menghabiskan jutaan dolar untuk kampanye promosi cloud demi mendorong startup awal mengadopsi teknologi enterprise
- Era suku bunga nol selama 10 tahun terakhir ikut berkontribusi pada situasi saat ini
- Kini ada gerakan tandingan
- Banyak dipimpin oleh @dhh dan komunitas Rails
- Secara mendasar terasa segar, benar, dan selaras dengan realitas kebanyakan bisnis software di dunia
Sebagian besar bisnis tidak membutuhkan cloud
- Sebagian orang benar-benar memiliki pandangan yang jauh dari realitas bisnis software sesungguhnya
- Mereka berpikir dari sudut pandang Fortune 500 dan menganggap enterprise sebagai standar
- Mereka mengira bisnis rata-rata membutuhkan high availability, replikasi multi-zone, failover otomatis, cluster Kubernetes terdistribusi, dan semua fitur cloud lainnya
- Padahal hanya sangat sedikit bisnis software yang benar-benar membutuhkan semua itu
- Sebagian besar bisnis akan tetap kecil mengikuti hukum power law
- Di Amerika Serikat, bisnis kecil mencakup 99,9% dari seluruh bisnis
- Di Uni Eropa, SME (kurang dari 250 karyawan) mencakup 99% dari seluruh bisnis
- Kebanyakan developer melebih-lebihkan kebutuhan skalabilitas
- Standar mereka untuk "traffic tinggi" terlalu rendah
- Sebagai acuan: saat ini setup 2 server menangani jutaan request per hari untuk jutaan pengunjung bulanan
- Indie maker seperti @levelsio menjalankan semuanya dengan satu server
- Kebanyakan developer belum pernah menjalankan proyek mereka sendiri dengan pengguna nyata dan traffic produksi di satu server
- Kebutuhan teknis juga dilebih-lebihkan
- Hanya segelintir bisnis software yang benar-benar membutuhkan fitur-fitur itu, dan biasanya mereka memang punya alasan teknis yang cukup
- Misalnya Netflix: harus mentranskode dan streaming video dalam jumlah sangat besar ke pelanggan di seluruh dunia, jadi butuh sistem terdistribusi, CDN, dan edge computing
- Jika hanya aplikasi kecil dengan seribu pengguna yang bertukar objek JSON, hal seperti itu sama sekali tidak perlu
- Banyak developer punya gagasan magis bahwa proyek mereka seperti Netflix
- Itu bentuk angan-angan yang bisa dimengerti, tetapi tetap mengarah pada keputusan teknis yang salah
- Mereka merasa perlu server yang tersebar di seluruh dunia karena mengira pengguna akan menyadari selisih beberapa milidetik saat menekan tombol
Server akan baik-baik saja
- Banyak orang punya pemikiran magis tentang cara kerja data center
- Mereka membayangkan server di data center rapuh, labil, dan bisa lenyap begitu saja
- Bahkan ada yang berpikir petir bisa merobohkan seluruh data center
- Data center modern sudah mempertimbangkan semua masalah itu dan menyiapkan banyak perlindungan
- Bukan hanya untuk hal biasa seperti petir, tetapi hampir semua hal yang dapat mengancam uptime
- Catu daya redundan, pendingin redundan, koneksi internet redundan, sistem pemadam redundan, sistem keamanan redundan, serta banyak pengamanan fisik
- Semua yang ada di data center dirancang dengan ketahanan dan redundansi (minimal N+1, kadang 2N) demi menjaga uptime
- Ini terutama pendapat yang berbasis rasa takut dan merupakan hasil dari pemasaran cloud yang sukses dan kampanye psyops
- AWS menaruh mesinnya di mana? Tempat ajaib di bawah pelangi?
- Bagaimana mungkin hanya mesin AWS yang secara ajaib terlindung dari masalah yang juga dimiliki data center lain?
- Bencana memang bisa terjadi (kebakaran OVH tahun 2021), jadi backup tetap diperlukan
- Tetapi dari pengalaman mengelola server selama sekitar 15 tahun, kejadian seperti itu jarang, dan tidak pernah mengalami downtime lebih dari beberapa menit
Mengelola server bukan pekerjaan penuh waktu
- Siapa pun yang cukup lama mengelola server tahu bahwa sebagian besar waktu habis di konfigurasi awal, setelah itu server relatif stabil
- Kerusakan hardware relatif jarang, dan begitu server berjalan, biasanya ia bekerja sempurna selama bertahun-tahun tanpa intervensi besar
- Mengelola server sendiri bukan pekerjaan penuh waktu
- Tidak perlu mempekerjakan tim devops berisi 5 orang
- Bahkan tidak perlu merekrut orang khusus server: kamu bisa melakukannya sendiri, dan itu tidak sesulit yang dibayangkan
- Claude dan ChatGPT punya pemahaman yang baik tentang sistem Linux dan cara mengelolanya, dan bisa dimintai bantuan
- Setelah tweet itu diposting, orang-orang mengira ini adalah pengalaman pertama mengelola server dan menganggap penulis terlalu optimistis tentang arti sebenarnya dari menjalankan server
- Penulis sudah punya pengalaman mengelola server sejak 2006
- Berawal dari mengedit skrip PHP dan mengunggahnya ke server FTP
- Belajar memasang WordPress, mengedit template WP, dan dari sana semuanya berkembang
- Itu pengalaman yang berharga dan mengajarkan dasar-dasarnya
- Belajar apa itu Linux dan cara menavigasinya
- Pada 2007, sampai meminta CD-ROM Ubuntu dari Canonical lewat pos lalu memasangnya di partisi komputer orang tua untuk belajar Linux
- Pengalaman awal seperti itu mengajarkan dasar pengembangan web, dan semua hal lain dibangun di atas fondasi tersebut
Pentingnya belajar Linux
- Developer generasi baru (Gen Z, Gen Alpha) benar-benar terputus dari hardware tempat software mereka berjalan
- Mereka tidak memiliki pengalaman dasar seperti ini
- Mereka lahir di era ketika orang acak di YouTube mengajarkan cara menjalankan perintah tertentu sambil mempromosikan vendor tertentu yang katanya bisa menyelesaikan semua masalah infrastruktur secara ajaib
- Wajar jika mereka memiliki asumsi magis tentang apa itu server dan bagaimana cara kerjanya
- Mereka mengaku bisa bekerja dengan "serverless" tanpa menyadari bahwa mereka tetap menjalankan kode di banyak box lain
- Tentu banyak juga yang belajar lebih dalam tentang Linux dan server, tetapi lulusan bootcamp rata-rata tidak punya pengalaman Linux praktik seperti para pengoprek FTP 20 tahun lalu
- Ini bukan penilaian moral, bukan soal baik atau buruk — ini hanya kondisi web development saat ini
- Akibatnya, perusahaan seperti Vercel menghasilkan jutaan dolar dengan memonetisasi developer generasi baru yang tidak benar-benar paham apa yang mereka lakukan dan belum pernah menjalankan server seumur hidup
- Ketidaktahuan datang dengan biaya ganda: biaya dari ketidaktahuan itu sendiri dan biaya yang dibayar ketika orang lain memanfaatkannya
- Kalau tidak tahu bagaimana sesuatu bekerja, itu benar-benar bisa menguras uang
Sekarang adalah waktu terbaik untuk belajar server
- Jika kamu belum pernah mengelola server sendiri dan takut pada semua hal yang berbau backend, itu tidak masalah
- Sebenarnya belum pernah ada waktu yang lebih baik dari sekarang untuk menjadi mahir dengan server
- Claude dan ChatGPT sama-sama sangat paham Linux dan bisa memandu langkah demi langkah dengan cara yang belum pernah ada sebelumnya dalam sejarah teknologi
- Bukan hanya membantu memahami cara setup dan cara kerjanya, tetapi juga memungkinkanmu bertanya dan mengikuti langkah saat perlu melakukan perubahan tanpa harus mempekerjakan siapa pun
- Ini tidak semenakutkan itu, dan juga tidak perlu dilakukan terlalu sering
- Di era AI ketika pembuatan kode menjadi standar dan kode bisa menjadi komoditas, mengetahui cara men-deploy kode itu ke server produksi murah dan benar-benar membuatnya berguna bagi pengguna akhir bisa menjadi pembeda utama sebagai developer
- Memang ada hal-hal seperti keamanan yang perlu diperhatikan
- Abaikan klaim bahwa mengelola server sendiri kurang aman dibanding menjalankan server di AWS, seolah-olah instance EC2 terlindungi secara ajaib dari hacker,
- Kenyataannya, mengatur semuanya dengan benar tidak sesulit itu, cukup merujuk pada panduan dan skrip setup
- Banyak developer yang lebih berpengalaman tetap bekerja jauh lebih buruk di production dibanding kamu yang dibantu AI
- Jika kamu meminta ChatGPT menjelaskan cara hardening server Linux dan mengikuti praktik keamanan terbaik (tidak memakai autentikasi password, hanya memakai SSH key yang kuat), maka 90% sudah selesai
- Cloudflare bisa memberi lapisan perlindungan tambahan
- Setelah box Linux dikunci dengan baik, jalankan Cloudflare di atas semuanya
- Jika IP server diproksi di DNS agar tidak terekspos, itu sudah sempurna
- Mendapat perlindungan DDoS, edge caching, dan DNS kelas atas secara nyaris gratis
24 komentar
Kalau mempertimbangkan waktu dan upaya yang dibutuhkan untuk membangun sendiri infrastruktur yang diperlukan secara on-premise, layanan cloud rasanya tidak semahal itu.
Dan layanan cloud digunakan karena ketersediaannya yang tinggi, bukan karena biayanya.
Rasanya seperti konsep IKEA atau Daiso.
Mungkin ada juga layanan cloud yang sangat worth it dan masuk akal.
Tapi begitu memakainya, ujung-ujungnya jadi ikut memakai hal-hal lain yang sekarang terlihat agak mahal.
(contoh asal) kalau pakai Lambda, lalu jadi pakai API Gateway, dan yang ini agak mahal dan tidak nyaman -_-^
Kurang lebih seperti itu.
Ngomong-ngomong, yang sangat saya setujui adalah.
Alasan AWS nyaman bagi mereka
Karena terlihat rumit secara teknis, jadi membuat mereka tampak pintar di depan developer lain
Kalimat di atas itu.
Sejujurnya, karena layanan AWS sudah lama dan berkembang terus, ada cukup banyak fitur yang bahkan tidak bisa mereka deprecate, dan terlihat keren kalau paham betul hal-hal seperti ini, jadi saya juga sampai ambil sertifikasi SA wkwk.. sangat setuju banget~~
Cloud, on-premise, dan IDC masing-masing punya kelebihan dan kekurangan, jadi pada akhirnya kuncinya adalah memilih sesuai tujuan penggunaan dan skalanya.
Asumsi terbesarnya adalah bahwa 'kerusakan hardware hampir tidak pernah terjadi'...
Berdasarkan pengalaman saya, saat perusahaan menyewa rak di IDC untuk mengoperasikan server, ada masa ketika disk mati kira-kira sekali tiap 3 hari, jadi saya masih ingat harus bolak-balik mengganti disk dan memulihkan RAID...
Kalau bisa, saya biasanya tetap menyarankan pakai cloud saja. Betapa besarnya nilai dari bisa menyalakannya lagi hanya dengan 'klik' saat hardware rusak.....
Agak aneh kalau disk rusak sekali tiap 3 hari...
Sepertinya itu bukan kasus yang umum.
Ini cerita dari lebih dari 10 tahun lalu, dan mungkin itu Seagate.. kalau tidak salah.
Backblaze mengumumkan 4.372 drive rusak tahun lalu, jadi pada skala sebesar itu memang ada kira-kira satu drive yang rusak setiap 2 jam...
Frekuensi seperti ini bisa terjadi pada skala yang sangat besar.
Hmm, saya sudah cukup lama bekerja di ruang server berskala 100 rak 42U, dengan lingkungan yang terdiri dari HPC, HCI, sistem file terdistribusi berbasis Hadoop generasi awal, dan berbagai macam storage, tetapi saya belum pernah melihat disk rusak sekali tiap 3 hari.
Opini Hacker News
Saya sudah bertahun-tahun mengelola server sendiri, menjaga semuanya tetap sederhana, dan menghemat banyak waktu serta biaya
Saya menghindari AWS atau Azure karena konfigurasinya rumit dan UI-nya juga kurang bagus
Yang penting adalah mengelola server sedemikian rupa sehingga bisa dibuat ulang hanya dari file konfigurasi kapan saja. Karena itu, alat seperti Ansible itu wajib
Kalau memang harus memakai cloud, saya merekomendasikan DigitalOcean. Sederhana dan intuitif, bagus untuk kesehatan mental
Saya hanya memakai DO untuk keperluan disaster recovery tingkat 3, dan mengonfigurasi klaster secara otomatis dengan Terraform dan Ansible
Sebagian besar komunitas developer cenderung ikut arus tren, tetapi di tengah suasana seperti itu saya tetap men-deploy monolit Clojure berbasis JVM ke klaster server fisik saya dan menghasilkan keuntungan yang stabil
pengaturan
ulimit, masalah performa syn cookies, pembaruan keamanan, penanganan serangan zero-day, pengiriman email (pemanasan IP, pengelolaan daftar spam), kepatuhan GDPR, dan sebagainyaSemua itu menjadi tanggung jawab saya, dan orang yang memakai cloud bukan sekadar ‘orang yang tertipu’
Saya tidak suka cara berpikir hitam-putih. Kebanyakan startup bisa menghemat banyak biaya jika pindah dari EC2 ke tempat seperti Hetzner, Linode, atau DigitalOcean
Tetapi cloud juga punya banyak kelebihan — fitur seperti backup, DB terkelola, multi-AZ bisa dipakai hanya dengan beberapa klik
Tidak ada biaya investasi hardware di awal, dan jika beban puncaknya besar, malah bisa jadi lebih murah
Namun karena nilai waktu engineering itu tinggi, cloud bisa menjadi pilihan rasional pada fase pertumbuhan cepat
Pada akhirnya, cloud mahal bukan karena cloud itu sendiri mahal, melainkan karena memakai fitur yang sebenarnya tidak perlu
Ada banyak kasus di mana strategi multi-cloud mencegah bencana
VPS atau dedicated server juga nyaris tidak punya biaya awal, dan kalau beban puncak tidak terlalu ekstrem, cloud belum tentu lebih murah
DB terkelola memang nyaman, tetapi sering ada upgrade paksa, dan jika skalanya tidak besar, saya merasa mengelolanya sendiri lebih baik
Dulu ekspansi hardware sulit, tetapi sekarang satu server saja bisa memberi performa setara rak penuh di masa lalu
Proyek skala menengah sekarang bisa menyelesaikan sendiri masalah yang dulu diselesaikan cloud
Hanya saja, untuk mendapat dukungan tenaga eksternal, cloud jauh lebih mudah, sedangkan self-hosting sulit mencari personel pendukung
Secara pribadi saya lebih suka self-hosting, tetapi untuk orang yang tidak ingin menyentuh infrastruktur langsung, saya rasa cloud lebih baik
Dulu saya menangani IT di sebuah startup hedge fund
Kami menjalankan program analisis C++ di server dual Xeon (RAM 512GB), lalu bos saya menjadi cemas setelah mendengar pertanyaan saat makan siang, “kenapa tidak pakai AWS?”
Saya melihat kenyataan bahwa ‘kepatuhan pada buzzword’ dipandang lebih penting daripada efisiensi
Banyak CTO menghabiskan anggaran besar yang sebenarnya tidak perlu karena suasana seperti ini, dan struktur yang efisien justru menjadi kelemahan dari sisi pemasaran
Ungkapan “hemat 10x” secara logika salah. 10x berarti lebih banyak
Dibanding biaya server, biaya tenaga kerja pemeliharaan jauh lebih besar
Bahkan jika mengoperasikan 10 instance EC2, patch otomatis bisa dilakukan dengan Systems Manager, jadi tidak perlu membangun otomatisasi sendiri
Perdebatan cloud bukan soal hitam-putih
Untuk skala kecil, Hetzner maupun AWS mirip-mirip saja, dan untuk perusahaan besar kuncinya adalah apakah mereka bisa membuat tooling sendiri
Bagian yang paling abu-abu adalah segmen perusahaan menengah (SME). Jika perlu sistem yang sepenuhnya terpisah untuk tiap pelanggan, AWS unggul, dan jika bebannya konstan 24/7, server sendiri lebih baik
Jika memakai cloud hanya untuk hosting VM, itu merugikan. Sering kali fitur cloud tidak dipakai tetapi biayanya tetap dibayar
Server sendiri harus membayar kapasitas maksimum sepanjang bulan, sedangkan cloud hanya membayar beberapa hari saat kapasitas itu benar-benar dibutuhkan
Cloud sangat berguna untuk membangun MVP dan memvalidasi pasar
Dengan kredit startup dan free tier, eksperimen bisa dilakukan cepat, lalu jika biaya jadi masalah, tinggal dipindahkan
Namun sejak awal harus dirancang dengan arsitektur yang independen dari server, dan sulit menyediakan waktu untuk migrasi
Tim kami memakai Google Cloud, tetapi pengeluaran kami kecil sehingga sales rep-nya tidak senang
Kemungkinan untuk pindah anticloud menjadi sumber daya tawar
Selain itu, cloud memudahkan pemenuhan SLA atau regulasi perlindungan data sehingga menguntungkan untuk membangun kepercayaan pelanggan enterprise
Saya penasaran kenapa AWS bisa tumbuh eksplosif di awal
Pada awal 2010-an, menyewa rack dan membangun server itu mahal dan lambat, dan konfigurasi multi-region juga nyaris mustahil
AWS menyelesaikan masalah-masalah itu, tetapi sekarang situasinya sudah berubah
Ada juga kisah Squarespace yang menyelamatkan servernya sendiri dengan membawa bahan bakar saat Badai Sandy
Setelah memesan server di Hetzner, dalam 10 menit Ubuntu bisa terpasang dan konfigurasi Ansible bisa selesai
Tarif tetap, bandwidth tanpa batas, performa yang dapat diprediksi — daya tariknya adalah kesederhanaan tanpa abstraksi yang tidak perlu
EC2 menghilangkan kerepotan itu, dan Lambda melangkah lebih jauh. Sekarang sewa bare metal jauh lebih murah
Kebijakan kredit gratis AWS di masa lalu pada dasarnya adalah strategi lock-in
Menaruh server sendiri di data center ternyata tidak sesulit yang dibayangkan
Saya membutuhkan CPU ber-clock tinggi untuk game server, dan karena sulit didapat di cloud, saya membangunnya sendiri
Biayanya sekitar £15 per bulan termasuk biaya pemasangan, dan berjalan baik selama bertahun-tahun. Hasilnya, penghematan biayanya besar
Mereka menaruh perangkat di data center Seattle, dan melakukan pengelolaan jarak jauh dengan KVM berbasis modem
Kami pindah ke Hetzner beberapa tahun lalu, dan karena efek penghematannya, sepertinya kami tidak akan kembali ke cloud lagi
Pengecualiannya adalah Cloudflare Workers, kualitasnya bagus dan kuota gratisnya besar
Berkat AI, menulis skrip otomatisasi, deployment, dan backup menjadi jauh lebih mudah sehingga pengelolaannya kini lebih sederhana daripada dulu
Sebagai referensi, Claude Code dari Anthropic sedang memberikan kredit gratis $250 untuk pengguna Pro/Max hingga 18 November
Pengumuman terkait bisa dilihat di tweet ini
Mungkin nilainya akan terasa setelah sekali saja mengalami pemulihan backup? Di on-premise, pemulihan backup itu yang paling bikin pusing.
Yah.. saya setuju seratus persen sampai pada poin bahwa 'biaya cloud lebih mahal daripada yang diperlukan' dan 'dalam kebanyakan kasus fitur cloud besar tidak diperlukan', tetapi nada tulisannya membuat saya tidak nyaman membacanya karena seolah-olah mengklaim semua layanan cloud itu penipuan. Kedengarannya seperti mengatakan, 'semua produk asuransi itu penipuan.'
Cloud itu dipakai ketika kita tidak ingin mengelola server sendiri atau saat permintaan sulit diprediksi sehingga perlu scaling cepat. Selain itu, saya tidak yakin ada kegunaan lain yang benar-benar berarti.
Saya setuju semuanya, tetapi saat mengoperasikan server sendiri secara langsung selama bertahun-tahun, sayang sekali tidak ada pembahasan dari sudut pandang keamanan.
Saya juga ingin memberikan satu suara untuk pendapat ini.
Benar.
Saya 100% setuju bahwa cloud itu mahal.
Tetapi jika membayangkan sekarang harus menjalankan lebih dari 200 container di bare metal dengan mengatur Kubernetes sendiri,
Dalam situasi hanya ada 1 backend developer dan tanpa devops, jika beban pengelolaan dan operasional server bisa berkurang dengan biaya seperempat dari gaji satu orang, itu sebenarnya tetap pilihan yang lumayan masuk akal.
Kalau ada orang yang tugasnya hanya mengelola infrastruktur server, keluar dari cloud jelas bisa menjadi opsi yang bagus.
Secara pribadi, ketika saya mencoba membangun layanan sambil sebisa mungkin menyingkirkan cloud, rasanya benar-benar bikin gila.
Saya membutuhkan container image registry, tetapi ketika hendak membangunnya sendiri, local storage terasa memberatkan, lalu demi kemudahan backup saya mencari yang kompatibel dengan S3, untuk memblokir akses dari luar saya juga menyiapkan layanan VPN, ditambah pengelolaan sertifikat HTTPS pada reverse proxy serta berbagai pengaturan untuk keamanan CI/CD... membangun semuanya sendiri...
Kalau di cloud hanya memakai beberapa layanan sederhana, tentu bare metal lebih murah dan memang itulah cara yang tepat. Namun, jika perlu integrasi dengan layanan lain dan ingin mengurangi berbagai beban, meskipun biaya server saat ini lebih mahal, bisa jadi tetap lebih menguntungkan karena biaya instalasi/pengelolaan berkurang, mengingat kita tidak perlu membangun satu per satu layanan seperti itu.
Ada banyak proyek open source untuk image registry.
Banyak kok. Yang saya maksud adalah beban karena harus mengelolanya sendiri secara langsung. Saya juga pakai Nexus atau Harbor.
Dari pengalaman pribadi, itu tidak terasa sebagai beban atau masalah.
Standar tentang apa yang dianggap beban bisa berbeda-beda, jadi mungkin saja terasa seperti itu.
Layanan seperti apa yang Anda kembangkan sehingga memerlukan registry image container?
Itu karena, layanan apa pun yang dikembangkan, saya lebih memilih deployment berbasis container. Saya juga sebisa mungkin lebih suka melakukan deployment tanpa koneksi langsung via ssh. Kalau hanya memikirkan biaya... sepertinya ada juga metode yang memungkinkan deployment langsung tanpa registry, tetapi saya hanya mencoba memikirkan contohnya, dan saya ingin fokus pada hal-hal seperti layanan email atau bagian-bagian yang jadi agak merepotkan.