Kisah Horor Serverless

• Di berbagai layanan SaaS dan serverless, kasus tagihan tak terduga dalam jumlah besar sering terjadi, dan ada sebuah halaman yang merangkum kasus-kasus tersebut dengan rapi
• Terungkap kasus ketika pengguna yang sebelumnya membayar biaya langganan bulanan secara normal menerima tagihan puluhan ribu hingga ratusan ribu dolar hanya dalam sehari akibat serangan DoS atau penggunaan sumber daya yang tak terkendali
• Pada sebagian layanan, bahkan ketika batas pengeluaran telah ditetapkan, biaya tambahan tetap dikenakan, sehingga keterbatasan sistem menjadi sorotan
• Komunitas pengembang membagikan pengalaman seperti ini, dan struktur penagihan yang tidak masuk akal serta kurangnya transparansi disebut sebagai isu utama
• Di lingkungan serverless dan cloud, satu kesalahan kecil atau satu serangan saja dapat menimbulkan kerugian finansial yang sangat besar, sehingga perlunya kewaspadaan makin ditekankan

---

Kumpulan kasus tagihan berlebihan pada layanan serverless dan SaaS

#1 Tagihan besar di Webflow

• Saat menggunakan paket $69 per bulan, tanpa alasan yang jelas pengguna ditagih $1,189.42 untuk biaya satu bulan

#2 Kasus serangan DoS pada situs game WebGL

• Operator situs unggahan game WebGL berskala menengah menerima tagihan lebih dari $100,000 dari Google Firebase hanya dalam sehari setelah terjadi serangan DoS

#3 Vercel Pro dan melampaui batas pengeluaran

• Meski menggunakan paket Vercel Pro seharga $20 per bulan dan menetapkan batas pengeluaran $120, tetap muncul biaya tambahan yang tak terduga

#4 Penagihan proyek dan tagihan bernilai sangat besar

• Muncul kasus proyek yang biasanya membayar $50 per bulan, lalu suatu pagi menerima tagihan hingga $70,000

#5 Penggunaan BigQuery dan isu tagihan dataset publik

• Saat menggunakan BigQuery di lingkungan Playgroud, muncul tagihan sangat besar melebihi $22,000

#6 Biaya hosting berlebihan dibanding jumlah pengunjung yang kecil

• Meski pengunjung bulanan hanya 9,000 orang, biaya bulanan mencapai $250, yang berarti perlu mengeluarkan $3,000 per tahun

#7 Masalah setelah Devin(AI) mengubah codebase

• Pengalaman atas hasil tak terduga ketika AI bernama Devin melakukan perubahan pada kode

#8 Tiba-tiba ditagih setelah penggunaan gratis

• Meski belum pernah membayar sama sekali, suatu hari tiba-tiba muncul tagihan $530

#9 Tagihan untuk situs dokumentasi dan proyek kecil lainnya

• Bahkan pada layanan dengan penggunaan kecil seperti situs dokumentasi sederhana, ada banyak kasus tagihan besar, misalnya hampir $400

#10 Horor free tier

• Tagihan sekitar $103 pun dianggap bermasalah. Terutama saat menggunakan free tier, kemunculan tagihan mendadak menjadi sumber kekhawatiran

#11 Cloudflare, AWS, dan isu lainnya

• Ada kasus penghentian layanan oleh Cloudflare disertai pemberitahuan untuk membayar $120,000 dalam 24 jam
• Di AWS S3, tagihan tak terduga tetap muncul bahkan setelah membuat bucket kosong dan privat
• Kasus serupa juga berulang di berbagai penyedia lain, seperti menerima tagihan belum dibayar sebesar $104,500 dari Netlify

#12 Serangan DoS, email, dan kehilangan data

• Saat serangan DoS terjadi, pengiriman email menghabiskan $11,000, dan setelah itu database juga hilang

#13 Tagihan massal Vercel serta masalah akun dan trial

• Di Vercel, serangan spam memicu tagihan $23,000 dalam sehari, dengan 56.000 akun dan trial ikut diaktifkan

#14 Tagihan tak terduga saat proses pengujian/deploy

• Saat mendeploy fitur ke Vercel dan layanan lain untuk tujuan pengujian, muncul biaya yang tidak terduga
• sitemap.txt menggunakan bandwidth hingga ratusan GB dan memicu tagihan besar

