Serverless Computing Adalah: Cara Kerja, Biaya & Batasnya

Menyewa server berarti membayar kapasitas untuk sebulan penuh, sementara permintaan ke aplikasi Anda tidak pernah rata. Ada jam sibuk di sore hari, ada dini hari yang nyaris sepi. Laporan State of Containers and Serverless dari Datadog (November 2025) menemukan sebagian besar workload di cloud memakai kurang dari 25% CPU yang mereka minta. Sisanya tetap dibayar meski tidak pernah tersentuh.

Serverless computing adalah model yang membalik urutan tersebut. Alih-alih menyiapkan kapasitas lebih dulu lalu berharap terpakai, Anda menyerahkan kode ke penyedia cloud dan kapasitas baru dialokasikan pada detik permintaan benar-benar datang. Saat tidak ada permintaan, tidak ada yang berjalan, dan tidak ada yang ditagih.

Apa Itu Serverless Computing?

Serverless computing adalah model eksekusi cloud yang menjalankan kode Anda tanpa mengharuskan Anda menyediakan, mengonfigurasi, atau merawat mesin tempat kode itu berjalan. Penyedia layanan yang memutuskan berapa banyak kapasitas dinyalakan, kapan dinyalakan, dan kapan dipadamkan kembali.

Namanya menyesatkan, jadi sebaiknya diluruskan sejak awal: servernya tetap ada. Kode Anda tetap berjalan di atas mesin fisik di suatu data center. Yang hilang adalah pekerjaan mengurus mesin itu — memilih spesifikasi, memasang sistem operasi, memasang patch keamanan, dan menebak berapa kapasitas yang dibutuhkan bulan depan. Semua itu berpindah ke penyedia. Kalau Anda ingin menyegarkan konsep dasarnya, pembahasan server menjelaskan peran yang tetap berjalan di lapisan bawah ini.

AWS merangkum modelnya lewat tiga ciri: penskalaan otomatis, ketersediaan tinggi yang sudah tertanam, dan penagihan yang hanya berjalan saat kode dieksekusi. Ciri ketiga inilah pembeda paling tajamnya. Pada server sewaan, tagihan berjalan selama mesin menyala; pada serverless, selama kode berjalan — diukur dalam milidetik.

Karena unit yang dijalankan biasanya berupa satu fungsi kecil, model ini juga dikenal sebagai Function as a Service (FaaS). Contoh yang paling banyak dipakai adalah AWS Lambda, Azure Functions, Google Cloud Run functions, dan Cloudflare Workers.

Paper Cloud Programming Simplified: A Berkeley View on Serverless Computing (Februari 2019) memakai perbandingan yang cukup tepat. Serverless terhadap cloud kira-kira seperti bahasa pemrograman tingkat tinggi terhadap bahasa rakitan: Anda kehilangan sebagian kendali detail, tetapi menukarnya dengan kecepatan membangun.

Cara Kerja Serverless: Perjalanan Satu Permintaan

Fungsi serverless tidak berjalan menunggu di latar belakang. Ia diam sampai ada pemicu (event yang menyalakan eksekusi). Pemicunya bisa berupa permintaan HTTP yang masuk lewat API gateway atau pesan baru di antrean. Bisa juga berkas yang diunggah, perubahan baris di basis data, atau jadwal berkala seperti cron job.

Begitu pemicu tiba, penyedia menyiapkan execution environment — ruang terisolasi berisi runtime dan kode Anda. AWS membagi hidupnya menjadi tiga fase resmi:

Lima fase fungsi serverless: pemicu tiba, Init, Invoke, dibekukan untuk warm start, lalu Shutdown.

Fase Init dibatasi 10 detik di Lambda. Kalau kode inisialisasi Anda lebih lambat dari itu, AWS mengulang fase tersebut pada pemanggilan pertama. Fase Invoke dibatasi timeout yang Anda tetapkan sendiri, maksimum 15 menit. Fase Shutdown hanya berlangsung 0 sampai 2.000 milidetik, bergantung pada ada tidaknya extension.

