Pada 2023, kejayaan hanya berjarak 11 MB/detik

 (thmsmlr.com)
2 poin oleh GN⁺ 2024-04-08 | 1 komentar | Bagikan ke WhatsApp
  • Bahkan situs web 1.000 besar dengan sekitar 200 juta pengunjung per bulan, jika hanya melihat HTML, membutuhkan sekitar 30 TB/bulan, rata-rata 11 MB/detik transfer, skala yang masih bisa ditangani oleh satu server
  • Perhitungannya berangkat dari Business Insider sebagai acuan: 2 halaman per pengunjung, 400 juta dokumen HTML per bulan, HTML terkompresi sekitar 75 KB, dengan asumsi JS, CSS, dan gambar diserahkan ke CDN
  • Eksekusi di edge punya keunggulan karena server dekat dengan pengguna, tetapi jika saat rendering terjadi round-trip ke database, latensi kembali terseret ke lokasi database origin
  • Selisih biayanya juga besar: Hetzner menawarkan server 16-core, RAM 64 GB, NVMe seharga $0,34/jam, dengan 20 TB transfer gratis lalu $1,5/TB, sementara AWS dan Vercel punya harga bandwidth yang jauh lebih tinggi
  • Jika bukan pekerjaan yang secara khusus membutuhkan cloud, konfigurasi satu server + SQLite + Litestream + CDN lebih sederhana dan murah, serta bisa menghindari scaling horizontal yang tidak perlu

Skala nyata situs web papan atas dilihat dari 11 MB/detik

  • Menggunakan Business Insider sebagai contoh situs web di kisaran 1.000 besar
    • Menurut SimilarWeb, peringkatnya 587 secara global dan jumlah pengunjung bulanannya sekitar 200 juta orang
    • Jika rata-rata tiap pengunjung melihat 2 halaman, perlu menyajikan 400 juta dokumen HTML per bulan
    • Berdasarkan contoh artikel, dokumen HTML standar setelah dikompresi berukuran sekitar 75 KB
    • Jika dikalikan, hanya untuk HTML diperlukan bandwidth sekitar 30 TB/bulan
  • 30 TB/bulan jika dirata-ratakan setara sekitar 11 MB/detik
    • Pada kasus Business Insider, ini sekitar 150 requests/sec
    • Asumsinya HTML tidak memakai CDN, sementara JS, CSS, dan gambar bisa disajikan lewat CDN
    • HTML terkompresi 75 KB tergolong besar, sehingga tergantung implementasi, penyesuaian seperti mengurangi ukuran HTML atau menambah jumlah request juga memungkinkan
  • Pada hardware modern, menghasilkan HTML 11 MB/detik dengan kode aplikasi adalah standar yang rendah
    • Prosesor server AMD terbaru menyediakan 64 core dan 128 thread
    • Prosesor server Zen 5 Turin dikabarkan memiliki 192 core, dan pada server dual-socket bahkan disebut-sebut konfigurasi mendekati 400 core dengan hingga 768 thread
    • Dari sudut pandang ini, Docker, serverless, dan scaling horizontal tidak selalu menjadi pilihan yang diperlukan

