Pros & Cons Serverless #

Serverless bukan lagi sekadar tren teknologi baru atau kata kunci (buzzword) yang ramai dibicarakan di kalangan komunitas IT. Dalam beberapa tahun terakhir, serverless telah bertransformasi menjadi pendekatan arsitektur utama yang diadopsi secara luas oleh berbagai level perusahaan, mulai dari startup tahap awal (early-stage) yang ingin memvalidasi ide bisnis dengan cepat hingga perusahaan skala enterprise yang melayani jutaan pengguna aktif setiap harinya.

Namun, di dalam dunia rekayasa perangkat lunak, tidak ada keputusan arsitektur yang gratis. Setiap kali kita memilih sebuah teknologi, kita sebenarnya sedang menyetujui serangkaian keuntungan sekaligus menerima serangkaian keterbatasan atau kelemahan yang dibawanya. Hal ini juga berlaku mutlak pada teknologi serverless. Untuk mengambil keputusan arsitektural yang matang dan bijaksana, kita harus membedah secara rasional kelebihan (pros) dan kekurangan (cons) serverless berdasarkan realita di lapangan, bukan sekadar janji-janji teoretis di brosur penyedia cloud.

Kelebihan Utama (Pros) #

Ada beberapa alasan kuat mengapa banyak tim engineering memutuskan untuk bermigrasi dari mesin virtual tradisional atau kluster container (seperti Kubernetes) menuju arsitektur serverless. Berikut adalah keuntungan utama yang ditawarkan oleh serverless:

1. Eliminasi Total Manajemen Infrastruktur (No Infrastructure Ops) #

Keuntungan paling nyata dari serverless adalah hilangnya beban pengelolaan server dari pundak tim pengembang. Kita tidak perlu lagi memikirkan bagaimana cara mengonfigurasi web server (seperti Nginx atau Apache), melacak kapasitas penyimpanan disk, melakukan pembaruan sistem operasi (OS patching), atau memantau apakah server fisik mati di tengah malam.

Bagi organisasi, ini berarti kita dapat memusatkan energi dan waktu kerja para insinyur perangkat lunak kita sepenuhnya untuk menulis kode yang menghasilkan nilai bisnis langsung (logika aplikasi dan fitur produk). Kita tidak perlu merekrut tim administrator sistem (sysadmin) yang besar hanya untuk menjaga agar server tetap menyala.

2. Skalabilitas Otomatis yang Instan (Instant Auto-Scaling) #

Aplikasi serverless dirancang untuk menangani perubahan beban kerja secara otomatis dan instan dari nol hingga ribuan request secara bersamaan tanpa intervensi manual.

Pada arsitektur tradisional, auto-scaling membutuhkan konfigurasi yang rumit: kita harus mendefinisikan batas CPU/RAM, mengatur durasi cooldown, dan menunggu beberapa menit sampai instans VM baru berhasil melakukan booting. Di serverless, platform cloud akan memunculkan container/runtime baru dalam hitungan milidetik saat ada request masuk secara tiba-tiba. Ketika traffic kembali sepi, platform akan menghancurkan kontainer tersebut hingga tersisa nol instans aktif (scale to zero).

3. Efisiensi Finansial yang Tinggi (Pay-per-Execution) #

Serverless menghapus model biaya sewa server statis. Kita hanya ditagih ketika kode kita benar-benar dipanggil dan dieksekusi.

Model billing ini dihitung dengan sangat presisi berdasarkan:

• Jumlah Invokasi: Berapa kali fungsi kita dipicu (misalnya per 1 juta request).
• Durasi Eksekusi: Berapa milidetik waktu yang dibutuhkan fungsi untuk memproses request, dikalikan dengan jumlah memori (RAM) yang dialokasikan untuk fungsi tersebut.