Bagian yang paling sering disalahpahami ada di anak panah yang kembali ke fase Invoke. Setelah selesai, environment tidak langsung dipadamkan, melainkan dibekukan. Kalau permintaan berikutnya datang cukup cepat, environment yang sama dicairkan dan dipakai ulang tanpa mengulang fase Init. Inilah yang membedakan warm start dari cold start.

Meski begitu, AWS tetap mematikan execution environment setiap beberapa jam untuk pembaruan runtime dan pemeliharaan, bahkan pada fungsi yang dipanggil terus-menerus. Karena itu kode Anda tidak boleh mengandalkan data yang tersimpan di memori antar-pemanggilan.

FaaS dan BaaS: Dua Bagian yang Sering Disatukan

Istilah serverless sebenarnya menaungi dua komponen berbeda, dan memisahkannya membuat banyak kebingungan hilang.

FaaS adalah bagian yang menjalankan kode tulisan Anda sendiri. Anda mengunggah satu fungsi, menentukan pemicunya, dan penyedia menjalankannya saat dibutuhkan. Lambda, Azure Functions, dan Cloudflare Workers masuk di sini.

BaaS (Backend as a Service) menggantikan komponen backend dengan layanan siap pakai: autentikasi, basis data, penyimpanan berkas, dan notifikasi. Anda tidak menulis kode servernya sama sekali. Firebase adalah contohnya yang paling dikenal, dengan Authentication dan Firestore sebagai andalan.

Keduanya sama-sama serverless karena memenuhi ciri yang sama: tidak ada server yang Anda urus, dan tagihan mengikuti pemakaian. Itu sebabnya daftar layanan yang AWS sebut serverless jauh lebih panjang daripada Lambda saja. Di dalamnya ada Fargate untuk container, API Gateway dan EventBridge untuk integrasi, serta DynamoDB sebagai basis data NoSQL yang menagih per operasi baca-tulis. Aplikasi serverless yang utuh biasanya mencampur keduanya.

Dua komponen serverless: FaaS berisi Lambda, Azure Functions, Workers; BaaS berisi Firebase, Firestore, DynamoDB.

Menempatkan Serverless di Antara IaaS, PaaS, dan SaaS

Pertanyaan "serverless itu masuk kategori apa" muncul terus, dan jawabannya paling jelas kalau dilihat dari siapa yang mengurus lapisan apa.

Dari tabel itu, serverless paling tepat dibaca sebagai turunan PaaS yang unit penagihannya berpindah dari "instance yang menyala" ke "eksekusi yang benar-benar terjadi". Platform PaaS seperti Heroku juga membebaskan Anda dari urusan sistem operasi, tetapi tagihannya tetap berjalan selama aplikasi menyala. Baris terakhir tabel itulah pembeda sesungguhnya.

Tiga hal yang sering ditanyakan dan layak dijawab lugas. Pertama, hypervisor (perangkat lunak yang membagi satu mesin fisik menjadi beberapa mesin virtual) tetap ada di bawah serverless. Lambda bahkan berjalan di atas microVM Firecracker. Yang benar bukan "tidak butuh hypervisor", melainkan "hypervisor bukan lagi urusan Anda".

Kedua, Amazon EC2 dan VPS bukan serverless, karena tagihannya berjalan selama instance menyala walaupun tidak ada permintaan masuk. Ketiga, serverless tidak menggantikan cloud computing; ia salah satu model penyajian di dalamnya.

Batas Teknis Empat Platform Serverless per 2026

Angka-angka berikut menentukan apakah sebuah beban kerja layak dipindahkan ke serverless atau tidak. Semuanya diambil dari dokumentasi resmi masing-masing penyedia per September 2026.

Tiga angka di tabel itu perlu keterangan tambahan. Lambda membagi CPU sebanding dengan memori, dan 1.769 MB adalah titik ketika sebuah fungsi mendapat setara satu vCPU. Payload sinkron Lambda dibatasi 6 MB untuk request maupun response. Fungsi HTTP di Azure tetap terputus pada 230 detik oleh load balancer, berapa pun timeout yang Anda pasang.