#15 Biaya pengujian Firebase dan Cloud Run

• Hanya dengan dua kali pengujian Firebase dan Cloud Run, biaya mencapai $72,000, membuat layanan menghadapi ancaman bangkrut

Kesimpulan dan implikasi

• Struktur biaya di lingkungan serverless dan cloud bisa tidak transparan atau sangat rentan terhadap serangan maupun kesalahan
• Banyak kasus tagihan tak terduga telah dilaporkan, sehingga pemantauan yang cermat, pengelolaan penggunaan, dan penetapan batas yang diizinkan sangat diperlukan saat mengoperasikan layanan
• Jika fitur otomatisasi dan pemantauan tidak memadai, satu kali pengujian sederhana atau satu serangan eksternal saja dapat menyebabkan kerugian tak terduga hingga puluhan ribu dolar
• Bagi pengembang, startup, dan pengguna SaaS lainnya, pentingnya pengelolaan biaya dan kesadaran risiko semakin besar

[ahwjdekf]

Saya pernah mengerjakan pengembangan untuk DW internal sebuah perusahaan besar, yaitu pekerjaan memindahkan data on-premise yang ada ke AWS. Namun, setelah berbulan-bulan pengembangan dan pengujian selesai, pada akhirnya proyek itu tetap dibatalkan. Alasannya karena tagihan bulanannya diperkirakan akan jauh lebih mahal dari yang dibayangkan. Bahkan bagi perusahaan besar sekalipun, pengeluaran cloud bukan hal yang mudah.

[regentag]

Saya juga pernah membuat akun untuk tujuan belajar AWS, lalu sempat ditagih biaya meski jumlahnya kecil.
Akun saya ternyata dibobol dan seseorang membuat lalu menjalankan instance dengan akun saya... Untungnya cepat saya hentikan, jadi selesai dengan biaya kecil saja.
Karena saya tidak bisa meluangkan waktu untuk mengelolanya, akhirnya saya memilih menghapus akunnya saja sebagai langkah penanganan.

[ifmkl]

Saya ingin merekomendasikan agar sebelum mulai memakai cloud, Anda membangun lingkungan mini server dengan kelas n100 atau n150 yang belakangan ini sering muncul, lalu menggunakannya untuk mengumpulkan lebih banyak pengalaman dalam pengujian maupun operasional.

[crawler]

Bahkan untuk proyek yang sangat kecil, rasanya benar-benar menakutkan bahwa begitu diunggah ke platform, jika ada kerentanan, hal itu bisa langsung berujung pada kerugian finansial.

Saya menaruh Cloudflare di depan konten saya, tetapi peretas menemukan objek yang tidak di-cache lalu menghajarnya lebih dari 100 juta kali. Setelah saya memblokirnya, mereka bahkan menemukan alamat bucket origin secara langsung dan menyerangnya.

Saya jadi penasaran apakah dalam kasus seperti ini biayanya akan dikembalikan.

[GN⁺]

Komentar Hacker News