Jika aplikasi kita tidak menerima request sama sekali (misalnya lingkungan staging saat libur akhir pekan), biaya komputasi kita adalah nol rupiah. Hal ini sangat menguntungkan untuk menghemat anggaran infrastruktur startup.

4. Akselerasi Kecepatan Peluncuran (Time-to-Market) #

Karena tidak perlu mengonfigurasi load balancer, mengelola virtual private cloud (VPC) tingkat rendah, atau menulis skrip setup server yang panjang, siklus deployment menjadi jauh lebih sederhana. Developer hanya perlu menulis kode, menjalankan perintah deployment singkat (atau memicu pipeline CI/CD via Git commit), dan aplikasi langsung dapat diakses secara publik. Kecepatan iterasi ini sangat krusial untuk melakukan validasi ide produk di pasar secepat mungkin.

5. Keandalan Tinggi Bawaan (High Availability by Default) #

Penyedia cloud secara default menjalankan fungsi serverless di atas beberapa pusat data fisik yang berbeda (Availability Zones) dalam suatu region. Jika salah satu pusat data mengalami kegagalan listrik atau koneksi internet terputus, traffic akan dialihkan ke pusat data lain secara otomatis tanpa memicu downtime pada aplikasi kita. Kita mendapatkan redundansi tingkat enterprise ini secara gratis tanpa perlu menyewa insinyur SRE khusus untuk merancang kluster failover yang rumit.

Kekurangan dan Batasan (Cons) #

Meskipun kelebihan serverless terlihat sangat menjanjikan, ia membawa konsekuensi teknis dan operasional yang tidak boleh diabaikan. Berikut adalah keterbatasan utama serverless yang sering kali menjadi kendala di dunia nyata:

1. Masalah Latensi Awal (Cold Start) #

Cold start terjadi ketika sebuah request masuk ke fungsi serverless yang sedang dalam keadaan tidak aktif (idle). Cloud provider harus menyalakan lingkungan runtime baru terlebih dahulu sebelum dapat mengeksekusi kode. Proses booting instans baru ini menambahkan latensi (keterlambatan) respon berkisar antara ratusan milidetik hingga beberapa detik.

Cold start sangat dipengaruhi oleh:

• Ukuran Bundel Kode: Semakin besar ukuran ZIP fungsi kita, semakin lama waktu unduh dan inisialisasinya.
• Bahasa Pemrograman: Java dan .NET memiliki waktu cold start yang jauh lebih lama dibandingkan Node.js, Python, atau Go.
• Koneksi Jaringan: Menghubungkan fungsi ke private VPC dapat menambah latensi cold start jika tidak dikonfigurasi dengan benar.

Hal ini membuat serverless kurang cocok untuk aplikasi yang membutuhkan latensi di bawah 50 milidetik secara konsisten 100% sepanjang waktu (misalnya aplikasi game real-time atau core banking API).

2. Ketergantungan Kuat pada Provider (Vendor Lock-in) #

Setiap penyedia layanan cloud memiliki cara unik dalam mengimplementasikan serverless: mulai dari format parameter event pemicu, sistem otentikasi (IAM), hingga perkakas deployment (CLI).

Jika kita menulis kode aplikasi yang sangat terikat dengan SDK atau layanan pemicu salah satu provider (misal: trigger AWS S3), memindahkan kode tersebut ke provider lain (seperti Google Cloud Storage) akan membutuhkan usaha penulisan ulang (refactoring) yang sangat besar dan mahal.

3. Kompleksitas Debugging dan Observability #

Ketika sebuah aplikasi monolitik tradisional dipecah menjadi puluhan fungsi serverless yang saling memicu secara asinkron lewat antrean pesan (Message Queues) dan event, melacak aliran data dan letak bug menjadi sangat sulit.

Kita tidak bisa menggunakan breakpoint debugger standar IDE lokal kita dengan mudah karena lingkungan eksekusinya tersebar di cloud. Kita terpaksa bergantung penuh pada sistem logging terdistribusi, distributed tracing (seperti AWS X-Ray atau Jaeger), dan manajemen korelasi ID yang kompleks untuk mencari penyebab kegagalan sistem.

