Serverless Itu Tipuan: Pakai Container Saja
(sliplane.io)- Serverless terlihat praktis, tetapi pada praktiknya merupakan pendekatan yang memicu kompleksitas, keterbatasan, dan biaya tinggi
- Container memberikan portabilitas, kemampuan mempertahankan state, dan kontrol yang jelas, sehingga lebih cocok untuk sebagian besar kasus penggunaan
- Serverless memiliki struktur biaya yang tidak transparan dan sulit diprediksi, serta menimbulkan kompleksitas yang tidak perlu antarkomponen
- Skalabilitas dan kemudahan serverless hanya cocok untuk kasus penggunaan yang terbatas
- Di lingkungan produksi nyata, deployment berbasis container lebih sederhana, skalabel, dan efisien dari sisi biaya
Serverless Is a Scam. Just Use a Container.
Apa itu serverless?
- Serverless adalah cara mendeploy kode per fungsi individual, di mana platform cloud menangani eksekusi dan scaling secara otomatis
- Namun, pada praktiknya ada sejumlah masalah berikut
- Batas waktu eksekusi (contoh: AWS Lambda dibatasi 15 menit)
- Tidak bisa mempertahankan state (diinisialisasi ulang pada setiap eksekusi)
- Masalah cold start
- Lingkungan yang sulit di-debug
- Pengaturan dan konfigurasi spesifik platform
- Penggunaan YAML yang berlebihan
- Terlihat sederhana, tetapi tidak cocok untuk pekerjaan yang kompleks
Container: sederhana, kuat, dan membosankan dalam arti yang baik
- Container memiliki kelebihan berikut
- Start cepat
- Dapat dijalankan di lingkungan mana pun
- Bisa mempertahankan state (menggunakan
Docker volume) - Tidak ada batas waktu eksekusi
- Bebas untuk debugging, pengembangan lokal, dan perpindahan ke lingkungan produksi
- Contoh kode:
docker run -v my-data:/data my-app - Hasilnya, workload yang memiliki state dapat dijalankan secara konsisten di mana saja
- Tanpa vendor lock-in, tanpa biaya tersembunyi, tanpa perubahan arsitektur yang tidak perlu
Penetapan harga serverless: mendorong kebingungan pengguna
- Biaya serverless disusun dengan sangat rumit
- Biaya per invocation
- Penggunaan memori
- Waktu eksekusi
- Jumlah data yang ditransfer
- Perbedaan tarif per region
- Biaya akses secret key, dan lain-lain
- Contoh istilah yang membingungkan:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- Karena struktur penagihannya tidak dapat diprediksi, bisa muncul tagihan tak terduga
- Perbandingan: VPS seharga $5 menawarkan biaya tetap yang bisa diprediksi dengan kontrol penuh atas semua resource
Bantahan terhadap “serverless itu skalabel”
- Serverless secara teknis memang bisa diskalakan, tetapi pada kenyataannya sebagian besar aplikasi tidak membutuhkannya
- Yang dibutuhkan oleh kebanyakan aplikasi adalah hal-hal berikut
- Prediktabilitas
- Kemudahan monitoring
- Batas resource yang memadai
- Lingkungan development dan staging
- Dalam pendekatan berbasis container, scaling juga sederhana
replicas: 5 - Atau dapat melakukan scale-out horizontal menggunakan load balancer
Desain stateless menciptakan masalah yang artifisial
- Serverless memaksa desain stateless tanpa pengecualian
- Tidak bisa menggunakan cache, session, file sementara, atau koneksi persisten
- Akibatnya, elemen yang dibutuhkan menjadi
- Database eksternal
- Cache terdistribusi
- File storage
- Event bus
- State machine
- Pada akhirnya, aplikasi serverless yang “sederhana” justru memiliki lebih dari 6 dependensi SaaS
- Sebaliknya, di container hal-hal berikut dimungkinkan
- Cache in-memory
- Penulisan ke disk
- Mempertahankan session
- Eksekusi tanpa batas waktu
Jawaban untuk “saya tidak ingin mengelola server”
- Ada cara menggunakan platform berbasis container tanpa harus mengelola server
- Gunakan platform seperti Sliplane, Railway, Coolify, dll.
- Atau cukup dengan Docker + systemd di VPS
- Deployment berbasis Git, rollback, logging, metrics, dan kemudahan operasional lainnya tetap tersedia
- Anda juga tetap memiliki pemahaman dan kontrol terhadap keseluruhan sistem
Bantahan terhadap klaim “serverless lebih murah”
- Pada frekuensi invocation yang sangat rendah, memang bisa lebih murah
- Tetapi biaya akan melonjak dalam situasi berikut
- Jika traffic melewati tingkat tertentu
- Jika perlu menambah memori
- Jika beban komputasi nyata cukup besar
- Jika transfer data tinggi
- Serverless membuat optimisasi menjadi sulit karena platform menyembunyikan semuanya
- Sebaliknya, container
- Dapat terus berjalan di hardware murah
- Dapat digabungkan dengan cache dan storage
- Mudah di-benchmark dan di-tuning
- Tidak ada biaya per milidetik
Kapan serverless benar-benar cocok
- Cocok untuk pekerjaan yang sporadis dan stateless seperti berikut
- Fungsi berbasis event (contoh: image resizing)
- Tugas yang jarang dijalankan atau webhook
- Alat internal
- POC
- Saat perlu scale up/down dengan cepat
- Namun, pada aplikasi nyata, pendekatan ini akan mencapai batasnya, dan
- Anda akan membayar harga yang besar dalam waktu, biaya, dan kompleksitas
Mengapa container adalah pilihan yang lebih baik
- Container memberikan hal-hal berikut
- Portabilitas
- Kontrol
- Kesederhanaan
- Transparansi
- Fleksibilitas
- Semuanya dimungkinkan: deployment satu atau banyak container, scaling, mempertahankan state, pekerjaan background, hingga integrasi DB
- Platform juga bisa diganti tanpa perlu menulis ulang kode
Ringkasan (TL;DR)
- Serverless tampak keren secara teori
- Dalam kenyataannya:
- Tidak transparan
- Mahal
- Terlalu kompleks
- Terlalu dibesar-besarkan
Sebelum memulai, tanyakan pada diri sendiri:
“Apakah ini tidak bisa dibuat begitu saja dengan container?”
- Jika jawabannya ‘ya’, maka memulai dengan container adalah pilihan yang lebih baik
Tindak lanjut yang disarankan
- Disarankan untuk membagikan contoh pengalaman menghadapi biaya tak terduga atau workflow yang tidak efisien akibat serverless
- Jangan membuat masalah yang sederhana menjadi terlalu rumit
19 komentar
Ada xfaas.. juga ada cf workers. Sepertinya ini tulisan yang bias.
Saya sempat berpikir untuk menjalankannya sebentar sebagai fungsi serverless saat menyewa GPU.
Apakah itu juga bisa dilakukan dengan container?
Di masa layanan web hosting PHP dulu, kalau PHP-nya dilepas lalu diganti JS yang penuh vendor lock-in....
Saya tidak bisa menghilangkan pikiran bahwa jadinya akan sulit dibedakan dari platform FaaS serverless yang umum.
Tentu saja, sebagai penikmat hal-hal nyeleneh yang terutama memakai PHP dan JS/TS, saya sendiri memakainya dengan puas,
tapi saya juga tidak terlalu paham kenapa banyak orang menilai ini terasa enak.
Menurut saya pribadi, menggunakan layanan serverless milik vendor itu berisiko, tetapi menyediakan lingkungan serverless sendiri di perusahaan dengan memanfaatkan container tampaknya ide yang bagus. Akan lebih baik jika serverless dimanfaatkan bukan sebagai layanan, melainkan sebagai sebuah konsep.
Beberapa waktu lalu, tweet dan video[1] tentang menyerah pada Edge rendering milik Vercel, serta tulisan tentang serverless server (wkwkwk)[2], sempat ramai, ya. Sepertinya saya juga punya pandangan yang mirip dengan tulisan-tulisan yang muncul saat itu.
Ini pendapat pribadi, tetapi dari sudut pandang developer frontend, menurut saya menempelkan serverless function ke request pengguna masih merupakan cerita yang cukup jauh untuk saat ini (kecuali aplikasi yang ingin dibuat hanyalah MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Tentu saja, seperti yang juga disebutkan di postingan ini, sepertinya ini memang tulisan yang terlalu provokatif untuk memancing perhatian :(
Sebagai orang yang pernah merasakan langsung lingkungan berbasis kontainer (berpusat pada ECS Fargate, klaster Kubernetes) dan lingkungan serverless (AWS), saya pribadi tidak terlalu merasa relate dengan argumen itu.
Poin-poin yang disebut sebagai keunggulan lingkungan berbasis kontainer justru merupakan hal-hal yang bisa menjadi kelebihan sekaligus kelemahan.
Semua hal yang disebut dengan alasan 'bisa dikendalikan langsung dan bisa memiliki state' pada akhirnya menjadi titik pengelolaan yang membuat tingkat kesulitan operasional lebih tinggi.
Saya justru sangat merekomendasikan serverless untuk organisasi kecil, terutama yang tidak memiliki tim pengelolaan server yang profesional.
Ah, saya setuju soal perhitungan biaya yang rumit atau sulit diprediksi, serta masalah vendor lock-in.
Karena ada yang membahas pengalaman pengembangan dan observability, saya ingin menambahkan,
kalau lingkungan integrasi awal disusun dengan baik, Anda bisa mendapatkan pengalaman pengembangan yang tidak kalah dari yang berbasis container, bahkan mungkin lebih mendekati native dibanding yang berbasis container. (Ada berbagai tool untuk itu juga.)
Soal observability, kalau ingin mendalaminya, baik serverless maupun berbasis container sama-sama bukan persoalan yang mudah. Sentralisasi log, visualisasi berbagai metrik, APM, visualisasi penggunaan CPU/memori, lalu menyusun strategi scaling berdasarkan itu, dan seterusnya...
Kalau belum sampai tahap itu, integrasi metrik/log yang disediakan secara default oleh cloud vendor sudah cukup kuat, jadi pada akhirnya kurang lebih sama saja.
Kalau mau mengungkapkannya secara agresif, saya jadi ingin bertanya, 'Sejauh mana Anda sudah benar-benar mencoba serverless?'...😅
Saya juga sempat berpikir bukankah lebih baik hanya menjalankan endpoint tertentu yang memang diperlukan di Lambda. Dari awal saya sendiri tidak punya pengalaman mengembangkan dengan serverless jadi tidak bisa banyak berkomentar, tetapi untuk beberapa kasus yang khusus sepertinya memang terlihat cocok.
Bukankah perusahaan yang menulis artikel ini adalah perusahaan platform hosting container, jadi mungkin mereka menulisnya dari sudut pandang yang bias? hehe
Sebelumnya juga ada yang meragukan tulisan dari developer Netlify (kompetitor) yang mengkhawatirkan Next.js (Vercel) di sisi frontend, kan. Melihat komentarnya, sepertinya tidak terlalu bias.
Saya orang frontend jadi... tidak terlalu dekat dengan bidang ini, tapi saya memang cukup sering melihat meme bahwa serverless itu sebenarnya tetap ada servernya haha
Pain point terbesar adalah pengalaman pengembang yang jauh lebih buruk dibanding native, dan karena perangkat lunaknya sendiri jadi memiliki ketergantungan pada penyedia infrastruktur, begitu sudah terlanjur menetap akan sulit untuk keluar. Bukan cuma referensinya yang jauh lebih sedikit, observability-nya juga sangat buruk.
Cloudflare tampaknya, setidaknya dibanding perusahaan lain, sedang berusaha menjalankan serverless dengan lebih baik. Database juga serverless, penyimpanan key-value juga serverless, bahkan message queue pun ada yang serverless...
(Tentu saja, kalau jadinya begini, kadang muncul juga rasa enggan karena terasa sepenuhnya bergantung dan terikat pada platform)
Meski begitu, jika debugging, observability, dan pengalaman pengembang tidak membaik, hasilnya tetap saja jalan di tempat.
pakai cloud run aja
Menjalankan layanan dengan serverless berarti memilih alat yang salah.
Ada masalah tertentu yang memang membutuhkan serverless. Cocok untuk penggunaan yang sesekali.
Apakah pendapatnya sama untuk layanan container serverless juga?
Karena masalah-masalah pada layanan serverless yang sudah ada (seperti Lambda), AWS membuat Fargate dan bahkan membuat App Runner yang lebih sederhana 🤔
Bahkan ada juga layanan container serverless
scale to zeroyang luar biasa dari Google Cloud, yaitu Cloud RunDari yang di atas, secara pribadi menurut saya pengalaman pengembang terbaik ada di Cloud Run
Serverless (server tetap ada)
Opini Hacker News
Dari awal memang bukan
Serverless, melainkanServerlease.Wkwkwkwk