• Saat belajar pemrograman di bootcamp, saya pernah mencoba membuat instance Elastic Beanstalk gratis. Untuk verifikasi identitas saya butuh kartu kredit, dan waktu itu saya tidak mengira itu akan jadi masalah. Namun kemudian server saya kena serangan spam bot dan Amazon menagih saya $100.000. Pada akhirnya saya mendapat refund, tetapi sejak hari itu saya jadi membenci Amazon dan bertekad akan memakai layanan lain jika harus menggunakan cloud computing. Saya tidak suka dashboard yang rumit dan struktur yang membuat pelanggan bingung hingga kehilangan uang. Seandainya kartu kredit hanya dipakai sebagai alat verifikasi dan bot diblokir, itu sudah cukup. Kalau dibandingkan dengan toko bahan makanan yang bisa menjual kuki dengan mudah lewat kartu kredit, menurut saya fintech sebenarnya bisa dipakai dengan jauh lebih berguna, tetapi mereka tidak melakukannya
  • Itulah salah satu alasan mengapa cloud hosting menakutkan. Bukan cuma Amazon, Azure atau Google Cloud juga "biasanya" memberi refund. Tapi kalau proyek demo saya yang cuma punya 5 pengunjung mingguan tiba-tiba kena DDoS, lalu perusahaan hosting memutuskan kali ini bukan kasus "biasanya" dan meminta transfer pembayaran, saya bisa berada di ambang bangkrut
  • Sekarang ada tagihan $25.000. Dulu saya menyalakan audit data plane untuk SQS dan ternyata terhubung ke feed event audit real-time. Akibatnya, setiap event audit murni memicu event pencatatan lagi seperti loop tak berujung. Akun yang selama hampir 10 tahun rata-rata cuma membayar $2 per hari tiba-tiba mulai mengeluarkan biaya $3.000 per hari, dan tidak ada peringatan atau intervensi apa pun dari AWS
  • Saya penasaran kenapa Anda membenci Amazon padahal mereka mengembalikan $100.000 itu. Dalam kasus saya, AWS selalu memberi refund bahkan untuk tagihan mahal yang sepenuhnya akibat kesalahan saya sendiri. Kalau ada kebijakan seperti "matikan semuanya saat anggaran terlampaui", mungkin akan ada banyak tragedi lain seperti "kena DDoS lalu AWS mematikan semua EC2 saya dan data yang saya tulis ke penyimpanan sementara ikut hilang"
  • "Ini hal yang sangat mudah, cukup satu kalimat if untuk mematikan instance ketika akun melewati batas dan membuang layanan ke drive statis. Mereka hanya tidak mau—mereka ingin memanfaatkan skala untuk memaksimalkan keuntungan dari pelanggan. Orang-orang yang dulu bikin semua orang susah dengan cloud compute sekarang juga mau mengambil keuntungan ekonomi dari biaya AI berkat perolehan pasar. Belakangan edge compute jadi lebih mudah karena cryptocurrency membuat orang berinvestasi berlebihan di hard drive. Pada akhirnya pasar mendorong gelembung dan perilaku buruk, serta memudahkan orang menyalahgunakan pasar dengan kekuatan alih-alih membangun kepercayaan. Penjahat pintar dengan sikap licik seperti 'kamu cuma tidak paham ini! (oh iya, bayar lagi sebelum pasarnya runtuh)' adalah salah satu masalah terbesar industri ini. Perusahaan taksi juga tidak menagih $1.000 hanya karena tidak mengantarkan ke tujuan. Sulit dipercaya bahwa mereka tidak bisa menaruh if di server. Apakah Amazon lebih buruk daripada perusahaan taksi? Mungkin saja iya. Inilah alasan 'Waymo' dimulai (mungkin bercanda)"
• Saya kira ini akan membahas penderitaan serverless dalam hosting/pengembangan/debugging, ternyata soal ledakan harga. Mungkin karena biaya bandwidth belum terasa terlalu serius buat saya, jadi sebagian besar tulisan semacam ini saya lewatkan begitu saja, tetapi yang ini agak mengejutkan—kasus bucket S3 kosong yang bisa meledakkan tagihan AWS, yang menceritakan bahwa cukup dengan memanggil API tanpa autentikasi ke S3 milik orang lain, biaya bisa dilempar ke pihak lawan. Ini hal baru buat saya
  • Saya rasa tindakan segera diambil setelah posting blog soal fenomena ini menjadi ramai: Amazon S3 berhenti mengenakan biaya untuk beberapa kode error
  • Salah satu masalah nyata lingkungan serverless adalah platformnya sendiri buram seperti black box—meski itu juga bagian dari value proposition serverless. Kami mewarisi backend Lambda besar, dan ketika ada masalah internal platform seperti putusnya socket sesekali saat terhubung ke secret extension, sangat sulit menelusurinya. Lingkungan pengujian lokal juga terlalu berbeda dari lingkungan deployment sebenarnya, jadi makin menyiksa. Google Cloud Functions mungkin berjalan baik untuk mainan di rumah, tapi untuk proyek sungguhan saya lebih memilih menaikkan HTTP server/queue consumer langsung ke container seperti ECS
  • Isinya seperti, 'bayangkan saya membuat bucket S3 privat kosong di region favorit saya. Lalu kebetulan salah satu tool open-source terkenal punya konfigurasi default untuk menyimpan backup ke S3, dan memakai nama yang sama dengan bucket buatan saya sebagai placeholder'—saya penasaran seberapa sering ini benar-benar terjadi; saya tidak tahu seberapa sering konflik penamaan benar-benar muncul
  • Sampai terpikir ini bisa dipakai untuk menyingkirkan pesaing. Karena itulah saya kurang suka AWS. Tidak ada upaya sama sekali untuk melindungi pelanggan kecil dari tagihan kejutan. Azure juga tidak jauh lebih baik, tapi setidaknya ada sedikit perlindungan
  • Saya juga awalnya berharap ini akan menjadi contoh cloud lock-in, di mana semuanya diikat ke serverless, Lambda, dan DynamoDB sehingga hal yang sebenarnya cukup dijalankan di VPS $20 dengan sqlite malah dipaksa menjadi sesuatu yang megah, tapi ternyata bukan itu jadi agak kecewa
