Serverless Architecture

Bayangkan kamu sedang membangun sebuah sistem yang harus menangani lonjakan traffic secara tiba-tiba. Di hari biasa, aplikasi kamu hanya dipakai oleh beberapa ratus pengguna. Server berjalan dengan tenang, resource terpakai sedikit. Lalu tiba-tiba sebuah kampanye promosi viral, dan dalam hitungan menit, ribuan pengguna baru datang bersamaan. Server mulai kepanasan, response time membengkak, dan sebagian request mulai gagal.

Tim operasional kamu buru-buru menambah kapasitas server. Tapi provisioning server baru tidak instan. Butuh waktu untuk menyiapkan environment, menginstall dependencies, dan memastikan konfigurasi aman. Sementara itu, pengguna terus datang dan makin banyak yang frustrasi. Setelah promosi selesai, traffic kembali normal. Sekarang kamu punya server tambahan yang menganggur, tapi tagihan cloud tetap berjalan.

Situasi seperti ini akrab bagi banyak tim yang mengelola infrastruktur sendiri. Mereka harus selalu menebak-nebak kapasitas yang dibutuhkan, menyiapkan buffer untuk lonjakan, dan membayar resource idle di waktu sepi. Pola arsitektur serverless hadir untuk memecahkan masalah ini dengan pendekatan yang berbeda.

Masalah yang Diselesaikan

Masalah inti yang dihadapi bukan hanya soal scaling. Lebih dalam dari itu, tim engineering menghabiskan terlalu banyak waktu untuk urusan server. Provisioning, patching, monitoring kesehatan instance, konfigurasi load balancer, dan recovery dari kegagalan hardware. Semua itu adalah pekerjaan yang tidak langsung menghasilkan nilai bisnis.

Belum lagi soal biaya. Model tradisional mengharuskan kamu membayar kapasitas yang tersedia, bukan kapasitas yang benar-benar dipakai. Server harus selalu menyala, siap melayani request kapan pun. Kalau traffic sedang sepi, kamu tetap membayar. Kalau traffic melonjak, kamu harus punya mekanisme scaling otomatis yang rumit.

Serverless menawarkan pendekatan sebaliknya: kamu hanya membayar eksekusi yang benar-benar terjadi. Tidak ada server yang menganggur. Scaling terjadi secara otomatis dari nol hingga ribuan eksekusi per detik. Tim bisa fokus pada kode dan logika bisnis, bukan pada infrastruktur.

Komponen Utama

Arsitektur serverless terdiri dari tiga blok utama yang bekerja bersama.

Event Sources adalah pemicu yang memulai eksekusi fungsi. Sumber event bisa berupa HTTP API yang menerima request dari pengguna, message queue yang mengantrikan pekerjaan, object storage yang memicu proses saat file diupload, atau scheduled timer yang menjalankan fungsi secara periodik. Setiap event source menghasilkan trigger yang akan mengaktifkan fungsi.

Functions & Runtimes adalah inti dari arsitektur ini. Fungsi-fungsi kecil yang menjalankan logika bisnis secara stateless. Setiap fungsi punya satu tanggung jawab spesifik. Ketika event masuk, platform akan menyediakan runtime container secara ephemeral, menjalankan fungsi, lalu menghentikannya. Platform yang mengatur scaling, ketersediaan, dan lifecycle container. Developer hanya perlu menulis kode dan menentukan konfigurasi seperti memory dan timeout.

Backing Services menyediakan state dan koordinasi yang dibutuhkan fungsi. Karena fungsi bersifat stateless, data persisten harus disimpan di luar. Database untuk menyimpan data aplikasi, cache untuk mempercepat akses, object store untuk file dan asset, serta message bus untuk komunikasi asynchronous antar fungsi.

Alur Kerja

Alur kerja serverless dimulai dari event sources yang mengirimkan trigger ke functions. Sebuah HTTP request masuk, platform langsung memicu fungsi yang terdaftar untuk endpoint tersebut. Fungsi berjalan dalam container ephemeral, memproses request, lalu mengembalikan response.

Selama eksekusi, fungsi bisa berkomunikasi dengan backing services. Misalnya membaca data dari database, menyimpan file ke object store, atau mengirim message ke queue untuk diproses fungsi lain. Setelah selesai, container dihentikan dan resource dibebaskan.

