Klaster Postgres Fly.io down selama 3 hari, tanpa kabar apa pun tentangnya

• Pada Juli 2023, saat pemeliharaan darurat (emergency maintenance) pada host Fly.io, mesin beberapa pengguna macet dalam status "stopped" dan zombie, sehingga tidak bisa direstart, dihapus, maupun dideploy ulang
• Di dashboard hanya muncul banner "Service Interruption", sementara status page tidak memuat informasi terkait, sehingga penyebab dan ETA pemulihan tidak dapat diketahui
• Perintah fly machine gagal dengan error "could not get machine", dan data abnormal terlihat, misalnya tanggal pembuatan di machine list ditampilkan sebagai "1970-01-01"
• Sebagian pengguna memulihkan sementara dengan menjalankan VM baru lewat fly scale, tetapi VM yang rusak tetap tidak bisa dihapus sehingga ada kekhawatiran penagihan terus berlanjut
• Tidak ada respons resmi maupun pembaruan status selama lebih dari 12–15 jam, yang berujung pada turunnya kepercayaan terhadap platform

---

Terjadinya gangguan dan gejala awal

• Pada pagi hari, health check aplikasi mulai gagal, dan mesin terkonfirmasi berada dalam status "stopped"
• Di dashboard hanya ditampilkan banner Service Interruption bertuliskan "We are performing emergency maintenance on a host some of your apps instances are running on", tanpa informasi lain
• Gangguan tersebut tidak muncul di status page, sehingga prosedur penyelesaian atau ETA tidak dapat ditemukan
• Saat mencoba merestart atau menghapus instance mesin yang macet, terjadi timeout
• Saat deploy ulang, muncul error terkait mesin unmanaged
  • Karena fly deploy hanya memperbarui mesin yang memiliki fly_platform_version=v2 di metadata, tiap mesin harus diperbarui manual satu per satu dengan fly machine update --metadata fly_platform_version=v2 <machine id>

Status mesin zombie dan cara memutar

• Sebagian mesin masuk ke "zombie mode" dan merespons semua perintah fly machine dengan "Error: could not get machine"
• Dengan fly scale, VM tambahan dialokasikan sehingga ketersediaan aplikasi pulih, tetapi VM yang rusak tetap berada dalam status tidak pasti dan tidak bisa dihapus maupun akunnya dihapus
• fly machine list menampilkan data yang salah seperti tanggal pembuatan "1970-01-01T00:00:00Z"
• Pengguna lain juga membuat mesin baru lewat scale-up sebagai jalan memutar, tetapi mesin asli tidak bisa dihapus karena error "connection refused"
  • Ada kekhawatiran bahwa baik VM zombie yang belum dibersihkan maupun VM tambahan yang dibuat akan tetap ditagih
• Environment staging juga berada dalam kondisi yang sama

Dampak pada kontainer database

• Seorang pengguna mengalami masalah yang sama sejak sekitar 14 jam sebelumnya, dan karena targetnya adalah kontainer database, pemulihan tidak bisa dilakukan hanya dengan scale-up sederhana
• Meski berada pada paket berbayar dan sudah mengirim email ke support beberapa jam sebelumnya, belum ada respons
• Aplikasi tersebut di-host di region syd, sehingga disebutkan kemungkinan ada masalah pada satu atau dua host di sana

Dampak luas dan pemulihan sementara

• Hingga kemarin, pengguna mengoperasikan 4 mesin untuk aplikasi+Postgres (staging dan production), tetapi 3 di antaranya masih down, termasuk dua database
• Karena aplikasi tersebut adalah aplikasi API eksternal perusahaan, semua integrasi terhenti
• Untuk menjaga operasional, proyek baru dibuat di Fly dan instance dijalankan; backfill environment variable dan konfigurasi memakan waktu beberapa jam
  • Tanpa disengaja, ini menjadi uji kemampuan DR (disaster recovery)
• Tidak ada cara untuk mengambil data dari mesin db, tetapi karena itu bukan db production utama, data yang diperlukan direkayasa balik dan dipulihkan

Kekhawatiran terhadap kepercayaan platform