Eksekusi di edge tidak selalu mengurangi latensi

  • Batas bawah fisik latensi pulang-pergi ke sisi lain bumi berdasarkan kecepatan cahaya adalah sekitar 200 ms
    • Dalam praktiknya, ke data center yang baik di sisi lain bumi sering kali memakan waktu kira-kira 300 ms
  • Jika JS, CSS, dan media disajikan melalui CDN, mengurangi 300 ms waktu pemrosesan server pada rendering awal saja bisa memberi efek yang mirip dengan memindahkan server lebih dekat ke pengguna
  • Teknologi serverless generasi kedua telah sangat mengurangi masalah masa lalu ketika cold boot mudah menghabiskan anggaran latensi 300 ms, tetapi round-trip ke database tetap tersisa
  • Jika rendering halaman membutuhkan satu saja query database, server edge harus kembali melakukan round-trip ke lokasi seperti us-east-1 tempat database origin berada
    • Latensi berpindah dari antara pengguna dan server origin menjadi antara server edge dan server origin
    • Halaman yang kompleks sering membutuhkan 5 atau lebih query database untuk rendering
    • Banyak framework web menjalankan query secara berurutan dengan model single-thread, sehingga jika terjadi beberapa kali round-trip antar data center, hasilnya bisa lebih lambat daripada sekali pergi ke origin
  • Ada aturan praktis bahwa komunikasi antar data center 10 kali lebih lambat daripada komunikasi di dalam data center, dan komunikasi di dalam data center 10 kali lebih lambat daripada komunikasi di dalam perangkat yang sama
    • Dalam konteks ini, SQLite lokal muncul sebagai pilihan yang menguntungkan untuk memangkas latensi

Perbedaan biaya Hetzner, AWS, dan Vercel

  • Server 16-core Hetzner, termasuk RAM 64 GB dan drive NVMe, berharga $0,34/jam
  • AWS EC2 m5a.4xlarge, yang dibandingkan sebagai server x86 serupa, berharga $0,68/jam
  • Perbedaan harga bandwidth lebih besar lagi
    • Hetzner memberi 20 TB transfer gratis dan setelah itu menagih $1,5/TB
    • AWS memberi 100 GB gratis dan setelah itu menagih $90/TB
    • Vercel disebut sebagai contoh yang menagih $200/TB setelah 1 TB pertama gratis
  • Kuota gratis dari vendor cloud memudahkan masuk di awal, tetapi saat skala membesar bisa berbalik menjadi biaya tinggi

Menjalankan operasi secara sederhana dengan konfigurasi satu server

  • Jika tidak ada kasus penggunaan cloud tertentu seperti transcoding video, menjalankan model AI sendiri, atau pekerjaan yang benar-benar memberi beban besar pada sistem, situs web atau SaaS dapat berjalan di satu server
  • Menempatkan server di Virginia dapat memberikan latensi di bawah 100 ms bagi pengguna berbahasa Inggris
  • Konfigurasi yang disarankan dibuat sederhana dengan berpusat pada satu server
    • Database menggunakan SQLite di mesin yang sama
    • SQLite dicadangkan secara terus-menerus dengan Litestream
    • CSS, JS, dan gambar di-cache lewat CDN
    • Server rendering dilakukan dekat dengan SQLite untuk mengurangi round-trip dan meningkatkan performa
  • Deployment juga tidak perlu dibuat rumit
    • CI cukup melakukan SCP kode ke server
    • NGINX mendukung deployment tanpa downtime
    • Docker dan virtualisasi diperlakukan sebagai faktor yang memperlambat eksekusi kode dan CI/CD