• Penderitaan sebenarnya di serverless bukan tagihan besar dari satu insiden, melainkan tagihan yang membengkak sedikit demi sedikit tiap bulan. Sangat mudah membuat resource lalu membiarkannya. Naik beberapa ribu dolar setiap satu-dua bulan, lalu ketika COO menyadarinya seluruh karyawan panik menurunkan biaya di bawah $10.000. Lalu terulang lagi. Kalau dijumlahkan selama beberapa tahun, pemborosan seperti ini bisa lebih besar daripada kehilangan uang sekaligus
  • Itu pada dasarnya model bisnis AWS. Pernahkah Anda menyebutnya model "Planet Fitness"? Daftar dan menghabiskan uang dibuat sangat mudah, tetapi menghentikan pembayaran dibuat sangat merepotkan
  • Organisasi tampaknya sama sekali tidak belajar dari periode tagihan mahal seperti ini. Saya penasaran apa penyebab biaya terus meningkat dan apakah ada cara untuk mencegahnya lebih awal
  • Hal seperti ini juga sering terjadi on-premise. Akan ada server—biasanya VM—yang terus berjalan untuk aplikasi yang tidak lagi dipakai. Tentu saja biaya VM juga tidak nol
• Sering kali tanggung jawabnya tidak jelas. Pelanggan menginginkan alat ajaib tanpa gesekan yang bisa mendeploy infrastruktur hardware dengan sekali klik. Kalau pengguna yang belum berpengalaman salah konfigurasi lalu muncul tagihan besar, reputasi cloud akan buruk bila mereka tetap menagih penuh, tetapi kalau pengguna dibatasi terlebih dahulu maka pintu juga tertutup bagi developer kecil yang ingin menantang startup. Dalam kasus seperti ini, kalau tiba-tiba muncul tagihan $10.000, saya selalu penasaran secara filosofis siapa seharusnya membayar sampai sejauh mana, dan sejauh mana biaya akibat kesalahan harus ditanggung. Kalau di level kode saya memakai resource 10 kali lebih tidak efisien, apakah itu tetap harus dianggap "salah konfigurasi adalah tanggung jawabmu"? Atau haruskah pelanggan tidak perlu peduli apakah cloud yang dipakai adalah raksasa seperti AWS atau layanan API startup kecil?
  • Bagaimana kalau ada sistem seperti batas anggaran/pemutus sirkuit (batas belanja)? Ini tidak terlihat seperti masalah yang mustahil diselesaikan
  • Jawabannya sebenarnya sederhana—pasang batas anggaran
  • Itulah juga alasan memakai server sungguhan yang bukan serverless, bukan server virtual semu
• Di Hetzner Anda bisa dapat 16TBx2 HDD, 1TBx2 SSD, 64GB RAM, dan 20TB trafik gratis seharga $70 per bulan. Sementara di instance micro AWS saya pernah membayar $150 hanya untuk trafik 1TB, setidaknya kalau saya ingat dengan benar. Tidak perlu seperti ini
• Tentang kisah "saya menaruh Cloudflare di depan konten saya, lalu seorang peretas menemukan objek yang tidak di-cache dan menghajarnya lebih dari 100 juta kali. Ketika saya memblokirnya, dia bahkan menemukan alamat bucket origin dan menyerangnya langsung", saya penasaran bukankah ini bisa terjadi pada siapa saja? Saya juga tidak tahu apakah bocornya objek yang tidak di-cache itu sama parahnya dengan membuka port 22 dengan kata sandi lemah, dan bukankah resource S3—terutama gambar—biasanya memang dibuat agar bisa diakses siapa pun sebanyak apa pun?
  • Sama sekali tidak. Bucket S3 harus privat dan aturan keamanan harus dibuat agar hanya bisa diakses lewat CDN. Dengan begitu semua akses dipaksa melewati CDN
  • Rasanya seperti membanggakan diri karena membiarkan celah OWASP Top 10 tetap ada. Pengaturan kontrol akses tidak sesulit yang dibayangkan, dan jika orang membuat kesalahan dasar seperti ini, kemungkinan besar mereka juga ceroboh di tempat lain. Saya tidak akan percaya pada sistem yang ditangani orang seperti itu
  • Dasar paling dasar adalah menjadikan objek S3 privat dan setidaknya menaruh proxy CloudFront di depannya. Hal seperti gambar harus dipaksa lewat cache