• Diungkapkan keterkejutan atas tidak adanya respons resmi setelah 12 jam berlalu
• Ini adalah kedua kalinya mengalami masalah yang sama; meski layanan down, Fly melaporkan semuanya normal dan tidak ada informasi maupun penanganan, sehingga pengguna hanya bisa menunggu
• Perbandingan dengan Heroku: jika host tidak stabil, dyno akan dipindahkan otomatis sehingga tidak ada kekhawatiran seperti ini
• Masalah ini terjadi bahkan pada aplikasi Rails + Postgres standar berskala kecil, sehingga ada kekhawatiran penanganannya akan jauh lebih sulit untuk aplikasi yang lebih kompleks
• Disebutkan bahwa masalah-masalah seperti ini benar-benar meruntuhkan kepercayaan terhadap platform

[GN⁺]

Komentar Hacker News

• Fly meninggalkan jawaban di thread dukungan: mereka menjelaskan bahwa mereka rutin memeriksa forum, tetapi melewatkan tulisan ini, dan terjadi kegagalan satu host yang berkepanjangan di region syd
  Host tersebut tidak kembali normal setelah restart dan juga tidak terhubung ke service discovery, sehingga perlu pemulihan manual
  Aplikasi yang berjalan dengan beberapa instance hanya terdampak pada sebagian instance, tetapi aplikasi dengan satu instance tidak dapat diakses selama gangguan, dan Fly sangat menyarankan konfigurasi beberapa instance
  Gangguan global/region dipublikasikan di status.fly.io, dan masalah satu host selama ini ditampilkan di tab status dasbor, tetapi mereka mengatakan sedang meninjau ulang cara berkomunikasi untuk gangguan satu host yang panjang seperti kali ini
  https://community.fly.io/t/service-interruption-cant-destroy...

  • Aku juga meninggalkan Fly karena kejadian seperti ini. Awalnya, webapp di Fly Machines sesekali tidak bisa terhubung ke mesin PostgreSQL produksi baru, lalu kemudian mesin PostgreSQL itu mati total dan semua data hilang
    Karena restart pun tidak memulihkannya, aku memulihkan backup lama ke RDS, dan merasa keputusan pindah memang tepat
  • Kalau memang benar terlewat, aku tidak paham kenapa thread itu dijadikan privat sehingga hanya pengguna yang login yang bisa melihatnya
  • Rasanya kehilangan satu host saja pada zaman sekarang seharusnya tidak menjadi masalah sebesar itu. Kegagalan instance adalah hal yang wajar terjadi, dan meski pelanggan hanya menjalankan satu instance, apalagi untuk layanan seperti Fly.io yang berpusat pada container, orang akan berharap sistem otomatis memindahkannya
    Terlebih lagi ini terdengar bukan sekadar satu container pengguna, melainkan layanan PostgreSQL terkelola, jadi rasanya lebih masuk akal mengharapkan ketahanan terhadap kegagalan host
  • Aneh rasanya dukungan untuk gangguan platform bergantung pada forum yang bisa saja dilihat atau tidak dilihat oleh karyawan. Melihat dokumentasi[1], untuk mendapat dukungan email perlu paket berbayar, minimal $29 per bulan, sehingga meski sudah membayar biaya resource, bisa saja tetap tidak mendapat dukungan
    Aku mungkin bisa membayar sekitar $5–10 per bulan, tetapi tidak akan menggunakannya untuk proyek sampingan yang tidak menginginkan gangguan 3 hari
    [1] https://fly.io/docs/about/support/
  • Semakin kamu membuat layanan dengan hambatan masuk yang rendah, ironis sekaligus tragis bahwa kamu justru membutuhkan ahli untuk menangani area low-level di bawahnya yang penuh friksi
    Kalau gangguan sudah berlangsung beberapa jam, menurutku mereka seharusnya menyalakan mesin baru dengan Ansible atau apa pun. Entah itu hardware sendiri atau mesin virtual AWS/GCP, seharusnya bisa dilakukan