Dua catatan penting menyertai tabel itu. Azure Consumption plan yang lama sudah berstatus legacy; Microsoft mengarahkan aplikasi serverless baru ke Flex Consumption, dan Linux Consumption dipensiunkan pada 30 September 2028. Dokumentasi Azure juga menyebut aplikasi runtime v3 di Linux Consumption berhenti berjalan mulai 30 September 2026. Angka batas 5 menit dan memori 1,5 GB yang mungkin Anda temui merujuk plan lama itu, bukan Flex Consumption.

Cloudflare Workers menghitung waktu CPU, bukan waktu dinding. Menunggu balasan dari basis data atau API lain tidak menambah tagihan. Untuk beban kerja yang banyak menunggu jaringan, batas 10 milidetik pada paket gratisnya jauh lebih longgar daripada kelihatannya. Model ini berjalan di jaringan edge yang sama dengan layanan CDN Cloudflare.

Cold Start: Seberapa Sering dan Seberapa Lama

Cold start adalah jeda tambahan saat permintaan datang ke fungsi yang belum punya execution environment siap pakai. Penyedia harus mengunduh kode, menyalakan runtime, lalu menjalankan kode inisialisasi Anda sebelum handler benar-benar dieksekusi.

Dokumentasi AWS memberi dua angka sekaligus:

"Cold starts typically occur in under 1% of invocations. The duration of a cold start varies from under 100 ms to over 1 second." — dokumentasi AWS Lambda, Understanding the Lambda execution environment lifecycle

Jadi persoalannya bukan seberapa sering, melainkan seberapa buruk saat terjadi. Satu detik tambahan tidak terasa pada pemrosesan berkas di latar belakang, tetapi sangat terasa pada halaman checkout. AWS juga mencatat cold start lebih sering muncul di lingkungan pengembangan ketimbang produksi, karena fungsinya lebih jarang dipanggil.

Cold start fungsi serverless melewati unduh kode, runtime, dan inisialisasi; warm start langsung ke handler.

Penyumbang terbesarnya adalah kode inisialisasi di luar handler: impor pustaka, pembacaan konfigurasi, dan pembukaan koneksi. Ada tiga cara umum menekannya:

1. Provisioned concurrency: Anda membayar sejumlah execution environment agar selalu dalam kondisi siap. Ini cara paling pasti, sekaligus paling mahal, karena Anda kembali membayar kapasitas menganggur.
2. Lambda SnapStart: AWS mengambil snapshot memori dan disk dari environment yang sudah selesai diinisialisasi, lalu memulihkannya saat dibutuhkan. Klaim resminya "as low as sub-second startup performance". Perlu diperhatikan, SnapStart hanya mendukung Java 11 ke atas, Python 3.12 ke atas, dan .NET 8 ke atas — Node.js dan Ruby tidak termasuk.
3. Instance yang selalu siap: Azure menyediakan always ready instances di Flex Consumption dengan tujuan yang sama.

Pendekatan Cloudflare berbeda secara mendasar. Workers tidak menyalakan container atau mesin virtual per fungsi, melainkan isolate V8 di dalam runtime yang sudah berjalan. Dokumentasinya menyebut isolate menyala kira-kira seratus kali lebih cepat daripada proses Node.js di atas container atau mesin virtual, dengan pemakaian memori satu tingkat lebih kecil. Konsekuensinya, cold start hampir tidak terasa, tetapi Anda terikat pada lingkungan JavaScript dan WebAssembly dengan memori 128 MB.

Keuntungan Serverless Computing

Kenapa memakai serverless kalau server biasa sudah bekerja? Jawabannya ada pada beberapa keuntungan yang terukur:

1. Tidak ada kapasitas menganggur yang dibayar: Tagihan dihitung dari jumlah eksekusi dan durasinya dalam milidetik. Aplikasi yang sepi semalaman benar-benar tidak menghasilkan biaya komputasi.
2. Penskalaan yang tidak perlu Anda rancang: Lambda menambah hingga 1.000 execution environment setiap 10 detik tanpa konfigurasi apa pun. Anda tidak perlu menyiapkan load balancing atau aturan autoscaling untuk lonjakan yang mendadak.
3. Ketersediaan tinggi bawaan: Fungsi dijalankan lintas zona ketersediaan tanpa Anda merancang redundansi sendiri.
4. Permukaan pemeliharaan yang jauh lebih kecil: Tidak ada sistem operasi yang perlu di-patch dan tidak ada web server yang perlu dikonfigurasi. Pemantauan disk penuh pada dini hari juga hilang.
5. Waktu rilis yang lebih pendek: Satu fungsi bisa ditulis, diunggah, dan dijalankan dalam hitungan menit — cocok untuk memvalidasi ide lebih dulu.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Sisi lain modelnya sama nyatanya, dan sebagian baru terasa setelah aplikasi berjalan beberapa bulan.

1. Cold start pada beban rendah: Justru aplikasi yang jarang dipanggil paling sering menemui jeda ini. Fungsi yang dipakai sekali sejam hampir selalu mulai dalam keadaan dingin.
2. Batas keras yang tidak bisa ditawar: Proses yang membutuhkan lebih dari 15 menit tidak bisa dijalankan di Lambda. Fungsi HTTP di Azure tetap terputus pada 230 detik. Payload sinkron Lambda dibatasi 6 MB. Batas seperti ini memaksa perancangan ulang, bukan sekadar penyesuaian konfigurasi.
3. Sifat stateless yang memaksa memindahkan data keluar: Karena environment bisa dipadamkan kapan saja, seluruh state harus disimpan di basis data atau cache eksternal. Sesi pengguna, unggahan sementara, dan hasil perhitungan tidak bisa mengandalkan memori proses.
4. Biaya yang berbalik arah pada beban konstan: Model bayar-per-eksekusi menguntungkan selama trafiknya tidak rata. Pada trafik yang tinggi dan stabil, ia justru lebih mahal daripada menyewa mesin. Angkanya dibahas di bagian berikutnya.
5. Pelacakan masalah yang lebih rumit: Satu permintaan bisa melewati beberapa fungsi terpisah. Menelusuri kesalahan menuntut distributed tracing, bukan sekadar membaca satu berkas log.
6. Ketergantungan pada penyedia: Format event, cara pemicu didefinisikan, dan integrasi ke layanan lain bersifat spesifik per platform. Memindahkan aplikasi serverless antar-penyedia menuntut penulisan ulang lapisan integrasi, kondisi yang umum disebut vendor lock-in.

Sebagian batas itu mulai bergeser. AWS kini menyediakan durable functions, varian Lambda yang memakai mekanisme checkpoint dan replay sehingga satu alur kerja bisa berjalan sampai satu tahun. Selama fungsi menunggu — misalnya menanti persetujuan manusia atau balasan sistem lain — eksekusinya ditangguhkan tanpa menagih biaya komputasi. Azure menyediakan padanannya lewat Durable Functions. Meski begitu, batas 15 menit tetap berlaku untuk fungsi Lambda biasa.

Keamanan Serverless: Yang Berpindah dan Yang Tetap Milik Anda

Salah satu daya tarik serverless adalah berkurangnya pekerjaan keamanan. Berkurang, bukan hilang — dan garis pembatasnya perlu jelas.

Yang berpindah ke penyedia adalah seluruh lapisan di bawah kode Anda. AWS menambal runtime beserta pembaruan keamanannya secara otomatis, dan mematikan execution environment setiap beberapa jam agar versi terbaru terpasang. Patch sistem operasi, versi web server, dan pengerasan mesin tidak lagi masuk daftar pekerjaan Anda.