Kapan scaling horizontal diperlukan dan kapan tidak

  • Narasi bahwa scaling horizontal diperlukan dalam kebanyakan kasus berlebihan
  • Ada asumsi bahwa performa server membaik lebih cepat daripada pertumbuhan internet
  • Jika latensi benar-benar penting, konfigurasi dengan menambahkan server di Jerman dan California memungkinkan
    • Write diarahkan ke primary
    • Read menggunakan read replica lokal
  • Konfigurasi seperti ini cukup scalable, kompleksitas pengelolaannya rendah, dan biayanya juga jauh lebih murah
  • Penyajian HTML pada skala 11 MB/detik tidak perlu dibuat rumit tanpa alasan

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-08
Pendapat di Hacker News

  • Bisnis hosting kecil saya dulu mengalami pasang-surut tepat di titik ini, dan saat itu saya tidak tahu apa yang sebenarnya terjadi
    Saat bertumbuh pada awal 2000-an, pendapatan besar biasanya datang dari stack yang rumit, dan banyak konfigurasi seperti load balancer serta firewall redundan yang sebenarnya melebihi kebutuhan pelanggan, tetapi pelanggan menginginkannya
    Failover sering kali biaya kompleksitas operasionalnya lebih besar daripada manfaat yang didapat saat server mati dengan cara yang memang diantisipasi, dan kami juga membuat platform cloud hosting berbasis API untuk melawan AWS, tetapi pendapatan mencapai puncaknya pada 2012
    Pelanggan menginginkan solusi yang lebih rumit yang memakai AWS sebagian atau seluruhnya, sementara kami berpikir karena hardware sudah jauh lebih kuat dibanding 10 tahun sebelumnya, pelanggan besar pun akan menginginkan server yang lebih sedikit dan sederhana
    Namun itu berarti menjual harga, bukan menjual kecerdikan, dan kami tidak memahami ambisi finansial yang diperlukan untuk transisi seperti itu. Tidak ada yang percaya pada satu server murah, dan membeli dua unit pun belum memberi jawaban memadai soal skalabilitas
    Pada akhirnya pendapatan memang bertahan, tetapi kami tidak bisa membangun stack layanan terkelola dan ekosistem software lebih cepat daripada Amazon, dan setelah tantangan teknis baru mengering, kami menjual perusahaan pada 2018
    Karena kami tumbuh secara bootstrap dan tagihan hosting tanpa batas terasa seperti risiko gila, desain produk kami pun lahir dari pola pikir seperti itu; baru belakangan terlihat bahwa semua orang ternyata bersedia mengambil risiko itu
    Alasan AWS menancap bukan hanya karena VC memungkinkan produk yang mahal, tetapi juga karena kecerdikan khas mereka tertanam dalam satu generasi developer software. Namun pengetahuan tentang kapan cloud tidak diperlukan dan apa alternatifnya kini terasa cukup niche

    • Kompleksitas dan kecerdikan AWS seperti catnip bagi developer, dan hampir tidak ada yang menandinginya dalam menopang resume-driven development

  • Ada beberapa masalah dengan angka-angkanya
    Pertama, traffic tidak tersebar merata. Angka 400 juta page load/bulan di tulisan itu bisa terkena hukum 80/20 secara rekursif, dan jika dilihat begitu, sekitar 205 juta request dapat menumpuk selama 5,8 jam, menjadi sekitar 9,7 ribu request per detik
    Itu masih mungkin dengan satu sistem, tetapi bukan lagi hal sepele, apalagi jika juga menginginkan satu DB tanpa read replica. Meski total traffic sama, batas bandwidth yang dibutuhkan untuk peak load menjadi jauh lebih tinggi daripada rata-rata optimistis 11MB/s
    Kedua, latensi end-to-end satu arah hanya berlaku untuk data streaming. Pada cold start dunia nyata, tanpa HTTP/3, koneksi TCP butuh 3 round trip, koneksi TLS minimal 2 round trip, baru setelah itu request dan response HTTP berjalan
    Untuk melayani manusia sungguhan, semua hal yang dapat diamati harus terjadi dalam kurang dari 1 detik, dan setelah itu persentase pengguna yang menganggap sistem rusak lalu menutup tab meningkat tajam
    Dulu saya membantu mengoperasikan betting exchange; traffic-nya melonjak ekstrem dan kebutuhan latensinya ketat, sementara volume transaksi terkonsentrasi pada bagian yang sangat kecil dari seluruh jendela event. Dalam trading real-time, hasil harus muncul di layar dalam 100ms sejak pengguna mulai bertindak, dan latensi round trip jaringan menggerus anggaran pemrosesan event
    Referensi: https://www.nngroup.com/articles/response-times-3-important-...

    • Untuk layanan seperti klon Business Insider, poin 1 adalah yang utama. Jika akun Twitter besar menautkan satu artikel, seluruh rata-rata page load bulanan bisa terkumpul dalam beberapa menit
      Beban seperti itu pun masih bisa ditangani dengan konfigurasi satu server besar, tetapi kini itu bukan lagi web server sederhana, melainkan semacam frontend load balancer yang cukup kuat dengan web server bawaan
      AWS memang mengenakan biaya mahal, tetapi ada engineering yang luar biasa besar di balik load balancer dan infrastruktur jaringannya, sehingga kita yang lain tidak perlu menjadi ahli di seluruh area stack tersebut
    • Contoh global itu agak lucu karena tidak memperhitungkan proses pembuatan koneksi, tetapi argumen utamanya tetap valid
      Sebenarnya berapa banyak layanan yang benar-benar membutuhkan jangkauan seluruh dunia? Apakah dukungan banyak bahasa juga ikut dibuat?
      Jika melayani di dalam AS atau EU, satu server pusat yang bagus pun bisa memberi latensi di bawah 30ms ke seluruh kawasan tersebut
      Kecuali benar-benar ada kebutuhan global dan harus mengelola database global juga, edge cenderung terlalu dibesar-besarkan

  • Melihat 500 Internal Server Error muncul, sepertinya penulis sedang menerima traffic lebih dari 11MB/s. Arsipnya ada di sini: https://archive.is/UVpg0

    • Baru kali ini saya melihat PR_END_OF_FILE_ERROR. Beberapa situs web mengatakan itu terjadi karena proxy, VPN, atau DNS-over-HTTPS, tetapi dalam kasus saya bukan itu penyebabnya

  • Menurut saya tulisan ini memandangnya dengan cara yang salah
    Pendekatan yang lebih baik adalah jangan melakukan scaling terlalu dini
    Bangun saja sesuai kebutuhan, dan dalam sebagian besar kasus bahkan CDN pun biaya yang tidak perlu. Dengan syarat, tidak membayar pajak bandwidth berlebihan dari penyedia cloud
    Jika masalah performa mulai terlihat, tangani saat itu; dan jika kuda pekerja biasa tiba-tiba menjadi unicorn yang diinginkan semua orang, itu adalah masalah yang justru ingin dimiliki

    • Mulailah dengan satu server. Kita bukan Facebook, dan keberhasilan startup tidak bergantung pada apakah di tahun pertama ada downtime tak terduga 15 menit sekali sebulan atau tidak
      Jika produknya bagus, pengguna akan mencoba lagi satu jam kemudian, bukan langsung pindah ke pesaing. Jika muncul masalah skalabilitas, cukup pindahkan bagian yang resource-intensive ke model hybrid yang bisa diskalakan
      Namun jika sejak awal ingin web-scale, puluhan microservice, kondisi kegagalan yang meledak di antaranya, dan membakar uang VC lewat tagihan AWS sebelum pelanggan pertama, silakan saja
    • Dalam kasus saya, DigitalOcean menyediakan fitur praktis seperti CDN, CI, high availability, dan deployment Git seharga 5 dolar per bulan, jadi saya mulai dari sana
      Mengoperasikan server fisik sendiri adalah urusan nanti, bukan masalah sekarang. Saat pilihan sudah antara tagihan AWS 1 juta dolar dan satu server besar, saya tidak akan memutuskan berdasarkan posting blog, melainkan sudah menjalankan pengujian sendiri

  • Jika memakai AWS, berarti Anda juga membeli kambing hitam. Gangguan besar layanan cloud mudah dijelaskan kepada atasan atau investor, tetapi jauh lebih sulit menjelaskan downtime kumulatif yang sama akibat kesalahan manusia di dalam tim

    • Kesalahan manusia adalah penyebab gangguan nomor satu, baik sebelum maupun sesudah tren cloud
      Kalau begitu, saya penasaran bagaimana itu selaras dengan tafsir bahwa cloud adalah kambing hitam

  • Jika menargetkan scaling vertikal, mengapa SQLite? Tidak ada yang menghalangi menjalankan Postgres yang di-host sendiri atau Supabase bersama aplikasi di server yang sama, dan selain butuh lebih banyak upaya konfigurasi, sulit terpikir kekurangannya
    Jika berjalan tanpa DB dan menaruh seluruh state global di memori fisik satu server besar, menyimpannya sebagai objek internal proses tanpa round-trip ke Redis, sesekali membuat snapshot memori ke disk, serta memakai bahasa multithread yang dikompilasi, maka satu box bisa memenuhi NIC di atas 1Gbit dan melayani seluruh dunia
    Saya juga merasa akan menarik kalau ada kasus nyata yang memakai arsitektur seperti itu

    • Mengapa tidak SQLite? Tentu jawabannya selalu “tergantung situasi”, tetapi belakangan suasana bahwa SQLite bukan database sungguhan makin ditantang
      Di luar pola persistensi relasional standar, perbedaan fiturnya besar sehingga Postgres bisa lebih baik, tetapi dalam beberapa pola arsitektur SQLite juga bisa unggul
      Untuk aplikasi berpusat konten seperti BusinessInsider, pola Baked Data berbasis SQLite bisa lebih baik dari sisi biaya dan latensi
      simonw(datasette) telah banyak membuat alat dan tulisan tentang penggunaan SQLite di lingkungan produksi untuk situs web berpusat konten atau kaya data: https://simonwillison.net/2021/Jul/28/baked-data/
    • Menurut benchmark-benchmark ini, alasannya karena SQLite jauh lebih cepat, terutama dalam hal waktu round-trip
      Itu masuk akal karena SQLite berjalan di dalam proses dan tidak perlu serialisasi. Ada juga keuntungan tambahan bahwa operasi bisa diproses secara serial, sehingga pengujian, penalaran, dan pembangunan lapisan cache menjadi jauh lebih mudah
      Jika tidak memakai Unix socket, ada juga overhead jaringan, tetapi karena disebut server yang sama, itu saya sisihkan sebagai catatan tambahan. Dalam praktiknya, sangat umum menaruh Postgres di mesin lain demi isolasi, dan itu juga salah satu keunggulan utama DB jaringan
    • Jika dijalankan di satu mesin, SQLite lebih baik daripada Postgres/MySQL
      Fitur yang dibutuhkan semuanya ada, dan kesederhanaan serta kecepatannya juga lebih baik. SQLite mampu menangani data skala terabyte, banyak pembacaan, backup streaming real-time, dan secara keseluruhan merupakan implementasi SQL yang cukup seimbang
      Rasanya saya baru akan mempertimbangkan Postgres/MySQL saat melampaui scaling vertikal satu box
    • Kemungkinan maksud penulis adalah bahwa SQLite bisa dipakai di edge
      https://blog.cloudflare.com/introducing-d1

  • Tampaknya banyak orang merasa perlu membela status quo dengan alasan ketersediaan dan keandalan ketika penulis berfokus pada latensi, bandwidth, dan biaya
    Kesimpulan saya bukanlah menolak keunggulan cloud di hadapan trade-off, melainkan mempertanyakan apakah pola arsitektur cloud yang kini ada di mana-mana beserta ketergantungannya benar-benar wajib
    Perbandingan ini lawan itu adalah perangkat retoris untuk memperkenalkan alternatif, dan solusi mana yang tepat bergantung pada sangat banyak faktor per penggunaan. Faktor-faktor seperti itulah yang juga membuat engineer mendapat pekerjaan
    Namun bahkan dalam pola yang diusulkan penulis, kekhawatiran SRE bisa diatasi. “Kalau satu server mati, bagaimana dengan availability?” nyaris seperti strawman, karena availability bisa diselesaikan dengan cara yang berbeda dari sistem yang kita kenal, dan solusinya harus disesuaikan dengan hal yang benar-benar penting

    • Mengapa itu strawman? Baik on-premise maupun cloud, itu adalah pertanyaan yang tentu akan diajukan orang normal dalam review desain

  • Ada cara untuk mendapatkan jauh lebih banyak hanya dengan menambahkan satu tahap pada anggaran hemat: menaruh API dan DB SQLite bersama
    Idealnya API memakai format serialisasi biner ber-overhead rendah dan koneksi persisten, sementara penyajian web memanfaatkan free tier layanan edge yang didukung VC dan sedang membakar uang. Saat ini Cloudflare Workers cukup murah hati dan traffic keluar juga gratis
    Intinya, SQLite mampu menangani jumlah query per detik yang sangat besar bahkan dengan satu thread. Banyak operasi bisa dimasukkan secara serial sehingga mudah dinalar, dan caching memori serta invalidasi di sisi API juga menjadi sederhana
    Dengan memisahkan web serving, kita bisa menikmati performa edge untuk handshake dan melewati DB sepenuhnya pada halaman statis. Tulisan itu meremehkan masalah waktu round-trip, padahal aplikasi nyata membutuhkan lebih banyak round-trip daripada yang dikira, sehingga masalah ini cukup nyata
    Sebagian besar penggunaan CPU di luar DB berasal dari parsing, deserialisasi, penyalinan data, dan TLS; jadi jika potongan besar itu dikurangi, mesin kelas entry-level pun bisa dengan mudah mendapatkan puluhan ribu write per detik, dan read bahkan lebih cepat
    Meski begitu, bottleneck klasik, terutama I/O, selalu layak di-benchmark. Penyedia sering melebih-lebihkan atau menyesatkan, jadi perlu dicoba sendiri di free tier. Sebaiknya siapkan juga integration test dan benchmark untuk berjaga-jaga jika harus pindah

    • Saya sedang bereksperimen dengan konsep serupa. PostgreSQL bisa mengeluarkan hasil query sebagai JSON, sehingga jika disesuaikan persis dengan bentuk yang akan dikirim API ke klien, tidak perlu diparsing terlebih dahulu
      Ini cukup bagus ketika hasilnya besar, tetapi saya berharap PostgreSQL sendiri tidak menjadi bottleneck saat membuat dataset besar menjadi JSON

  • Orang-orang bilang kita harus berada di edge, dekat dengan pengguna, dan mengurangi latensi
    Sebenarnya, seberapa besar masalah latensi itu?
    Contohnya adalah proyek rekomendasi buku Gnooks yang berjalan di server Jerman: https://www.gnooks.com
    Penasaran apakah ada yang merasa situs itu terlalu lambat
    Selama beberapa tahun terakhir, proyek ini menerima ribuan saran pengguna, tetapi seingat saya tidak ada yang pernah mengangkat latensi sebagai topik. Padahal kelompok pengguna terbesarnya berasal dari AS

    • Situs ini menaruh sebagian besar logika di backend, dan untuk setiap interaksi pengguna hanya melakukan satu kali bolak-balik ke server
      Karena itu, masalah latensinya jauh lebih kecil dibanding PWA gaya sekarang yang mengimplementasikan sebagian besar logika di frontend lalu mengirim banyak kueri ke backend untuk memuat data yang diperlukan
    • Kalau diakses dari Australia, terasa bahwa ini bukan situs lokal yang cepat. Ia bisa terlihat seperti situs lokal yang lambat atau situs luar negeri yang cepat, dan ping sekitar 300ms, sesuai perkiraan
      Tetap saja situsnya sendiri baik-baik saja. Masalah baru muncul kalau situsnya memang sudah lambat
    • Coba saja memakai internet lewat VPN dari Australia
      Jika dilakukan dari Eropa, latensinya akan sekitar 2 kali lipat dari yang dilihat pengguna Australia, sehingga membantu memperkirakan pengalaman terburuk
    • Dari Hanoi, hasilnya lebih baik dari perkiraan. Dari DNS+TLS awal sampai pemuatan halaman masih memakan waktu lebih dari 1 detik, tetapi permintaan berikutnya lebih baik seperti yang diperkirakan dan setidaknya di bawah 1 detik
    • Seperti kebanyakan pertanyaan lama, jawabannya bergantung pada situasi
      Bagusnya, ini bisa diuji secara andal untuk memastikan apakah benar-benar penting. Dengan begitu, akan ada jawaban yang konkret

  • Tulisan ini sama sekali tidak membahas ketersediaan. Layanan yang berjalan di satu box akan mengalami downtime terencana maupun tidak terduga
    RPO/RTO juga perlu dipikirkan. Saat box itu jebol—atau lebih tepatnya, kalau jebol—perlu dilihat berapa lama pemulihannya dan berapa banyak data yang hilang
    Untuk pernyataan bahwa jika rendering halaman punya satu saja kueri database maka harus kembali ke DB di us-east-1, ada juga opsi-opsi seperti ini:
    https://aws.amazon.com/rds/aurora/global-database/
    https://aws.amazon.com/dynamodb/global-tables/
    https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
    https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
    Ada banyak hal serupa lainnya, dan kalau mencoba merangkai sendiri hal yang sama secara tambal-sulam, itu akan merepotkan

    • Menurut saya, ketersediaan saat ini cenderung terlalu dilebih-lebihkan
      Kalau 10–20 tahun lalu, saya mungkin setuju. Internet masih baru, dan kalau sebuah situs turun orang-orang menyalahkan situsnya, lalu situasi cepat menjadi buruk. Namun sekarang, mereka lebih mungkin menyalahkan penyedia internet lebih dulu atau mencoba lagi nanti
      Tidak semua orang adalah Google, dan sistem yang lebih sederhana pada dasarnya juga lebih kecil kemungkinannya gagal. Pertahankan backup, dan kalau benar-benar khawatir, replikasi DB ke situs disaster recovery dingin. Itu sudah cukup untuk sebagian besar perusahaan dan situasi yang bukan FAANG
      Selama data tidak hilang, bagi banyak perusahaan itu hanya menjadi gangguan singkat. Jika komunikasinya baik dan kejadiannya sangat jarang, downtime beberapa hari pun bisa ditoleransi; dalam beberapa kasus, kehilangan data pun bisa ditanggung
      Ada ungkapan bahwa setiap tambahan satu angka 9 pada reliabilitas akan menggandakan biaya, dan itu harus benar-benar diperhitungkan saat menilai ROI. Seberapa besar reliabilitas yang sebenarnya dibutuhkan bisnis bergantung pada target pasarnya, dan menurut saya jawaban default IT berupa 100% otomatis itu keliru
    • Jika dijalankan langsung di server fisik, latensi bisa dikurangi jauh lebih besar dan bandwidth I/O bisa ditingkatkan dibanding produk-produk yang ditautkan
      Model satu server atau dua server juga jauh lebih rendah kompleksitasnya, dan karena itu tim operasi seperti LetsEncrypt pun memilih arsitektur dua server fisik seperti ini untuk menjalankan layanan global pada skala web: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
      Berkat latensi internal yang sangat rendah dari DB di dalam server atau DB tepat di sebelahnya, software dapat menjalankan kueri DB beberapa orde besaran lebih cepat, memakai lebih sedikit resource per pengguna, dan memberi pengalaman pengguna yang lebih responsif dibanding layanan DB terkelola di dunia nyata
    • Layanan yang berjalan di AWS atau tempat serupa pun tetap mengalami downtime
      Kompleksitas menciptakan jebakannya sendiri, dan menurut saya tidak ada layanan web yang belum pernah mengacaukannya sekali pun. AWS sendiri juga kadang menyebabkan insiden
    • Di AWS pun masalah ketersediaan besar tetap terjadi
      Tidak bisa dibilang bahwa VPS lebih buruk dalam hal ini