• Seolah ingin menutupi masalah ini, Fly mengubah thread[1] menjadi privat bagi orang yang belum login
  Di thread itu ada contoh kasus layanan sedang down tetapi status Fly tampil normal, tidak ada informasi, dan tidak ada yang bisa dilakukan selain menunggu
  Pengguna lain mengatakan tiga dari empat mesin—termasuk aplikasi serta PostgreSQL staging/production—masih down, dan aplikasi API eksternal rusak sehingga semua integrasi ikut bermasalah
  Mereka mengatakan perlu beberapa jam untuk membuat proyek Fly baru dan menyalakan instance sementara, dan tidak bisa menemukan cara untuk mengambil data dari mesin DB
  Ada juga reaksi bahwa terasa seperti penghinaan ketika halaman status organisasi menampilkan “tidak ada gangguan”, sementara di halaman yang sama aplikasinya ditampilkan sedang maintenance dan tidak dapat diakses
  Ada juga tulisan yang mengatakan selama 17 jam hampir tidak ada pembaruan halaman status maupun notifikasi, dan mereka hanya menerima peringatan Better Stack
  Backup lengkap thread: https://pastebin.com/ebmCSZkC
  Tweet yang dikirim kepada CEO Fly: https://twitter.com/SouthPawNZ/status/1682181533673857024
  [1] https://community.fly.io/t/service-interruption-cant-destroy...

• Hal terburuk dari Fly adalah ketika ada yang salah, bukan cuma satu hal yang rusak, melainkan beberapa hal sekaligus, sementara halaman status semuanya tampak hijau
  Biasanya responsnya juga diam saja, atau terlalu santai seperti “begini jadinya kalau deploy pada hari Jumat”
  Produknya terlihat keren, tetapi rasanya seperti kemasan cantik untuk layanan hosting paling tidak stabil yang pernah saya pakai
  Tidak bisa setiap minggu merusak pekerjaan orang, membuat mereka menghabiskan malam akhir pekan untuk pemulihan, lalu menutupnya dengan “kami seharusnya bisa lebih baik”. Itu alasan untuk pengecualian, bukan untuk pola yang berulang

  • Meniru pengelolaan halaman status ala AWS saat terjadi gangguan layanan, berani juga

• Di thread HN ini ada banyak noise, tetapi menurut saya intinya begini: para karyawan tampaknya sudah melihat masalah sebelum pelanggan menyadarinya, setelah email dikirim ke dukungan berbayar pun butuh beberapa jam sampai ada respons, dan pembaruan tentang host yang down baru muncul setelah sekitar 20 jam
  Mereka tidak memberi tahu pengguna terdampak dengan benar tentang kegagalan host atau cara pemulihan, dan meski dashboard menampilkan pemeliharaan darurat, halaman status tetap menampilkan semuanya normal
  Saya paham bahwa downtime seperti ini memang terjamin dan umum terjadi karena karakteristik paket dan arsitekturnya, tetapi dengan komunikasi seburuk ini, pelanggan akan pergi
  Kalau seperti penyedia lain, mereka mengirim email begitu host tempat saya berada terlihat sedikit saja bermasalah, setidaknya saya bisa segera melakukan sesuatu untuk aplikasi saya

  • Dari sudut pandang saya, itu bukan ringkasan yang baik. Dukungan tier gratis bergantung pada mereka menyadari aktivitas di forum, dan itu terlewat; orang-orang yang mengalami gangguan melihat konsekuensi dari deploy dengan konfigurasi yang bukan high availability
    Namun, apakah mereka cukup sadar bahwa mereka berada dalam kondisi seperti itu masih menjadi perdebatan
    Ada gangguan yang tidak biasa lama pada satu server tertentu, dan gabungan hal-hal ini membuat banyak orang mengalami gangguan panjang tanpa penjelasan
    Dashboard hanya menampilkan gangguan region/layanan dan tidak menampilkan gangguan server individual, dan karena orang-orang tidak tahu itu, mereka menganggapnya seperti kebohongan
    Perilaku aneh pada pengaturan tag Discourse membuatnya terlihat seolah-olah mereka mencoba menyembunyikan masalah
    Singkatnya, menurut saya ini kejadian yang sial, prosedur dari sisi pengelolaan pelanggan buruk, dan mungkin dokumentasinya juga sebagian kurang, tetapi ini lebih banyak asap daripada api
  • Sebagai karyawan Fly.io, untuk memperjelas: dalam 30 menit sejak host tunggal ini turun, kami memberi tahu halaman status terpersonalisasi[1] semua pelanggan terdampak, dan ketika terselesaikan sekitar 47 jam kemudian, halaman status juga ditandai terselesaikan
    Timeline-nya dalam UTC adalah 2023-07-17 16:19 host down, 16:49 halaman status terpersonalisasi dipublikasikan, 2023-07-19 15:00 host pulih, 15:17 halaman status ditandai terselesaikan
    [1] https://community.fly.io/t/new-status-page/11398
  • Bayangkan seperti apa jadinya kalau AWS harus memperbarui halaman status global setiap kali satu host tunggal di suatu region turun
    Fly.io tidak ingin menjadi klon Heroku, tetapi karena pemasaran dan pengalaman pengguna yang sangat dipoles, akhirnya terlihat seperti itu
    Akibatnya, mereka juga harus berhadapan dengan basis pengguna ala Heroku yang bisa memberi pukulan besar pada brand setiap kali terjadi kegagalan satu host
  • Saya mengalami hal yang sama saat memakai Fly untuk proyek pribadi. Proyeknya down, tetapi halaman status menampilkan semuanya normal
    Karena itu proyek pribadi untuk bersenang-senang, tidak masalah, tetapi saya tidak yakin akan nyaman dipakai untuk kebutuhan yang lebih serius
  • Jika ada informasi yang keliru, saya rasa lebih baik membalas langsung tulisan tersebut daripada membuat generalisasi seperti itu
    Selain itu, sulit bagi saya menerima bahwa ada banyak penyedia cloud yang downtime 20 jamnya bisa disebut “terjamin dan normal”
    Sayangnya, di thread-thread HN yang melibatkan Fly.io, saya cukup sering merasakan banyak pasif-agresivitas