Tiga hal tetap menjadi tanggung jawab Anda. Pertama, dependency di dalam paket deployment. Pustaka yang Anda ikutkan bisa mencapai 250 MB dalam keadaan terbuka di Lambda, dan celah di dalamnya tetap celah Anda. Kedua, izin akses: satu fungsi yang diberi hak terlalu luas berubah menjadi pintu masuk ke layanan lain di akun yang sama. Ketiga, rahasia aplikasi. Kunci API dan kredensial basis data lebih aman disimpan di layanan pengelola rahasia. Menempelkannya sebagai environment variable kurang bijak, dan di Lambda ruangnya pun hanya 4 KB untuk semuanya.

Ada satu konsekuensi yang baru terasa setelah aplikasi tumbuh. Memecah aplikasi menjadi puluhan fungsi berarti memperbanyak titik masuk. Satu monolit dengan satu endpoint publik berubah menjadi banyak fungsi dengan pemicunya masing-masing, dan setiap pemicu itu perlu ditinjau sendiri-sendiri.

Menghitung Biaya: Titik Impas Serverless dan VPS

Harga Lambda punya dua komponen, dan keduanya sederhana. Setiap bulan Anda mendapat 1 juta request dan 400.000 GB-detik gratis. Di atas itu, tarifnya $0,20 per 1 juta request ditambah $0,0000166667 per GB-detik. GB-detik dihitung dari durasi eksekusi dikalikan memori yang Anda alokasikan.

Rumusnya bisa ditulis begini, dengan R sebagai jumlah request dan G sebagai total GB-detik:

G     = R × durasi_detik × (memori_MB ÷ 1024)
biaya = maks(0, R − 1.000.000) × $0,20/juta
      + maks(0, G − 400.000)   × $0,0000166667

Dengan asumsi tetap — memori 512 MB dan durasi rata-rata 200 milidetik — berikut hasilnya pada tiga tingkat beban. Konversi memakai kurs referensi Kementerian Keuangan per 2 September 2026, Rp17.722 per dolar AS.

Baris pertama menjelaskan kenapa serverless terasa hampir gratis untuk proyek kecil. Pada 3 juta panggilan sebulan, komputasinya masih tertampung jatah gratis. Yang tersisa hanya biaya request, di bawah harga secangkir kopi.

Baris kedua adalah tempat perhitungannya berbalik. Paket VPS 2 vCPU dengan RAM 4 GB berharga sekitar Rp470.000 per bulan, setara $26,52 pada kurs yang sama. Kalau kita cari titik saat biaya Lambda menyamai angka itu, hasilnya:

Untuk fungsi 512 MB berdurasi 200 milidetik, titik impasnya berada di sekitar 17,9 juta request per bulan — kira-kira 6,9 request per detik tanpa henti.

Di bawah angka itu serverless lebih murah. Di atasnya, VPS Indonesia dengan spesifikasi tersebut lebih hemat. Selisihnya pun melebar cepat: pada 100 juta request per bulan, biaya Lambda sudah hampir tujuh kali lipat harga VPS-nya.

Kurva biaya serverless datar selama jatah gratis, lalu memotong garis VPS Rp470.000 di 17,9 juta request.

Angka 6,9 request per detik itu bukan patokan universal. Fungsi yang lebih kecil menggesernya jauh ke atas. Pada memori 128 MB dan durasi 100 milidetik, jatah gratis komputasinya saja baru habis di 32 juta request. Sebaliknya, fungsi 2 GB yang berjalan dua detik menembus titik impas jauh lebih awal. Karena itu rumus di atas lebih berguna daripada angkanya.

Kapan Serverless Cocok, Kapan Sebaiknya Tidak

Serverless masuk akal ketika trafik Anda tidak rata dan beban puncaknya sulit ditebak. Kandidat terkuatnya adalah pemrosesan berkas yang diunggah pengguna, webhook dari layanan pihak ketiga, dan tugas terjadwal seperti laporan harian. Backend aplikasi di bawah beberapa juta panggilan per bulan juga cocok. Begitu pula penerimaan data dari perangkat IoT yang mengirim sesekali, dan otomatisasi DevOps seperti pemicu setelah build selesai. Pola lain yang sering dipakai adalah menempatkan logika ringan di edge, sementara pemrosesan berat tetap di region terdekat.