4. Biaya Tidak Terduga pada Skala Besar (Scaling Costs) #

Meskipun model pay-per-use sangat murah saat traffic rendah, pola biaya ini memiliki titik impas (break-even point). Pada aplikasi yang melayani traffic sangat tinggi secara konstan dan stabil selama 24 jam sehari, biaya retail milidetik serverless akan menumpuk dan menjadi jauh lebih mahal dibandingkan dengan menyewa VM flat-rate bulanan atau menjalankan kluster kontainer yang dimaksimalkan utilisasinya.

5. Batasan Fisik Eksekusi (Runtime Limits) #

FaaS memaksakan batasan fisik yang ketat demi menjaga performa multi-tenant di pusat data mereka:

• Timeout Limit: AWS Lambda membatasi waktu eksekusi maksimal 15 menit per request.
• Memory & Storage Limit: Ada batas maksimal memori (biasanya 10 GB) dan ruang penyimpanan lokal sementara (ephemeral storage /tmp) yang bisa dialokasikan.

Hal ini membuat FaaS tidak dapat digunakan untuk komputasi berat yang memakan waktu lama, seperti pemrosesan video berdurasi panjang, pelatihan model machine learning (training AI), atau WebSocket dengan koneksi aktif berjam-jam.

Analisis Trade-Off Serverless #

Untuk membantu pemahaman visual, diagram alur di bawah ini menggambarkan bagaimana keuntungan dan keterbatasan serverless saling bertolak belakang dalam proses pengambilan keputusan desain sistem.

flowchart TD
    Start["Analisis Trade-Off Serverless"] --> Ops["Beban Operasional"]
    Ops --> OpsPro["PRO: Tanpa manajemen server & OS patching"]
    Ops --> OpsCon["CON: Kehilangan kontrol sistem operasi tingkat rendah"]

    Start --> Cost["Efisiensi Biaya"]
    Cost --> CostPro["PRO: Biaya nol saat idle, bayar per invokasi"]
    Cost --> CostCon["CON: Sangat mahal untuk traffic konstan tinggi 24/7"]

    Start --> Scale["Skalabilitas"]
    Scale --> ScalePro["PRO: Auto-scaling instan dari nol ke ribuan request"]
    Scale --> ScaleCon["CON: Batasan execution timeout maksimal 15 menit"]

    Start --> Performance["Performa & Latensi"]
    Performance --> PerfPro["PRO: Desain decoupled asinkron yang tangguh"]
    Performance --> PerfCon["CON: Risiko cold start pada pemanggilan awal"]

Matriks Perbandingan Pro vs. Kontra #

Tabel berikut menyajikan ringkasan komparatif dampak keputusan arsitektural saat memilih serverless:

Ringkasan #

• Keputusan menggunakan serverless harus didasarkan pada analisis trade-off yang jujur antara beban operasional, efisiensi biaya, pola traffic, dan batasan teknis aplikasi.
• Kelebihan utama serverless meliputi hilangnya tanggung jawab pemeliharaan server, auto-scaling instan tanpa intervensi manual, model billing pay-per-use, dan keandalan tinggi multi-AZ bawaan.
• Kekurangan kritis serverless yang harus diantisipasi adalah latensi inisialisasi awal (cold start), potensi vendor lock-in, kompleksitas debugging sistem terdistribusi, batasan timeout eksekusi, dan biaya kumulatif yang mahal pada traffic konstan tinggi.
• Evaluasi arsitektur secara periodik untuk memastikan apakah serverless masih memberikan nilai ekonomis dan efisiensi operasional bagi tim seiring bertumbuhnya skala bisnis perusahaan.

← Sebelumnya: Layanan Serverless   Berikutnya: AWS Lambda →