• Saya benar-benar ingin menyukai Fly.io. Konfigurasi dan penggunaannya sangat mudah, tetapi jujur saya rasa aplikasi mission-critical tidak boleh dijalankan di atas layanan ini
  Pada akhirnya semuanya saya pindahkan ke AWS, meski saya benar-benar tidak ingin begitu
  Mesin sering tidak berjalan, terjadi kegagalan acak, build gagal, dan meski saya membayar tier yang lebih tinggi demi dukungan, dukungannya lambat merespons dan tidak membaca pertanyaan dengan benar
  Tidak bisa menambahkan sidecar, sulit diintegrasikan dengan monitoring eksternal, dan dokumentasinya cukup baik untuk happy path tetapi sangat kurang untuk edge case
  Untuk proyek hobi ini oke, dan saya masih menaruh banyak proyek pribadi di sana, tetapi untuk infrastruktur perusahaan, biaya waktu dan frustrasinya jadi terlalu besar sehingga harus pindah
  Saya sangat berharap karena terdengar seperti penerus spiritual Heroku, tetapi menurut saya belum sampai ke level itu

  • Pengalaman saya juga sama. Bahkan untuk proyek hobi baru-baru ini, selama dua hari berturut-turut saya tidak bisa membangun apa pun sehingga berhenti menggunakannya
    Minggu sebelumnya build berhasil, di lokal juga baik-baik saja, dan belakangan di Fly juga kembali berhasil, tetapi itu adalah downtime yang tidak bisa dipahami tanpa penjelasan penyebab maupun jawaban dukungan
    Tier gratisnya sangat murah hati sehingga banyak hal bisa dilakukan meski tetap di bawah batas penagihan, tetapi waktu luang saya sedikit dan pada waktu itu saya hanya ingin membangun proyek
    Padahal itu cuma situs statis kecil yang dibuild dengan Node
    Tool-nya sendiri bagus, jadi kalau infrastrukturnya distabilkan, saya ingin mencobanya lagi
  • Separuh informasi penting yang diperlukan untuk memakai layanan ini terkubur di suatu thread forum yang ditulis staf
    Kalau dengan upaya yang sama informasi itu tidak bisa dimasukkan ke dokumentasi, saya tidak tahu seburuk apa pipeline dokumentasinya
    Jawaban untuk pertanyaan penggunaan di forum seharusnya “ada di dokumentasi; kalau belum ada, baru saja kami tambahkan” dan “kalau membingungkan, beri tahu kami, kami akan memperbarui dokumentasinya”
  • Saya juga mengalami hal yang sama. Dashboard Fly bilang semuanya normal, tetapi request timeout
    Saya harus menggali sendiri log fly dan melihat bahwa proxy tidak bisa menjangkau server, dan tidak ada cara bagi saya untuk memperbaikinya
    Beberapa jam kemudian saya memposting issue di forum, tetapi tidak ada jawaban dan tidak ada tanda bahwa itu dibaca; tak lama setelah itu, masalahnya seperti terselesaikan secara ajaib
    Saya berharap mereka sukses, tetapi karena kurangnya komunikasi seperti ini dan rasa tidak berdaya karena tidak bisa melakukan apa-apa, saya tidak akan memakai fly.io untuk sementara
  • Penasaran apakah kamu sudah mencoba Render. Menurutmu apa penerus Heroku?
  • Pengalaman saya juga agak mengecewakan. Proyek main-main akhirnya saya pindahkan ke Hetzner VM + Dokku, karena node database PostgreSQL berhenti tanpa pemberitahuan apa pun dan tidak kembali sampai saya menghidupkannya lagi secara manual