Sebaliknya, empat kondisi berikut menandakan model lain lebih tepat. Pertama, proses yang berjalan lebih dari 15 menit, seperti transcoding video panjang atau pelatihan model. Kedua, koneksi persisten seperti WebSocket dan server game, yang bertentangan dengan sifat eksekusi sesaat. Ketiga, trafik tinggi yang konstan di atas titik impas tadi. Keempat, aplikasi yang membutuhkan kendali sistem operasi — pemasangan pustaka sistem tertentu, penyetelan kernel, atau perangkat lunak lama yang menuntut lingkungan spesifik.

Untuk kebutuhan di kelompok kedua, Docker di atas VPS biasanya sudah memadai, sementara Kubernetes baru relevan kalau Anda benar-benar menjalankan banyak layanan lintas banyak mesin.

Serverless Open Source: Menjalankannya di Server Sendiri

Ketergantungan pada satu penyedia bisa dikurangi dengan menjalankan platform serverless sendiri. Pilihannya tidak banyak, dan kondisinya per 2026 sebaiknya diperiksa sebelum Anda menaruh harapan.

Knative adalah yang paling matang. Ia berjalan di atas Kubernetes dan terdiri dari tiga bagian: Serving untuk layanan HTTP yang menskala mengikuti trafik hingga turun ke nol replika saat sepi, Eventing untuk perutean event, dan Functions untuk membangun fungsi. Statusnya di CNCF naik dari Incubating menjadi Graduated pada 11 September 2025, tingkat kematangan yang sama dengan Kubernetes sendiri.

OpenFaaS lebih ringan dan tidak mengharuskan Kubernetes: varian faasd sanggup berjalan di satu mesin virtual. Fungsinya dikemas sebagai container, sehingga bahasa apa pun bisa dipakai. Yang perlu diperhatikan adalah lisensinya. Community Edition ditujukan untuk eksplorasi dan uji coba awal, dengan jendela 60 hari untuk pemakaian komersial. Setelah itu Anda diarahkan ke edisi berbayar.

Apache OpenWhisk masih sering disebut sebagai pilihan ketiga, tetapi kondisinya sudah berubah. Proyek ini memang lulus inkubasi Apache pada Juli 2019. Namun laporan dewan Apache Software Foundation tertanggal 20 Mei 2026 mencatat statusnya Dormant, tanpa aktivitas pengembangan pada kuartal terakhir. Laporan yang sama menyebut kemungkinan pemindahannya ke Apache Attic dalam tahun ini.

Tiga platform serverless open source: Knative sudah CNCF Graduated, OpenFaaS CE dibatasi 60 hari, OpenWhisk dormant.

Satu hal perlu disadari sebelum menempuh jalur ini. Begitu Anda menjalankan platform serverless sendiri, sebagian besar keuntungannya ikut hilang. Server tetap harus disediakan, ditambal, dan dibayar sepanjang bulan — bedanya sekarang Anda juga mengurus platform serverless-nya. Pilihan ini masuk akal kalau kendali penuh atau kewajiban menyimpan data di infrastruktur sendiri lebih berat daripada penghematan operasional.

Serverless dari Region Indonesia

Lima tahun lalu, memakai serverless dari Indonesia berarti menerima latensi tambahan dari Singapura. Sekarang ketiga penyedia besar sudah punya region di Jakarta. Google Cloud membuka asia-southeast2 pada 24 Juni 2020. AWS menyusul dengan ap-southeast-3 pada 14 Desember 2021, Lambda termasuk di dalamnya. Microsoft meresmikan Azure Indonesia Central beserta tiga availability zone-nya pada April 2025.