• Sulit menyebut ini serverless, karena pada kenyataannya tetap menjalankan server di infrastruktur cloud. Secara mendasar kita masih menulis perangkat lunak mengikuti model klien-server, dan harus ada server yang berjalan di suatu tempat agar pengguna bisa memakainya. Menurut saya, 'serverless' yang sejati adalah bentuk di mana pengguna mengunduh perangkat lunak sekali lalu bisa memakainya tanpa internet. Atau kalau pun data dikirim ke server, fungsinya tidak bergantung pada lokasi spesifik yang ditentukan developer
  • Istilah 'serverless' pada dasarnya berarti "sistem terkelola di mana resource (server) otomatis bertambah atau berkurang sesuai beban", dan itulah intinya. Saat beban naik server bertambah, saat beban turun server berkurang. Serverless hanya benar-benar menunjukkan nilainya jika Anda bisa mengubah seluruh struktur kode agar cocok dengan lingkungan seperti ini secara efisien. Artinya ini arsitektur yang seharusnya dipakai hanya ketika memang benar-benar dibutuhkan
  • Biasanya itu disebut perangkat lunak 'lokal'. Nama 'serverless' memang kurang bagus, tetapi sebenarnya itu membahas struktur deployment backend tertentu. Bukan aplikasi yang benar-benar tidak punya backend
  • 'Serverless' itu seperti "perusahaan tanpa karyawan". Sebenarnya tetap ada orang yang memberikan layanan, tetapi semuanya hanya pekerja kontrak
  • 'Server' biasanya berarti satu mesin dengan OS tertentu dan beberapa lapisan perangkat lunak di atasnya, termasuk tool monitoring, yang memungkinkan pengguna mengakses business logic. Kalau memakai server langsung, Anda harus memikirkan pilihan OS, instalasi/pembaruan perangkat lunak pendukung, pemulihan saat gagal, dan sebagainya. Serverless adalah model 'function as a service', jadi Anda hanya perlu memikirkan business logic—kode Anda. Tidak perlu memasang OS di server, tidak perlu memikirkan perangkat lunak dasar seperti HTTP server, dan tidak perlu menangani update atau maintenance. Cukup unggah kode dan kode itu akan dieksekusi saat dipanggil. Ini konsep pembebasan total dari stres mengoperasikan server. Karena itulah namanya 'serverless'—servernya memang ada, tapi Anda tidak perlu mengelolanya sendiri
• Kata "serverless" sebenarnya tidak berarti servernya tidak ada, melainkan Anda tidak perlu mengelola server secara langsung atau tahu di server mana kode Anda berjalan. Rasanya seperti, "nih saya kasih kode, tolong jalankan tiap satu jam. Di mana dijalankannya saya tidak peduli"
  • Kata ini mungkin terasa mengganggu, tetapi secara linguistik ini bukan masalah Orwellian. 'Newspeak' dalam 1984 bergerak ke arah menghilangkan keragaman ekspresi, sedangkan 'serverless' justru neologisme untuk menunjuk kategori baru. Tentu istilah ini bisa mengaburkan keberadaan server itu sendiri, tetapi tidak tepat kalau disebut Orwellian. Mungkin istilah seperti "servelet" sebagai 'server ringan' juga bisa dipakai
  • Ungkapan sinis seperti "cloud itu tidak ada, itu cuma komputer orang lain" juga sering dipakai
  • Pada akhirnya 'serverless' terasa seperti versi tech-bro dari 'shared hosting' lama dengan "margin 10.000%" dan model penagihan per request
  • Sistem "no-code" juga pada kenyataannya tetap berjalan dengan kode. Marah karena PaaS atau apa pun pada akhirnya punya server terasa seperti mencari-cari alasan