• Ini mungkin jawaban yang sangat tidak memuaskan, tetapi secara pribadi yang bisa saya katakan hanya sejauh ini: saya sama sekali tidak tahu mengapa thread ini di situs komunitas kami hilang dari daftar
  Saya sedang melihat UI admin, dan ada ikon gembok kecil di samping postingan, tetapi opsi “unlist story” masih bisa diklik
  Hal terbaik yang bisa saya katakan adalah, saya cukup yakin tidak ada instruksi dari atas untuk menyembunyikan thread ini. Situsnya publik dan siapa pun bisa membuat akun untuk melihat thread
  Silakan mengatakan apa pun tentang kami, tetapi bersembunyi dari hal seperti ini bukan salah satu kelemahan kami
  Untuk masalah server Sydney, saya belum cukup tahu untuk memberi jawaban yang berguna bagi orang-orang yang menjalankan instance di atasnya. Saya baru pulang dari luar dan baru mulai mencari tahu
  Setelah melihat lagi, semua postingan di kategori app-not-working tampaknya terlihat seperti “private”, dan mungkin itu pengaturan kategori. “Private” di sini berarti harus mendaftar dengan akun Discourse agar bisa melihatnya

  • Kalau boleh memberi saran jujur, mungkin ini lebih ditujukan kepada Kurt, tetapi perusahaan membutuhkan proses, akuntabilitas, dan komunikasi yang lebih baik
    Nada jawaban ini dan komunikasi fly.io lainnya, jika mempertimbangkan opini publik tentang fly.io, tampak sebagai tanda bahwa elemen-elemen itu kurang
    Dengan lebih dari 60 karyawan dan masalah sebanyak ini, itu bukan terlihat seperti nada yang manusiawi dan hangat, melainkan tanda bisnis yang tidak bisa diskalakan
    Agar bisnis B2B yang sedang tumbuh berhasil, hal-hal seperti proses dan pengawasan diperlukan, tetapi dari jawaban-jawaban lain tampaknya kalian tidak menginginkannya, dan itu pertanda buruk
    Sekali rusak itu insiden, dua kali rusak itu nasib buruk, tetapi tiga kali rusak berarti prosesnya bermasalah. Dari komentar-komentar di sini, di Fly.io tampaknya rusaknya jauh lebih sering daripada tiga kali
  • Kesimpulan yang saya dapat dari jawaban ini adalah, kalau saya memilih Fly.io di tempat kerja, saya bisa saja dipecat
    Bukan karena gangguan itu sendiri, melainkan karena bisa perlu berhari-hari untuk mendapatkan dukungan
    Jaminan apa yang bisa kalian berikan kepada komunitas bahwa dukungan akan lebih baik lain kali?
  • Mungkin karena di-hosting di region SYD
  • Saya tidak tahu mengapa kategori app-not-working pada dasarnya membuat thread hilang dari daftar, tetapi sampai penyebabnya ditemukan, saya menghapusnya dulu sehingga thread ini kembali publik
  • Saya sangat menyukai apa yang dilakukan Thomas, dan menurut saya pendekatan ini benar. Sebagai catatan, https://fly.io/blog/carving-the-scheduler-out-of-our-orchest... adalah salah satu tulisan favorit saya di blog Fly
    Kami telah menjalankan https://changelog.com di Fly.io sejak April 2022, dan arsitektur saat ini ada di https://github.com/thechangelog/changelog.com/blob/master/IN...
    Selama 15 bulan, kami memproses lebih dari 100 juta request sebagai aplikasi Phoenix + PostgreSQL di Fly.io, tetapi sulit menemukan alasan untuk mengeluh
    Beberapa deployment gagal dan kami memperbaikinya dengan menjalankan ulang pipeline, pada awal Juli 2023 di Frankfurt ada 9 ribu request yang mengembalikan 503 selama 10 detik, dan satu volume yang tidak terhapus saat eksperimen mesin menghilang keesokan harinya, hanya itu
    Kami sering membahas pengalaman Fly.io di podcast Kaizen: https://changelog.com/topic/kaizen
    Episode pengumuman migrasi: https://changelog.com/shipit/50
    PR terkait: https://github.com/thechangelog/changelog.com/pull/407
    Kami juga baru-baru ini membahas rencana migrasi dari apps v1 (Nomad) ke apps v2 (flyd): https://changelog.com/friends/2#transcript-138
    Saya sedih mendengar banyak orang tidak mendapat pengalaman yang baik, tetapi saya percaya Fly.io akan terus membaik. Semoga suatu hari masa sulit seperti ini menjadi cerita yang baik
    Tulisan yang memberi harapan: https://community.fly.io/t/reliability-its-not-great/11253