Dampaknya ada dua. Waktu tempuh jaringan ke pengguna Indonesia turun drastis, sehingga jeda cold start tidak lagi bertumpuk di atas latensi lintas negara. Data pemrosesan juga bisa tetap berada di dalam negeri, pertimbangan yang makin sering muncul pada proyek pemerintahan dan layanan keuangan. Meski begitu, tidak semua fitur tersedia serentak di region baru — periksa dulu ketersediaan layanan yang Anda pakai.

Pertanyaan yang Sering Muncul

Apa bedanya cloud computing dan serverless computing?

Cloud computing adalah payung besarnya, yaitu pemakaian sumber daya komputasi lewat internet. Serverless salah satu model penyajian di dalam payung itu. Ciri khasnya dua: tidak ada server yang Anda urus, dan tagihan hanya berjalan saat kode dieksekusi.

Apakah serverless computing termasuk PaaS?

Paling tepat dibaca sebagai turunan PaaS. Keduanya membebaskan Anda dari urusan sistem operasi, tetapi unit penagihannya berbeda: PaaS menagih selama instance menyala, serverless menagih per eksekusi. Di beberapa kurikulum sertifikasi, FaaS bahkan diperlakukan sebagai kategori tersendiri di antara PaaS dan SaaS.

Apakah serverless computing membutuhkan hypervisor?

Isolasi antar-pengguna tetap membutuhkan lapisan virtualisasi, dan AWS Lambda memakai microVM Firecracker untuk itu. Yang benar bukan "tidak memakai hypervisor", melainkan hypervisor itu sepenuhnya dikelola penyedia dan tidak pernah Anda sentuh. Cloudflare Workers memakai pendekatan berbeda dengan isolate V8, bukan mesin virtual per fungsi.

Apakah Amazon EC2 termasuk serverless?

Bukan. EC2 adalah mesin virtual yang tagihannya berjalan selama instance menyala, termasuk saat tidak ada permintaan masuk. Layanan AWS yang tergolong serverless antara lain Lambda, Fargate, API Gateway, EventBridge, Step Functions, dan DynamoDB.

Apa contoh nyata serverless computing sehari-hari?

Pembuatan thumbnail otomatis setiap kali foto diunggah, pengiriman email konfirmasi setelah pembayaran berhasil, dan chatbot yang menjawab pesan masuk. Contoh lain: laporan penjualan yang dirakit tiap tengah malam, serta validasi formulir tanpa backend yang menyala terus-menerus.

Apa bedanya serverless dengan microservices?

Keduanya menjawab pertanyaan yang berbeda. Microservices adalah gaya arsitektur — aplikasi dipecah menjadi beberapa layanan kecil yang berdiri sendiri. Serverless adalah model menjalankan dan menagih kode. Sebuah microservice bisa dijalankan di container maupun sebagai fungsi serverless, dan keduanya kerap dipakai bersamaan.

Bahasa pemrograman apa saja yang bisa dipakai?

Lambda mendukung Node.js, Python, Java, Go, Ruby, dan .NET secara resmi, ditambah runtime khusus untuk bahasa lain. Cloudflare Workers berjalan di atas JavaScript dan WebAssembly. Cloud Run menerima container apa pun, sehingga praktis bebas bahasa.

Kesimpulan

Serverless computing adalah model menjalankan kode tanpa mengurus server, dengan tagihan per eksekusi alih-alih per jam menyala. Kekuatannya paling terasa pada trafik yang tidak rata, tugas terjadwal, dan pemrosesan berbasis event. Di sana Anda berhenti membayar kapasitas menganggur sekaligus berhenti mengurus sistem operasi.

Batasnya juga perlu diketahui sejak awal. Ada cold start dari bawah 100 milidetik sampai lebih dari satu detik, batas eksekusi 15 menit, dan keharusan menyimpan state di luar fungsi.

Biayanya pun berbalik lebih mahal begitu trafik menjadi konstan. Pada fungsi 512 MB berdurasi 200 milidetik, pembalikan itu terjadi di sekitar 17,9 juta request per bulan. Hitung ulang angka tersebut dengan durasi dan memori fungsi Anda sendiri sebelum memutuskan. Semoga artikel ini membantu.