Alur ini bersifat dua arah antara functions dan backing services. Fungsi membaca dan menulis data, sementara backing services menyediakan state yang dibutuhkan. Event sources hanya mengirim trigger satu arah ke functions.

Kapan Pola Ini Cocok

Serverless sangat cocok untuk workload yang bersifat event-driven dan memiliki pola traffic yang tidak menentu. Contoh penggunaan yang umum termasuk pemrosesan file setelah upload, seperti transcoding video atau kompresi gambar. Webhook handlers yang menerima callback dari layanan eksternal. API backend untuk aplikasi dengan traffic yang fluktuatif. Serta scheduled tasks seperti agregasi data harian atau pembersihan log.

Pola ini juga ideal untuk tim kecil yang ingin bergerak cepat. Tanpa perlu mengelola server, developer bisa langsung deploy fungsi baru dalam hitungan menit. Proses deployment menjadi lebih sederhana karena tidak perlu mengatur environment atau konfigurasi server.

Trade-off dan Batasan

Serverless bukan solusi untuk semua masalah. Ada beberapa batasan yang perlu dipahami sebelum memutuskan mengadopsinya.

Cold start adalah masalah yang paling sering dibahas. Ketika fungsi tidak dipanggil dalam waktu lama, platform akan menghentikan container-nya. Saat request baru datang, platform perlu menyediakan container baru, yang membutuhkan waktu beberapa ratus milidetik hingga beberapa detik. Untuk aplikasi real-time atau latency-sensitive, cold start bisa menjadi masalah serius.

Batasan execution time juga perlu diperhatikan. Sebagian besar platform membatasi durasi eksekusi maksimal, misalnya 15 menit. Fungsi yang membutuhkan waktu lebih lama harus dipecah menjadi beberapa langkah atau menggunakan pendekatan lain.

Sifat stateless fungsi berarti state management menjadi tanggung jawab developer. Semua data yang perlu dipertahankan antar eksekusi harus disimpan di backing services. Ini menambah kompleksitas dan latency karena setiap eksekusi harus terhubung ke database atau cache.

Dari sisi biaya, serverless bisa menjadi mahal untuk workload dengan traffic tinggi yang stabil. Model pay-per-execution menguntungkan untuk traffic variabel, tetapi untuk beban konstan, server tradisional dengan reserved instance bisa lebih murah.

Implikasi Praktis untuk Tim Engineering

Mengadopsi serverless bukan hanya soal mengganti cara deploy. Ini mengubah cara tim berpikir tentang arsitektur dan operasional.

Pertama, fungsi harus dirancang untuk single-purpose dan stateless. Setiap fungsi melakukan satu hal dan tidak bergantung pada state lokal. Ini mendorong desain yang lebih modular dan mudah diuji.

Kedua, monitoring dan debugging menjadi lebih menantang. Karena fungsi berjalan di container ephemeral, kamu tidak bisa SSH ke server untuk melihat log. Distributed tracing menjadi kebutuhan, bukan pilihan. Tim harus menginvestasikan waktu untuk setup observability yang baik.

Ketiga, keamanan perlu diperhatikan dengan pendekatan least privilege. Setiap fungsi harus memiliki IAM role sendiri dengan akses minimal ke resource yang dibutuhkan. Environment variables yang berisi credential harus dienkripsi. Untuk akses ke resource privat, fungsi perlu dijalankan di dalam VPC.

Keempat, tim harus siap dengan pola baru dalam menangani error. Karena fungsi bisa gagal kapan saja, perlu ada mekanisme retry dan dead letter queue untuk menangani pesan yang gagal diproses.

Kelima, cold start perlu dikelola dengan strategi provisioned concurrency untuk fungsi-fungsi yang membutuhkan latency rendah. Ini berarti membayar sejumlah container yang selalu siap, mirip dengan reserved capacity.

Pada akhirnya, serverless memberikan kebebasan dari urusan server, tetapi menuntut kedisiplinan baru dalam desain, monitoring, dan manajemen biaya. Tim yang siap dengan trade-off ini akan mendapatkan kecepatan pengembangan dan elastisitas yang sulit ditandingi pola tradisional.