- Abstraksi cloud yang ada saat ini membuat CPU, memori, dan disk sulit dipakai dalam kombinasi sesuai kebutuhan, dan baik VM maupun PaaS sama-sama menambahkan lebih banyak batasan dibanding komputer biasa
- Remote block storage dan biaya egress yang tinggi mempertahankan struktur yang terikat pada asumsi era HDD, sehingga masalah performa dan biaya justru makin membesar di lingkungan SSD dan jaringan modern
- Kubernetes menutupi API cloud yang sulit digunakan, tetapi tidak bisa mengubah abstraksi dasar yang keliru, sehingga tetap membawa keterbatasan VM, disk, dan jaringan apa adanya
- Seiring meningkatnya kebutuhan software dan eksekusi lewat agents, ruang eksekusi privat, kemudahan berbagi, dan overhead operasional yang rendah menjadi semakin penting, sementara bottleneck struktural cloud lama juga ikut membesar
- exe.dev mencoba mendekati cloud yang benar-benar ingin dipakai dengan lebih dulu menyediakan CPU dan memori lalu membiarkan VM dijalankan langsung di atasnya, sambil menggabungkan TLS proxy, authentication proxy, NVMe lokal, replikasi asinkron, dan penempatan berbasis anycast
Mengapa membangun cloud baru lagi
- Abstraksi cloud yang ada sekarang membuat komputer sulit dipakai dengan cara yang diinginkan, dan itulah alasan langsung dimulainya perusahaan baru ini
- Komputernya sendiri bagus, tetapi cloud modern mengulang batasan yang sama di hampir semua produk, dan inti masalahnya lebih dekat ke bentuk unit penyusun dasarnya daripada sekadar UX atau kesalahan desain API
- VM disediakan sebagai instance terpisah yang terikat pada CPU dan memori, padahal bentuk yang diinginkan lebih mirip dengan menyediakan dulu resource CPU, memori, dan disk, lalu menjalankan VM sebanyak yang diperlukan di atasnya
- Linux VM pada dasarnya adalah proses yang berjalan di dalam cgroup Linux lain, tetapi cloud saat ini tidak memudahkan hal ini untuk ditangani
- Untuk mengakalinya, perlu menaruh gVisor atau nested virtualization di atas satu VM cloud, dan itu berarti menanggung penurunan performa serta setidaknya harus mengelola reverse proxy sendiri
- PaaS juga tidak menyelesaikan masalah ini, dan justru memaksakan abstraksi yang terikat pada vendor yang kurang kuat dibanding komputer biasa
- Cara mengembangkan aplikasi harus dipelajari ulang untuk tiap penyedia komputasi
- Kadang baru setelah proyek berjalan cukup jauh terlihat bahwa sesuatu yang mudah di komputer biasa hampir mustahil dilakukan karena batasan platform yang tertanam dalam
- Berkali-kali terasa seperti “kali ini bisa”, tetapi lalu kembali mentok pada abstraksi yang hanya terimplementasi setengah-setengah
Batasan struktural yang terlihat pada disk dan jaringan
- Pada sisi disk, penyedia cloud cenderung memilih remote block storage atau pendekatan seperti S3 yang bahkan lebih terbatas dan lambat, dan ini dulu cukup masuk akal pada era HDD
- Remote storage tidak terlalu merugikan untuk baca-tulis sekuensial, dan karena random seek HDD berada di kisaran 10ms, koneksi Ethernet dengan RTT 1ms masih merupakan biaya yang bisa diterima
- Dari sudut pandang penyedia, ini memudahkan operasi karena satu dimensi bisa dihapus dari tipe instance standar
- Tetapi asumsi itu runtuh saat beralih ke SSD
- Waktu seek turun dari 10ms menjadi 20 mikrodetik
- RTT jaringan pada sistem blok jarak jauh memang membaik, tetapi overhead IOPS yang pada era HDD sekitar 10% kini membesar menjadi lebih dari 10 kali lipat di era SSD
- Di EC2, konfigurasi 200k IOPS memerlukan setup yang rumit dan biaya $10.000 per bulan, sementara MacBook menyediakan 500k IOPS
- Teknologi jaringannya sendiri sebenarnya sudah sangat baik, tetapi biaya egress dan struktur bisnisnya justru bekerja melawan kemudahan penggunaan
- Jaringan hyperscaler sangat bagus, tetapi biayanya sangat tinggi dan juga membuat integrasi dengan vendor lain jadi tidak nyaman
- Tarif egress cloud ditawarkan sekitar 10 kali per GB dibanding menempatkan server di rak data center biasa
- Saat penggunaan naik sedikit saja, kelipatan biaya ini menjadi lebih buruk lagi
- Pelanggan yang menghabiskan puluhan juta dolar per bulan bisa mendapat harga lebih baik, tetapi itu tidak cocok untuk proyek berskala puluhan atau ratusan dolar per bulan
- Pada rentang ini, apa pun yang dibangun akan sulit dioperasikan dengan murah
Kubernetes dan API menutupi masalah, tetapi tidak menyelesaikannya
- API cloud menyakitkan untuk ditangani, dan Kubernetes hadir untuk menutupinya serta mengurangi beban yang harus ditanggung engineer
- Namun VM tetap sulit dikelola bahkan di atas Kubernetes, karena cloud pada dasarnya melemparkan nested virtualization langsung ke pengguna
- Pada sisi disk juga serupa: saat Kubernetes dirancang, di pihak Google praktis tidak ada perangkat blok jarak jauh yang benar-benar layak dipakai, dan bahkan ketika pola umum hari ini berhasil disesuaikan, hasil akhirnya tetap mudah terikat pada storage yang lambat
- Jaringan pun sama; jika dibuat terlalu mudah, sebagian sistem di data center terbuka terdekat bisa dihubungkan lewat private link dan menghapus satu angka nol dari biaya cloud, sehingga insentif untuk mempermudahnya menjadi kecil
- Daripada menganggap Kubernetes sekadar pekerjaan buatan yang sia-sia, ini dipandang sebagai hasil dari upaya menghadapi masalah yang nyaris mustahil: membuat cloud yang portable dan usable
- Secara mendasar, masalah ini tidak bisa diselesaikan hanya dengan menumpuk abstraksi baru di atas abstraksi cloud yang sejak awal salah, dan upaya memperbaiki Kubernetes pun pada akhirnya punya batas yang jelas
- Waktu hidup bersama cloud yang tidak nyaman seperti ini sudah mencapai 15 tahun, dan selama itu cara bertahannya adalah memperlakukannya seperti bagian lain dari software stack yang tidak menyenangkan: ditoleransi dan disentuh seminimal mungkin
Mengapa sekarang saatnya diperbaiki
- Alasan sekarang menjadi titik balik adalah karena munculnya agents
- Seperti Jevons paradox, makin mudah menulis kode, makin besar pula total jumlah software yang akan dibuat, dan orang akan memakai lebih banyak program baik untuk pekerjaan maupun hobi
- Untuk menjalankan semakin banyak program itu, dibutuhkan ruang eksekusi privat, kemudahan berbagi, dan overhead operasional yang kecil
- Semakin besar total volume software, masalah cloud yang dulu sekadar menjengkelkan berubah menjadi bottleneck yang jauh lebih besar
- Diperlukan lebih banyak komputasi dan pengelolaan yang juga harus lebih mudah
- agents membantu menggantikan operasi atas AWS API, tetapi ini mengharuskan pemberian kredensial dan kadang tetap bisa menghapus database produksi
- Yang paling penting, agents juga menabrak dinding yang sama dengan manusia ketika menghadapi batas mendasar abstraksi cloud yang ada
- Token yang terpakai menjadi lebih banyak dari yang perlu, dan hasilnya pun lebih buruk dari harapan
- Semakin banyak context window agent terbuang untuk memaksa cloud klasik agar cocok dipakai, semakin sedikit ruang yang tersisa untuk benar-benar menyelesaikan masalah
Bagian yang mulai diperbaiki lebih dulu oleh exe.dev
- Yang pertama dirilis oleh exe.dev adalah solusi untuk masalah isolasi resource VM
- Alih-alih melakukan provisioning VM satu per satu, mereka memberikan CPU dan memori lebih dulu, lalu menyediakan struktur untuk menjalankan VM yang diinginkan langsung di atasnya
- Dengan asumsi bahwa VM baru tidak seharusnya langsung diekspos ke internet, mereka juga menangani TLS proxy dan authentication proxy
- Untuk disk, mereka memakai NVMe lokal, lalu blok-bloknya direplikasi secara asinkron ke luar mesin
- Mesin dapat ditempatkan di banyak region dunia agar eksekusi bisa terjadi di lokasi yang dekat
- Mesin-mesin itu ditempatkan di belakang jaringan anycast untuk memberikan titik masuk berlatensi rendah bagi pengguna di seluruh dunia
- Di atas fondasi ini, sistemnya dirancang agar segera bisa menambahkan lebih banyak fitur baru
- Masih banyak hal yang belum selesai dibangun
- Beberapa item yang cukup jelas seperti static IP masih tersisa
- Tantangan seperti UX untuk mengakses snapshot disk historis yang dibuat otomatis juga masih ada
- Pada saat yang sama, mereka juga kembali ke tahap menempatkan komputer langsung di rak data center, sambil meninjau ulang seluruh lapisan software stack, termasuk cara konektivitas jaringannya dibangun
- Tujuan akhirnya adalah membuat cloud yang benar-benar ingin dipakai
3 komentar
Awalnya saya sempat berpikir, kenapa baru sekarang?
Tapi setelah melihat penulisnya adalah salah satu pendiri Tailscale, entah kenapa jadi ingin mendukung.
Tolong buat yang bagus!
Akan bagus kalau layanan bisa dihubungkan hanya dengan drag-and-drop
Komentar Hacker News
Kubernetes awalnya mungkin terlihat cocok untuk menjalankan beberapa kontainer web app, tetapi tak lama kemudian ditumpuki SDN dan berbagai layanan lain hingga membengkak tak terkendali
Semakin "dioptimalkan" dan "dikeraskan" clusternya, biaya cloud, insiden, downtime, dan upaya debugging semuanya malah membesar 2–3 kali lipat
Pada akhirnya, setelah meninggalkan inersia DevOps seperti itu dan menghapus cluster, lalu menyalakan firewall pada single VM Debian dan melakukan deploy Docker dengan Kamal, stabilitas dan keandalan infra justru menjadi yang terbaik, sekaligus biaya turun besar
Sebagian besar aplikasi bisnis hanya melayani ratusan hingga ribuan pengguna, jadi sering kali satu VM besar saja sudah cukup, dan karena cloud seperti Google menangani kegagalan hardware, saat perlu cukup nyalakan VM kedua lalu ganti IP di Cloudflare
Sangat umum orang memaksakan k8s pada skala yang terlalu kecil, dan kalau begitu sejak awal memang bukan skala yang membutuhkan k8s
Karena itu dibutuhkan lapisan yang lebih tinggi untuk menyederhanakan pola deploy yang umum, dan Knative adalah salah satu contohnya
Solusi yang berusaha mengekspos semua primitive dasarnya pada akhirnya tak bisa tidak akan serumit Kubernetes itu sendiri
https://github.com/openrundev/openrun yang saya buat menangani deploy web app internal tim secara deklaratif, menambahkan SAML/OAuth dan RBAC, serta mendukung baik single machine Docker maupun Kubernetes
Pola pikir yang terlalu kompleks, sulit di-debug, dan mahal bisa direplikasi persis sama di VM
Hanya saja sekarang single Debian VM itu mungkin berada di luar radar kebijakan mereka sehingga masih bebas
Begitu seseorang mulai ikut campur, besar kemungkinan mereka akan mencoba menambahkan HA, rollout/rollback, 3–5 VM, kebijakan jaringan virtual, 4 security scanner, 2 log processor, watchdog, network monitor, mTLS, sampai alat visibilitas traffic
Dengan satu mesin tambahan, upgrade atau perubahan tidak terasa terlalu menegangkan meski terjadi gangguan
https://github.com/psviderski/uncloud yang saya buat terinspirasi dari Kamal, membuat konfigurasi multi-machine sesederhana single VM, dan melakukan deploy ke banyak VM dengan zero-config WireGuard overlay serta Docker Compose standar
Bisa mulai dari 1 mesin tanpa kompleksitas orchestrator atau control plane, lalu saat perlu diperluas dengan campuran cloud VM dan on-prem
Saat memakainya di production, rasanya selalu bagus setiap saat, sampai terlihat seperti mendefinisikan ulang komputasi itu sendiri
Jadi saya merasa ada sudut pandang dari kubu yang sangat membencinya yang saya lewatkan
OP adalah salah satu co-founder Tailscale, jadi konteksnya makin menarik
Pengamatannya bahwa perusahaan Cloud 1.0 tradisional memberi default sekitar 3000 IOPS pada VM sementara laptop bisa mencapai 500 ribu IOPS terasa tepat
Visinya benar-benar bagus dan saya pun terasa seperti pelanggan targetnya, tetapi saya khawatir seiring kesuksesan membesar, jalurnya akan mengikuti pola lama: tekanan pendapatan mengalahkan idealisme
Harga cloud sering kali bukan berbasis biaya, dan biasanya dirancang untuk mengambil margin besar khususnya pada item seperti bandwidth atau NAT gateway yang baru melonjak setelah pelanggan terikat dalam
Saya rasa OP juga pasti paham struktur seperti ini
Tetapi storage itu pada dasarnya bersifat ephemeral dan redundansinya juga tidak cukup
RAID1 bisa mengurangi kegagalan hardware, tetapi jumlah NVMe yang bisa dipasang jadi berkurang, dan juga tidak ada cara yang rapi saat VM harus dipindahkan karena masalah lain seperti RAM/CPU host
Pada akhirnya VM seperti ini hampir harus diperlakukan seperti bare metal, dan membutuhkan redundansi di level aplikasi seperti replikasi database
Di Azure, kita harus berasumsi mereka bisa memindahkan VM sesuka hati dan menghapus data ephemeral, tetapi di OpenStack dulu kami bisa mematikan VM bila perlu dan menyalin data NVMe ke host lain lewat migrasi lokal tingkat blok
Meski begitu, kalau host crash maka VM tersebut tetap akan down sampai host pulih, jadi redundansi di level aplikasi tetap menjadi prasyarat
Tetapi latency persentil 99.9 Hetzner sekitar 5ms sedangkan DO sekitar 18ms, dan latency maksimum juga berbeda cukup jauh: Hetzner di kisaran 7ms versus DO 85ms
Pada dd sekuensial, Hetzner mencapai 1.9GB/s sedangkan DO 850MB/s
Dari sisi harga pun beda jauh: Hetzner 4 euro sementara instance DO 18 dolar
Saya menulis ini sebelum selesai membaca artikelnya, dan ternyata OP juga tepat menyoroti dua hal itu
Seolah-olah mereka membuat bahkan server sederhana pun sulit memakai DB lokal agar lock-in terjadi
Gagasan bahwa karena membuat satu barang biayanya X maka harga ditetapkan 1.y*X sebenarnya jauh dari cara pasar menetapkan harga
Pendekatan top-down lebih realistis daripada bottom-up
Seperti debat soal AI yang sangat terpolarisasi, Kubernetes juga terlihat sama terbelahnya
Selama beberapa tahun mengelola cluster dengan berbagai ukuran, tak pernah sekalipun penyebab insiden adalah k8s itu sendiri
Pernah ada satu outage total selama satu jam, dan pihak yang memang tidak suka k8s langsung mencoba menyalahkan "sistem k8s sialan" itu
Penyebab aslinya ternyata layanan tertentu membuka puluhan ribu port dalam sekejap pada kondisi tertentu dan memicu self-DOS
Saya tidak menganggap k8s adalah seluruh masa depan, juga tidak menganggapnya sampah; saya pikir ini sistem yang bagus ketika memang benar-benar dibutuhkan
Yang satu: terlalu kompleks untuk dipelajari, tidak diperlukan untuk masalah saya, dan cara deploy lama sudah cukup; yang lain: lebih buruk dari bare metal dari sisi efisiensi biaya/energi
Biasanya keduanya berjalan bersama
Sikap yang cukup netral atau tidak terlalu peduli justru makin jarang, dan politik Amerika langsung teringat
Saya sendiri juga tidak begitu paham k8s, dan ketika staff engineer mulai bicara tentang pod dan cluster mata saya langsung kosong, tetapi di tim kami ini cocok dan benar-benar berjalan
Bagi orang yang hanya punya palu, semua terlihat seperti paku; orang yang memegang kapak malah heran kenapa semua orang mencoba membelah kayu dengan palu
Bahkan jika kapak memang alat yang tepat, mudah juga membenci palu bila orang yang memegang palu merebut pekerjaanmu
Untuk banyak use case, best practice k8s sudah lumayan mapan, sedangkan di dunia LLM kita bahkan belum benar-benar tahu apa yang bisa disebut best practice
Saya sangat setuju dengan poin bahwa VM terikat pada CPU/memori sehingga kita membayar waktu, bukan pekerjaan
Karena itu saya membeli satu server lelang Hetzner murah dan menjalankannya di atas Firecracker orchestrator self-hostable yang saya buat
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
Yang saya inginkan adalah membeli hardware, lalu membaginya sesuka hati menjadi VM tanpa perlu memikirkan provisioning atau lifecycle
VM yang idle menyimpan state memorinya ke disk sebagai snapshot lalu mengembalikan seluruh RAM, jadi hardwarenya milik saya, VM-nya disposable, dan saat tidak dipakai hampir tidak ada biayanya
Khususnya, setelah ada memory-state snapshot, ternyata semuanya jadi bisa dilanjutkan kembali, dan itu jauh lebih kuat daripada dugaan saya
Saya bisa menyimpan snapshot Chromium yang sudah login lalu langsung menyalakan salinan sesi saat dibutuhkan, agent bekerja di dalam sandbox, dan docker compose untuk preview environment juga berjalan di sana
Saat tidak ada yang berjalan, server praktis idle, dan satu box 100 dolar per bulan menangani semua ini
Detailnya saya tulis di https://shellbox.dev/blog/race-to-the-bottom.html
Dokumentasinya lengkap dan berguna, tetapi cukup banyak bagian yang terasa seperti ditulis AI, jadi saya berharap bisa sedikit lebih ringkas
Meski begitu, bagian "design decisions" khususnya sangat bagus, dan saya juga belajar hal baru dari sana
Kalau belum, layak juga diposting ke Show HN
Sudah terlalu banyak software yang bahkan tidak dipakai, jadi saya tidak begitu paham kenapa kita terobsesi menghasilkan lebih banyak kode
Lihat saja app store, penuh dengan software yang tidak dipakai siapa pun
Bagi saya, penggunaan LLM yang lebih jelas seharusnya bukan untuk membuat lebih banyak software, melainkan untuk membuat software yang lebih baik
Saya berharap fokusnya bergeser dari semata code generation ke arah lain, karena ada banyak cara agar LLM membantu menulis kode yang lebih baik
Gambaran software sebagai sistem deterministik yang dibangun dengan rapi, dipelihara, dan diperbarui tentu masih akan ada, tetapi AI sudah mengubah cara pengguna berinteraksi dengan komputer
Akibatnya, saya rasa akan muncul software yang jauh lebih mendekati sekali pakai
Sekarang kita masih di fase "bagaimana AI membantu engineer menulis software", tetapi perlahan bergeser ke "apa yang harus engineer lakukan agar AI bisa menulis software dengan lebih baik"
Jika begitu, akan masuk generasi engineer baru dengan pandangan yang benar-benar berbeda tentang apa itu software dan bagaimana interaksi komputer seharusnya dibuat
Saya rasa akan ada sangat banyak software kustom yang tidak akan pernah masuk app store
Agar bisa disebut Jevons paradox, biaya produksi software harus turun tetapi kenaikan permintaan melampaui penghematan tersebut sehingga total belanja justru naik
Konsep ini berlaku di pasar yang kuantitas permintaannya sangat responsif terhadap perubahan harga, yaitu pasar dengan elastisitas permintaan tinggi
Di luar game, kelak kita mungkin akan melihat kembali dan merasa aneh bahwa dulu kita membuat satu software yang dipakai ratusan juta hingga miliaran orang
Kini orang bisa membuat software yang tepat melakukan apa yang benar-benar mereka inginkan, dengan lebih sedikit terpengaruh prioritas yang saling bertentangan atau model pendapatan yang menyimpang
Dalam pengertian itu, software seperti itu juga bisa dibilang berkualitas lebih tinggi
Itu memudahkan kedua sisi memprediksi biaya dan pendapatan, tetapi intinya selalu membuat software yang segenerik mungkin
Akibatnya, UX atau fitur yang penting hanya bagi sebagian pengguna terus terpangkas
Vibe coding dan pengembangan yang dipercepat LLM bisa membalik keadaan ini
Kini semua orang bisa membiayai software kustom yang sesuai kebutuhan dan preferensi mereka, dan kita bisa membayangkan dunia di mana 150 ribu pelanggan Salesforce memakai 150 ribu CRM yang berbeda-beda, alih-alih CRM yang sama
Ruang ekspansi software saat ini sangat besar
Jika tidak memahami siklus pembengkakan software, kita akan terus mengulangi kesalahan yang sama
Dimulai dari lean software, lalu fitur permintaan pengguna terus menumpuk, berubah menjadi bloated mess, kemudian perlu rewrite yang lebih kecil lagi, lalu kembali ke lean software
Reboot biasanya gagal, atau justru berhasil mengenai inti masalah dengan tepat dan maju cukup jauh sampai mengancam pemain lama
Cara pandang yang merendahkan DevOps sebagai sekadar pengisi CV dan biang kompleksitas berlebihan terasa lebih seperti pola pikir startup
Di perusahaan kecil mungkin satu orang DevOps menangani seluruh infra, tetapi terutama di sektor finansial, pihak yang benar-benar memegang arah sering kali justru para MD platform engineering
Mereka memecah software engineer menjadi banyak kelompok kecil dan ingin setiap tim mengendalikan repo, deploy, dan segala halnya sendiri, sambil percaya bahwa microservices memberi mereka kekuasaan itu
Saya jamin orang DevOps justru benci kompleksitas
Mereka yang harus on-call malam dan akhir pekan, dan semua insiden selalu dimulai dari asumsi bahwa "ini masalah infra"
Padahal log deploy semuanya sudah masuk ke sistem agregasi log, tapi developer sendiri jarang melihat log dan menyelesaikan masalah deploy-nya; ujung-ujungnya langsung menjadi Incident
Mungkin sekarang sudah saatnya menganggap microservices sebagai tren yang telah lewat
Saya memandang exe.dev dengan positif, dan menurut saya memang ada peluang untuk sesuatu yang memperlancar alur kerja pengembangan LLM sambil tetap memberi fleksibilitas mesin Linux dengan hak root
Tetapi ketika membaca kalimat "dikhianati terus-menerus oleh abstraksi yang setengah diimplementasikan dan setengah dipikirkan", ironisnya itu justru persis pengalaman saya dengan Tailscale
Katanya memudahkan networking, tetapi kenapa baterai jadi cepat habis, kenapa aturan firewall diubah sampai bentrok dengan tool lain, dan kenapa bug tracker begitu sunyi, sehingga akhirnya saya harus memahami implementasi internalnya sendiri
Itu yang membuat saya berkata, "No thank you"
Layanannya sendiri terlihat sangat keren
Yang saya coba bangun bukan ACL router, melainkan lapisan jaringan peer-to-peer, dan di titik itulah rasanya kurang pas
Saya pribadi cukup memakai Hetzner
Semua yang ditawarkan perusahaan cloud terlalu mahal, dan Postgres HA plus backup yang saya jalankan sendiri selama 10 tahun tanpa downtime tetap hanya memakan biaya sekitar sepersepuluh dari biaya production RDS atau CloudSQL
Saya melakukan autoscaling instance sendiri dengan metrik yang dikumpulkan dari Grafana, dan autoscaler berbasis webhook juga berjalan sangat sederhana dan tidak pernah menimbulkan masalah
Jadi sekarang saya benar-benar tidak tahu lagi kenapa harus memakai GCP atau AWS
Semua layanan sudah HA dan backup harian juga berjalan sangat baik
Waktu itu tujuannya adalah mereproduksi pengalaman dedicated server yang paling fleksibel dengan harga murah, dan UML memungkinkan hal itu
Namun sepanjang 2010-an saya ternyata benar-benar salah menduga bahwa mayoritas developer tidak akan memilih model semua komponen stack ditagih terukur hanya demi sedikit kenyamanan
Saya penasaran apakah software engineer usia 20-an sekarang masih tahu cara membangun platform web app bert traffic tinggi dengan server dan router bekas beli dari eBay
Tahun lalu saya sendiri melakukannya untuk membuat datastore 50PiB+, dan saya sungguh penasaran seberapa sering pendekatan seperti ini dipakai di proyek menengah hingga besar
Hetzner menghilangkan banyak kerepotan fisik sambil mempertahankan hampir seluruh keuntungan ekonominya, jadi saya heran kenapa ia bukan raja dunia hosting dan pada 2021 hanya berhenti di pendapatan 367 juta euro
Sulit dipercaya bahwa pengetahuan mengelola sekumpulan dedicated server sudah sedemikian terspesialisasi sampai orang mengabaikan penghematan sebesar ini
Meski begitu, memang benar bahwa jika bisa mendapatkan orang yang tepat, menjalankannya sendiri bisa jauh lebih murah
Setiap menit cron menjalankan docker pull untuk mengambil image terbaru, lalu hanya jika ada versi baru dijalankan docker up -d untuk menggantinya
Di depan saya pasang caddy untuk HTTPS, dan begini saja sudah berjalan sangat murah dan stabil selama bertahun-tahun
Terlihat seperti provider berbasis Inggris dengan filosofi yang mirip, dan walau saya belum mencobanya, saya sudah membuat akun sebagai kandidat VPS berikutnya
Karena sejak awal kita mampu memakai server yang 5 kali lebih cepat, sering kali autoscaling memang tidak perlu
Alternatif sudah banyak, dan saya membuat https://shellbox.dev
Tidak seperti exe, layanan ini menagih hanya saat digunakan, bisa scale-to-zero, dan bisa menyalakan VM seketika lewat SSH
Karena ini Linux biasa, VSCode dan Zed remote juga didukung, dan nested virtualization pun bisa
Kalau mau berinvestasi, 5 juta dolar saja juga tidak masalah
Tidak ada port yang diekspos ke luar, dan semua frontend web dilindungi dengan password
Saya tidak berniat merilisnya, ini lingkungan pengembangan terisolasi pribadi saya yang berjalan di Raspberry Pi di belakang TV
Biayanya pun praktis nol
Semoga layanannya juga sukses
Tidak jelas sebenarnya infra dasarnya berada di mana, jaminan keamanan apa yang ada, dan hal-hal semacam itu, sehingga sulit mempercayakan workload ke sana