• Saya sangat menyukai fly.io dan berharap mereka sukses. Mereka mengerjakan hal yang sulit, jadi wajar jika ada yang rusak
  Namun kurangnya komunikasi mengecewakan, terutama karena pada Maret CEO sendiri menyoroti hal itu sebagai sesuatu yang ingin diperbaiki dalam tulisan besar tentang reliabilitas di komunitas
  https://community.fly.io/t/reliability-its-not-great/11253#s...

  • Setelah kartu “kami kacau, tetapi akan memperbaikinya” sudah dipakai, akan sulit jika tetap tidak berhasil memperbaikinya
  • Kami menghargai umpan balik yang jujur. Kami seharusnya bisa berkomunikasi lebih baik tentang masalah ini
    Di dasbor pengguna yang terdampak, kami menampilkan gangguan pada satu host, dan masalah platform/region kami refleksikan di halaman status, tetapi jelas ada area abu-abu ketika status yang disampaikan tidak sesuai dengan pengalaman pengguna yang sebenarnya
    Kami baru-baru ini menambahkan banyak hardware untuk menghindari masalah kapasitas, dan sesuai perkiraan, probabilitas gangguan keseluruhan turun, tetapi jumlah gangguan dalam bentuk hardware meningkat
    Kami bisa berbuat lebih banyak untuk membantu pengguna menghindari masalah seperti ini, mempercepat pemulihan, dan memberi tahu dengan lebih baik saat mereka terdampak
    Walaupun kami melakukan kesalahan dalam komunikasi, kami mendengarkan umpan balik seperti ini

• Sinyal bahaya yang lebih besar adalah Fly tampaknya tidak memiliki cara otomatis untuk memindahkan workload dengan cepat dari server yang rusak ke server yang sehat
  Padahal container dan orchestrator sudah mengabstraksikan konsep volume data yang bisa dipasang/dilepas
  Tentu saja, menyediakan ini membutuhkan investasi teknis besar, dan menurut saya itu salah satu alasan storage di tiga besar cloud mahal. Namun jika menyediakan layanan persistensi data, kemampuan ini wajib ada
  Ada ketidaksesuaian antara apa yang ingin ditawarkan Fly dan apa yang diharapkan pasar
  Fly ingin berinovasi dengan memungkinkan aplikasi berjalan di banyak data center, tetapi tanpa layanan persistensi data yang layak, fitur itu tidak berguna bagi kebanyakan orang
  Mereka tampaknya mencoba menyelesaikan masalah persistensi dengan replikasi SQLite, tetapi dengan begitu sebagian besar developer harus mengubah cara mengembangkan aplikasi agar sesuai dengan platform Fly
  Fly harus memilih apakah ingin menjadi pengganti Heroku yang stabil dan murah, atau menawarkan cara pengembangan aplikasi tersendiri yang memberi performa terbaik bagi pengguna di seluruh dunia
  App Engine adalah contoh menarik. Ia mendahului zamannya dan meresepkan cara pengembangan yang bisa diskalakan hingga traffic sangat tinggi, tetapi orang-orang tidak ingin mengubah cara mereka mengembangkan aplikasi untuk menyesuaikan diri dengannya

  • Bukankah mereka sudah pernah pivot sekali? Dengan skala saat ini dan pendanaan lebih dari 100 juta dolar, menurut saya akan sangat sulit melakukannya lagi
    Saat ini mereka terlihat kewalahan, seperti baru saja memadamkan satu kebakaran lalu muncul kebakaran lain, sehingga saya tidak percaya pada roadmap teknisnya
    Bukankah sudah sekitar 2 tahun sejak banyak orang memasukkan Fly.io ke daftar “cek lagi nanti”?
    Kalau orang sudah menganggapnya tidak stabil, memulihkan reputasi itu sangat sulit, terutama di bidang IT
  • Fly tidak memiliki storage yang terhubung secara remote; semuanya adalah volume berbasis LVM lokal pada node
    Persistensi data dilakukan dengan mengekspor snapshot LVM 24 jam atau yang dibuat manual ke S3
    Menurut saya ini benar-benar bukan tempat untuk menjalankan workload persisten. Jika menjalankan PostgreSQL di sana, Anda harus siap melakukan hot-load data ke instance baru atau memulihkan dari backup