• Saya pernah memakai serverless AWS, dan pengujian lokal nyaris mustahil. Untuk serverless run juga wajib memakai AWS IAM role, sehingga seluruh akun terbuka dengan izin yang sangat luas. Akibatnya muncul masalah besar yang pada praktiknya tidak jauh berbeda dari menguji langsung di production setiap saat
  • Saya juga mengerjakan proyek serverless selama beberapa tahun, dan biaya terbesar memang karena hampir tidak bisa menjalankan apa pun secara lokal. Waktu debugging juga sangat lama. Tool-tool yang katanya jadi pengganti hampir tidak berguna untuk proyek nyata
  • Kalau file ~/.aws/credentials disetel dengan benar, Anda bisa melakukan pengujian lokal memakai security key AWS. Saya mengotomatisasi deployment Lambda dengan makefile, dan membuat IAM role kustom per Lambda untuk mengelola kebutuhan keamanan dalam file JSON. Keunggulan nyata AWS adalah semua hal bisa ditangani dengan API yang sama. Semuanya bisa dibuat dan dikelola secara programmatic
  • 1. Deploy dalam satu stack ke akun developer terpisah sebagai lingkungan staging gratis 2) Uji lokal dengan runtime Docker resmi 3) Tulis unit test seperti biasa 4) Emulasikan lingkungan staging di mesin Anda dengan tool seperti localstack—opsinya sangat banyak, jadi saya tidak paham kenapa pengalamannya bisa seburuk itu
  • Klaim yang sangat jauh dari kenyataan
• Menurut saya, penamaan 'serverless' tetap Orwellian, karena pada akhirnya hanya membungkus sistem yang justru berbasis server
• Sulit dipercaya perusahaan-perusahaan ini mengenakan biaya sampai $550 untuk 1TB bandwidth. Menyewa server dengan port terjamin 10Gb/s pun saya akan menganggapnya penipuan kalau biayanya lebih dari $3 per TB. Saya heran bagaimana serverless membenarkan biaya yang sampai 150 kali lipat ini. Apakah benar ada begitu banyak orang yang mau membayar harga seperti itu? Untuk wiki bacaan/dokumentasi teknis/blog, cukup taruh di VPS $10 atau GitHub Pages saja tanpa masalah, dan dengan setup yang lumayan Anda bahkan bisa menangani 10.000 koneksi bersamaan dengan mudah

[benjamin]

Bukankah sekarang kebanyakan orang yang baru pertama kali terjun ke pengembangan, saat membuat sesuatu dengan AI, meluncurkan layanannya memakai hal-hal seperti Vercel atau Supabase?

Tetapi ketika layanan mereka mulai membesar, sepertinya mereka tidak benar-benar menghitung berapa harga yang harus dibayar kepada platform-platform itu.
Dengan pola pikir, nanti saja dipikirkan saat waktunya tiba.

Pendiri Vercel atau Supabase tampaknya akan ikut mengangguk sambil tersenyum lebar, “Benar, benar, pikirkan saja nanti kalau saatnya sudah tiba!”

Tentu saja, memang bisa dipikirkan nanti. Asalkan Anda punya kemampuan untuk cepat keluar dari sana.
Tetapi tanpa pengetahuan tentang ilmu komputer, itu tidak akan mudah.
Bisa-bisa uang yang baru mulai Anda hasilkan habis diserahkan kepada mereka.

Sebenarnya, inilah yang sedang terjadi sekarang.
Jadi… sebuah bisnis besar sedang terbuka yang memakan uang para pemula yang terjun tanpa tahu apa-apa tentang ilmu komputer.

Inilah alasan mengapa kita harus terus mendalami ilmu komputer.
Ada orang yang menghabiskan 1 juta won per bulan untuk layanan yang baru mulai menghasilkan uang, sementara ada orang lain yang menjalankan layanannya tanpa membayar sama sekali.
Menghemat biaya operasional juga merupakan sebuah kemampuan. Bukankah itu keunggulan kompetitif yang luar biasa?
Menyenangkan memang menulis kode dengan AI, membuat sesuatu, dan merasakan keseruannya, tetapi jika tidak berusaha masuk lebih dalam, pada akhirnya Anda tidak akan bisa menciptakan perbedaan.

https://jeho.page/essay/2025/09/08/sucker-developer.html