- Unkey, penyedia layanan autentikasi API, beralih dari arsitektur serverless berbasis Cloudflare Workers ke server stateful berbasis Go untuk mengatasi masalah performa dan kompleksitas arsitektur
- Struktur baru ini menghadirkan kecepatan respons 6x lebih cepat sekaligus menghilangkan cara-cara bypass cache yang rumit dan overhead pipeline data
- Di lingkungan serverless, karena tidak ada jaminan memori persisten antar pemanggilan fungsi, setiap pembacaan cache memerlukan permintaan jaringan, yang menimbulkan latensi cache p99 di atas 30ms
- Dengan beralih ke arsitektur aplikasi yang lebih sederhana dari sistem terdistribusi, self-hosting menjadi memungkinkan, independensi platform tercapai, dan pengalaman developer juga meningkat drastis
- Serverless cocok untuk workload yang tidak teratur atau pola request/response yang sederhana, tetapi jika dibutuhkan latensi rendah yang konsisten atau pengelolaan state persisten, server stateful lebih efektif
Batasan serverless dan bottleneck performa
- Bagi Unkey, autentikasi API berada di jalur kritis request, sehingga latensi dalam hitungan milidetik langsung memengaruhi pengalaman pengguna
- Deployment edge global dan auto-scaling Cloudflare Workers memang menarik, tetapi ketiadaan persistensi cache dan latensi permintaan jaringan akhirnya menjadi masalah
-
Masalah caching
- Fungsi serverless tidak memiliki memori persisten antar pemanggilan, sehingga setiap lookup cache memerlukan permintaan jaringan eksternal
- Latensi p99 lookup cache Cloudflare terukur lebih dari 30ms
- Sekalipun menumpuk beberapa lapisan cache (SWR, Redis, dll.), secara mendasar tidak bisa lebih cepat daripada ‘0 permintaan jaringan’
- Akibatnya, target respons di bawah 10ms tidak bisa tercapai
-
Masalah coupling dengan SaaS
- Serverless memang mengurangi beban pengelolaan infrastruktur, tetapi pada praktiknya alat SaaS tambahan justru menjadi keharusan
- Cache → Redis, pemrosesan batch → Queue, log → Durable Objects, dll.
- Setiap layanan menambah latensi, biaya, dan titik kegagalan
- Meski mencampurkan Cloudflare Durable Objects, Queues, Workflows, dan lainnya, kompleksitas nyata justru meningkat
-
Masalah pipeline data
- Karena serverless adalah lingkungan yang ephemeral, data harus segera di-flush pada setiap pemanggilan
- Untuk menangani event, log, dan metrik, mereka harus membangun sendiri layanan buffering dan relay yang kompleks
- Contoh:
- Mengirim batch log ke ClickHouse melalui
chproxy
- Membangun server buffering terpisah untuk menghindari rate limit saat mengirim log ke Axiom
- Hasilnya, bahkan fungsi analitik yang sederhana pun menimbulkan kompleksitas setingkat sistem pemrosesan event terdistribusi
Beralih ke server berbasis state
- Dengan mengadopsi server stateful berbasis Go (v2), batching dalam memori dan flush berkala menjadi memungkinkan
- Tidak perlu layanan tambahan atau pipeline yang rumit
- Maintainability, debugging, dan pengujian lokal menjadi jauh lebih sederhana
-
Hasil performa
- Perbandingan
/v1/keys.verifyKey dan /v2/keys.verifyKey menunjukkan latensi turun 6x lipat
- Walau infrastrukturnya lebih sedikit daripada 300 POP global Cloudflare, performa yang dirasakan pengguna meningkat signifikan
Manfaat di luar performa
-
Self-Hosting
- Karena bergantung pada runtime Cloudflare, pelanggan sebelumnya tidak bisa melakukan self-host Unkey
- Runtime Workers memang secara teknis open source, tetapi sangat sulit dijalankan secara lokal, bahkan dalam mode pengembangan
- Dengan beralih ke server Go standar, self-hosting menjadi mudah
- Cukup jalankan perintah
docker run -p 8080:8080 unkey/api
- Tidak perlu runtime khusus atau konfigurasi rumit
- Developer kini bisa menjalankan seluruh stack Unkey secara lokal dalam hitungan detik, sehingga debugging dan testing menjadi jauh lebih mudah
- Kecepatan pengembangan dan debugging lokal meningkat drastis
-
Peningkatan pengalaman developer
- Batasan yang sebelumnya ditemui di serverless:
- Perlu mempertimbangkan batasan eksekusi fungsi
- Sulit mempertahankan state antar pemanggilan
- Debugging log terdistribusi rumit
- Lingkungan pengujian lokal tidak nyaman
- Dengan beralih ke server stateful, pajak kompleksitas (Complexity Tax) ini dapat dihilangkan
-
Mendapatkan independensi platform
- Tidak lagi bergantung pada ekosistem Cloudflare
- Bisa di-deploy di mana saja
- Bisa menggunakan database apa pun
- Dapat mengintegrasikan layanan pihak ketiga tanpa khawatir kompatibilitas runtime
Strategi migrasi dan pelajaran yang didapat
- Migrasi dimanfaatkan sebagai kesempatan untuk memperbaiki masalah desain API yang menumpuk seiring waktu
- API v2 baru berjalan berdampingan dengan v1 lama, sehingga pelanggan dapat menggunakan kedua versi selama masa deprecation
- Salah satu keuntungan mempertahankan serverless adalah biaya menjalankan API v1 tetap rendah meski penggunaan turun ke nol, sehingga ada masa migrasi gratis
-
Hal-hal yang tetap dipertahankan
- Mereka tidak membuang seluruh pendekatan serverless
- Deployment edge global: memakai AWS Global Accelerator untuk mempertahankan latensi rendah di seluruh dunia
- Auto-scaling: Fargate menangani scaling tanpa batasan serverless
-
Peningkatan performa rate limiter
- Dalam model serverless, dibutuhkan trade-off besar antara kecepatan, akurasi, dan biaya, dan karena sifatnya terdistribusi, hampir mustahil mencapai ketiganya sekaligus
- Dengan server stateful dan state in-memory, mereka membangun rate limiter yang lebih cepat, lebih akurat, dan lebih murah untuk dioperasikan
Kapan serverless cocok (dan kapan tidak)
-
Saat serverless cocok
- Workload tidak teratur: ketika tidak berjalan terus-menerus, skala ke nol sangat unggul secara ekonomis
- Pola request/response sederhana: ketika tidak memerlukan state persisten atau pipeline data yang kompleks
- Arsitektur event-driven: sangat baik untuk merespons event tanpa perlu mengelola infrastruktur
-
Saat serverless tidak cocok
- Saat dibutuhkan latensi rendah yang konsisten: ketergantungan pada jaringan eksternal menurunkan performa
- Saat dibutuhkan state persisten: upaya mengakali sifat stateless justru menambah kompleksitas
- Workload frekuensi tinggi: model biaya per panggilan menjadi tidak ekonomis
- Saat dibutuhkan kontrol yang detail: abstraksi platform bisa menjadi batasan
-
Biaya kompleksitas
- Pelajaran terbesar dari migrasi ini adalah memahami biaya kompleksitas dari upaya mengakali batasan platform
-
Hal-hal yang dibangun di serverless
- Library caching canggih untuk mengakali sifat stateless
- Beberapa layanan pendukung untuk pemrosesan batch data
- Pipeline log yang kompleks untuk pengumpulan metrik
- Cara-cara bypass yang rumit untuk pengembangan lokal
-
Di server stateful
- Semua hal di atas menghilang
- Beralih dari sistem terdistribusi dengan banyak komponen bergerak ke arsitektur aplikasi yang sederhana
- Terkadang, memilih fondasi yang berbeda adalah solusi terbaik daripada terus mengakali batasan
Langkah berikutnya
- Saat ini berjalan di AWS Fargate di belakang Global Accelerator, tetapi ini hanya solusi sementara
- Tahun depan mereka berencana meluncurkan platform deployment sendiri, "Unkey Deploy", yang memungkinkan pelanggan (dan Unkey sendiri) menjalankan Unkey di mana pun yang mereka inginkan
- Peralihan ke server Go stateful adalah langkah pertama untuk menjadikan Unkey benar-benar portabel dan bisa di-self-host
- Detail implementasi dipublikasikan sebagai open source di repositori GitHub
3 komentar
Saya juga dulu hampir seperti penganut fanatik serverless dan sangat gencar mendorong arsitektur serverless, tetapi belakangan ini saya lebih memilih struktur yang dibangun dengan satu EC2 dan satu RDS. Lalu secara bertahap memisahkan hal-hal yang memang diperlukan satu per satu. Jadi, penerapan serverless pun akhirnya saya lakukan setelah banyak pertimbangan.
Ada berbagai alasan, tetapi saya merasa bahwa jika di tim ada bahkan hanya satu orang yang tidak punya pengetahuan tentang serverless, biaya komunikasi/pemeliharaan meningkat cukup besar. Dan setelah kembali mengelola server, saya kembali menyadari bahwa serverless ternyata tidak semurah atau semudah yang saya bayangkan.
Opini Hacker News
Sebagai seseorang yang sudah beberapa tahun menggunakan lingkungan serverless (terutama amazon lambda, dan juga yang lain), saya sangat setuju dengan pendapat penulis.
serverless memang mengurangi pekerjaan di beberapa sisi, tetapi secara bersamaan malah menambah pekerjaan di area lain karena harus menyelesaikan "masalah-masalah buatan" yang muncul.
Salah satu contoh yang saya alami adalah masalah batas ukuran upload.
Ketika memindahkan aplikasi yang sudah ada ke serverless, saya pikir cukup membuat endpoint API untuk import data pelanggan berukuran besar dan menambahkan worker di background.
Namun di "api gateway" (proxy yang memanggil kode), upload di atas 100MB tidak dimungkinkan, dan ketika saya bertanya apakah batas itu bisa diubah, saya hanya diberi tahu agar pelanggan mengunggahnya dalam file-file yang lebih kecil.
Secara teknis itu mungkin terdengar masuk akal, tetapi kenyataannya pelanggan sungguhan tidak akan mengubah cara mereka mengunggah file.
Rasanya seperti "berfungsi dengan baik di ruang hampa"; secara teori terlihat keren, tetapi ketika benar-benar dijalankan, waktu dan biaya yang dihemat dari beralih ke serverless akhirnya harus diinvestasikan kembali untuk mengatasi masalah khas serverless.
Untuk menyelesaikan masalah ini, Anda perlu menyediakan presigned S3 URL.
Integrasinya bisa dilakukan dengan membiarkan pengguna mengunggah langsung ke S3 lalu mengirimkan hasil uploadnya, atau dengan cara seperti membedakan nama file menggunakan request id.
Dari sudut pandang orang yang sudah lama memakai lingkungan AWS, hal seperti ini memang menjengkelkan, tetapi saya bisa memahami batas 100MB itu sendiri karena membuka API upload file arbitrer punya risiko besar terhadap serangan DoS.
Meski begitu, kalau melihat kecepatan internet sekarang yang sudah jauh lebih cepat, ambang 100MB terasa agak ketinggalan zaman.
Tetap saja, saya rasa pada akhirnya batas seperti itu memang diperlukan.
Perusahaan kami pernah menjadi pelanggan yang mewakili divisi sertifikat AWS SSL.
Untuk mendukung Vanity URL (domain kustom), kami membutuhkan sertifikat SSL untuk tiap domain, dan jumlahnya mencapai ribuan.
Alat manajemen sertifikat AWS hanya nyaman digunakan sampai skala ratusan, jadi butuh sekitar 3 bulan sampai masalah ini terselesaikan.
Mengejutkan bahwa beberapa layanan AWS tidak bisa merespons cepat kebutuhan segelintir pelanggan dengan skala seperti itu.
Awalnya Lambda terlihat sangat menjanjikan sehingga kami mengadopsinya, tetapi pada akhirnya kami meninggalkan semua proyek Lambda dan memindahkannya ke lingkungan kontainer sesuai kebutuhan.
Lambda juga tetap harus meng-upgrade runtime Node setiap 1~2 tahun, dan jika memakai kontainer kita bisa menentukan sendiri siklus itu, jadi lebih fleksibel.
Masalah tersulit dalam ilmu komputer adalah menyalin file dari satu komputer ke komputer lain.
Saya meninggalkan referensi untuk pembaca di masa depan.
Dengan memakai uploader dan endpoint "tus", kita mendapatkan fitur seperti pemecahan upload dan resume, sehingga cocok untuk mengatasi batasan seperti ini.
https://tus.io/
Seperti yang dijelaskan di artikel, serverless jelas punya kegunaannya sendiri.
Tetapi saya rasa itu tidak cocok untuk sebagian besar aplikasi.
Kecuali dalam situasi khusus, saya tidak berencana memakai serverless sebagai infrastruktur inti.
Kesan saya justru pengelolaan infrastrukturnya menjadi lebih merepotkan.
Tiap platform punya persyaratan berbeda, cara testing/development juga berbeda-beda, jadi selalu terasa serba tanggung dan pengujian lokal pun sulit.
Layer abstraksinya juga penuh jebakan di tiap platform, dan tidak ada standar yang benar-benar nyata.
Menurut saya jauh lebih nyaman mengemas executable dengan image Docker, dan setup lingkungan juga bisa diabstraksikan secukupnya sehingga terasa lebih alami sebagai lingkungan pengembangan.
Abstraksi minimum pada level lingkungan Linux dan filesystem terasa paling efisien.
Kalau perlu, image itu juga bisa dijalankan sebagai server dan dioperasikan secara on-demand atau selalu siaga.
Kalau melihat berbagai tren teknologi yang populer selama 10 tahun terakhir, sering kali yang menjadi ramai adalah teknologi yang dipakai perusahaan besar untuk menyelesaikan masalah yang secara nyata hanya ada pada skala mereka sendiri.
Contohnya termasuk GraphQL, react, Tailwind, NextJS, dan banyak lainnya.
Tidak ada alat yang merupakan solusi universal untuk semua masalah, dan yang penting adalah memilih berdasarkan pengalaman serta pemahaman terhadap situasi dan masalah kita sendiri.
Saya bahkan ingin menunjukkan betapa "menyenangkannya" saya sekarang mencoba menjalankan aplikasi amazon lambda secara lokal.
Mencobanya sebelum deploy benar-benar merupakan tantangan tersendiri.
Knative (Serverless untuk Kubernetes) menerima kontainer secara langsung.
Karena itu format packaging standar, ia mudah dipindahkan ke berbagai platform.
Tim itu sebenarnya sedang mengembangkan library yang akan diintegrasikan ke aplikasi server stateful, bukan aplikasi itu sendiri.
Keuntungan performanya juga datang karena authentication diproses dekat dengan lingkungan pelanggan, bukan karena serverless itu sendiri.
Bukankah sebenarnya semua platform "serverless" menerima image Docker?
Setahu saya Cloud Run mendukungnya.
Sebenarnya kekhawatiran saya adalah soal “serverless function” yang mengabstraksikan terlalu banyak hal.
ClickHouse tidak suka ribuan insert kecil, jadi kami mengumpulkan event dengan layanan Go bernama chproxy lalu mengirimkannya dalam batch besar.
Setiap Cloudflare Worker mengirim event analitik ke chproxy, lalu chproxy mengumpulkannya dan mengirimkannya secara massal ke ClickHouse.
Untuk data ClickHouse saja, saya penasaran kenapa mereka tidak memakai fitur insert asinkron, alih-alih membuat layanan terpisah khusus untuk itu.
https://clickhouse.com/docs/optimize/asynchronous-inserts
Rasanya para developer tenggelam dalam tool yang katanya "mempermudah".
Padahal kebanyakan masalah sebenarnya bisa diselesaikan dengan mudah memakai alat paling dasar (compiler, bash script, library).
Keterikatan seperti ini pada tool kadang justru merugikan baik perusahaan maupun developer.
Menurut saya, Docker pada 2013 adalah tool terakhir yang benar-benar membawa perubahan universal dan positif.
Setelah itu, ada banyak hal yang mungkin membantu perusahaan tertentu, tetapi ketika dipaksakan ke semua perusahaan justru merusak produktivitas atau membuat sistem ambruk.
Akhir-akhir ini tempat seperti Cloudflare mendorong v8 isolates seolah-olah itu akan menjadi 'docker generasi berikutnya', tetapi itu tepat sasaran untuk sebagian workload, bukan untuk semuanya.
Pola "menerima image docker lalu menayangkannya di internet" terlalu kuat, jadi saya rasa itu masih akan menjadi pendekatan terkuat bahkan pada 2040.
Masalah lainnya adalah semakin sedikit orang yang benar-benar memahami dasar-dasarnya.
Pekerjaan dilakukan dengan mengalihdayakan sebagian besar stack ke layanan pihak ketiga, sementara yang benar-benar dibuat sendiri hanya sebagian dari aplikasi inti.
Bahkan bagian itu pun bisa saja ditulis oleh AI.
Seluruh industri sedang menumbuhkan "ketidakberdayaan yang dipelajari".
Jauh lebih banyak orang daripada yang dibayangkan ternyata tidak begitu paham compiler, bash script, dan library.
AWS lambda itu terlalu murah.
Itu membantu untuk meningkatkan visibilitas!
Saya belum pernah melihat orang naik sampai level Staff hanya dengan menulis bash script.
Saya ingin bertanya kepada "vercel security checkpoint".
Di iPhone, jika saya terhubung lewat kombinasi proton VPN dan Firefox Focus dengan exit node California atau Kanada, saya terus-menerus mendapat error code 99 "Failed to verify your browser".
Apa masalahnya?
Thread ini membuat saya makin yakin dengan pendapat saya.
Istilah serverless sendiri definisinya terlalu kabur, jadi namanya terasa seperti omong kosong.
Pada akhirnya server tetap ada.
Ini mirip seperti menyebut sesuatu "tanpa listrik", padahal sebenarnya tetap memakai listrik.
Namanya saja yang berubah, tetapi tidak benar-benar menjelaskan apa yang sedang terjadi.
Saya rasa kesimpulannya bukan sekadar "serverless itu buruk".
Pelajaran yang lebih penting adalah bahwa jika ada dependensi pada sebuah layanan, memindahkan layanan itu lebih dekat ke klien tidak serta-merta mempercepat pengalaman end-to-end kecuali dependensi itu ikut dipindahkan juga.
Pada akhirnya lebih baik membangun dekat dengan dependensinya, dan kalau itu tidak cukup, semua dependensi juga harus dipindahkan atau disinkronkan agar dekat dengan klien, tetapi dalam praktiknya proses itu sering menjadi sangat rumit.
Itu tergantung bagaimana dan seberapa sering dependensi dipakai, dan kalau itu DB, apakah lebih baik dekat server atau dekat klien juga berbeda tergantung kebutuhannya.
Pada beberapa skenario penggunaan, respons cepat itu penting, sementara pada yang lain lambat pun tidak masalah.
Tergantung apa yang bisa di-cache di server atau di klien, itu juga bisa dipecah.
Saya rasa ini tidak harus dipandang secara hitam-putih.
Jika Anda menginginkan rasio harga terhadap performa terbaik, jawabannya adalah menyiapkan instance sendiri dan menangani sendiri pekerjaan yang dibutuhkan.
Tidak perlu membiarkan penyedia cloud menjadi penyihir penagihan berlebihan.
Saat ini "local maximum" yang kami capai adalah menjadikan kontainer Docker sebagai lingkungan/deployment artifact standar dan hanya menyuntikkan secret bila perlu.
Dengan begitu, pengujian lokal menjadi mudah, dan sebagian besar manfaat utama seperti otomasi infrastruktur serta reproduksibilitas tetap bisa dipertahankan.
serverless terlalu berlebihan untuk sebagian besar aplikasi, tetapi sangat cocok untuk beberapa aplikasi tertentu.
Khususnya untuk utilitas sederhana atau layanan on-demand yang tidak memerlukan infrastruktur sendiri, serta aplikasi stateless berskala besar, serverless bisa lebih cocok.
Bukan berarti serverless hanya dipakai untuk hal-hal sederhana; saya justru merasa ada kontradiksi mendasar antara model "webapp tradisional" dan platform serverless.
Sepertinya sekarang Anda siap menerima misterio.
https://github.com/daitangio/misterio
Ini wrapper klaster docker stateless yang sederhana.
Awalnya dimulai dari homelab saya, lalu mendapat respons yang lebih besar.
Docker agak mirip dengan microservices.
Itu cocok untuk sebagian aplikasi, tetapi cenderung dibesar-besarkan seolah-olah standar industri.
Jika Docker dipakai berlebihan, akan muncul beban patch keamanan dan operasional, dan jika diterapkan ke semua proyek tanpa pikir panjang maka pengelolaan risiko akan gagal.
Masalah dependensi juga sekarang sudah diselesaikan oleh sebagian besar developer dengan pola tidak memasang secara global.
Docker tidak sepenting dulu, tetapi tetap dominan.
Dari sudut pandang penyedia hosting, saya memperkirakan margin akan naik setidaknya 10% dengan adopsi Docker.
Saya merasa Docker juga termasuk dalam "obsesi pada tool" yang disebutkan seseorang di bawah.
Intinya bukan bahwa serverless itu tidak bekerja, melainkan para penulis tidak benar-benar memahami fondasi yang mereka bangun.
Menaruh API yang sensitif terhadap latensi di edge runtime stateless adalah kesalahan tingkat pemula, dan penderitaan yang mereka alami sebagai akibatnya sepenuhnya bisa diprediksi.
Menurut pengalaman saya, sebagian besar masalah layanan cloud berasal dari penyalahgunaan atau kesalahpahaman arsitektur.
Itu adalah masalah manusia yang sebenarnya bisa dihindari dengan desain yang lebih hati-hati.
Namun masalahnya, kebanyakan vendor cloud memasarkan produknya dengan marketing yang meyakinkan sambil menyembunyikan angka performa yang sebenarnya.
Apakah Lambdas benar-benar cukup cepat untuk workload saya, atau apakah replikasi eksternal AWS RDS cocok, itu tidak akan diketahui sampai diuji.
Saya belajar dari pengalaman bahwa performa nyata AWS harus dibenchmark sendiri.
Bukan soal para penulis tidak memahaminya; yang penting adalah informasi yang dibagikan seseorang itu sendiri bernilai.
Saya rasa ini tidak bisa hanya disebut sebagai "kesalahan pemula".
Pada kenyataannya, engineer sering kali tahu bahwa pendekatan tertentu tidak cocok untuk pekerjaan nyata, tetapi manajer kerap mendorongnya begitu saja karena dianggap "cara modern".
Atau karena batas waktu dan biaya, kadang kita terpaksa memilih opsi yang "kurang baik".
Atau memang bisa saja tim implementasi aslinya benar-benar belum memahami dengan baik, tetapi bagaimanapun juga, berbagi cerita seperti ini sangat membantu perkembangan komunitas kita secara keseluruhan.
Menurut pengalaman saya, jika Anda membutuhkan sesuatu yang pasti (auto scaling cepat, latensi rendah, CPU, disk, kecepatan jaringan, dll.), cara paling pasti adalah mengelola instance EC2 sendiri.
Jika Anda menyerahkan kendali sambil berharap performa meningkat, Anda akan menghadapi bottleneck yang tidak bisa diperbaiki.
Pada akhirnya, ini sama saja dengan mengakui bahwa para penulis adalah "satu dari 10.000 orang hari ini".
https://xkcd.com/1053/
Secara pribadi saya berterima kasih karena mereka telah membagikan informasi dan kesalahan seperti ini.
Rekayasa pada akhirnya selalu merupakan pertarungan biaya
Di tahap awal, hal ini digunakan untuk mengurangi waktu dalam membuat prototipe atau membangun bisnis
Belakangan, biaya harus ditekan sambil melakukan optimasi
Tulisan seperti ini sendiri membuktikan betapa dirinya bukan seorang engineer
Seperti in