• Karena alasan yang sama, sejak dulu saya sudah menyarankan di HN agar tidak memakai Fly: https://news.ycombinator.com/item?id=31394179
  Setelah meminta penghapusan akun, akun saya menjadi semacam shadow ban tanpa komunikasi apa pun
  Saya juga mengirim email, tetapi sampai sekarang tidak pernah mendapat jawaban, dan setelah itu semuanya saya pindahkan ke aplikasi Railway dan Google Cloud Run

  • Maksudnya setelah menghapus akun, Anda mencoba mendaftar lagi dengan alamat email yang sudah dihapus itu?
    Mengapa sebuah perusahaan melakukan shadow ban hanya karena seseorang mengajukan pertanyaan yang tidak berbahaya?

• Yang menarik, rasanya sejarah berulang di Fly.io. Mirip dengan saat pertama kali bertemu Heroku
  Fly.io dulu terasa segar dan menarik seperti Heroku saat pertama muncul, dan saya terkesan dengan kesederhanaan serta kemudahan penggunaannya
  Namun seiring waktu, sinyal-sinyal masalah kecil mulai terlihat, downtime menjadi lebih sering, dan deployment yang dulu cepat dan mulus terasa menyakitkan karena melambat
  Rasanya seperti déjà vu masa ketika keunggulan Heroku mulai menghilang
  Menyedihkan melihat Fly.io tampaknya mengikuti jalur yang sama: makin banyak orang berbondong-bondong ke platformnya, performa memburuk; makin populer, makin terlihat kurang stabil
  Ini terasa seperti kisah peringatan tentang bagaimana platform yang menjanjikan pun bisa jatuh, dan saya berharap Fly.io bisa keluar dari siklus ini serta menemukan pijakan sebelum menjadi tidak berguna seperti titik terendah Heroku

  • Saat itu saya agak khawatir melihat Fly menyediakan resource yang cukup besar secara gratis dan di dokumentasinya pun secara halus menganjurkannya seperti sebuah fitur
    Saya merasa mereka mungkin terlalu melebih-lebihkan hati nurani industri ini, dan kalau sudah dikenal luas seperti Heroku, jelas orang-orang yang tidak mau membayar akan berdatangan
    Untuk mencoba lagi penawaran gratis yang murah hati, Anda perlu organisasi pencegahan penyalahgunaan yang kuat dan mahal, atau kantong sangat dalam untuk menggelontorkan hardware agar sanggup menanggung ketiadaannya di awal
    Fly tidak tampak kuat di kedua sisi itu. Itu juga salah satu alasan saya menyukainya. Hal-hal semacam itu terlihat seperti omong kosong ala perusahaan besar, dan Fly tidak terlalu berbau seperti itu
    Namun saya tidak akan terkejut jika para engineer Fly menghabiskan sebagian besar waktunya untuk menangani penambang kripto gratisan, penipu, dan pelaku penyalahgunaan, serta mengoptimalkan alokasi resource dan pembatasan otomatis, alih-alih mengerjakan keandalan infrastruktur jangka panjang atau pengalaman developer
  • Saya juga merasakan hal yang sama
    Saya penasaran apakah ini terkait skala. Saat sebuah perusahaan memperoleh pelanggan berbayar yang cukup untuk membuatnya menguntungkan atau layak didanai, apakah pada saat yang sama masalah yang cukup banyak juga menumpuk sehingga kesan segar dan menarik di awal perlahan berubah menjadi seperti pesaing lama yang ingin digantikannya?
    Pengalaman saya juga begitu. Ketika perusahaan tumbuh dari skala beberapa loyang pizza menjadi tingkat “kami sudah memesan venue acara”, entropi mulai meresap, dan pepatah seperti hukum Conway atau hukum Brooks menjadi semakin jelas