Brief by evilfactorylabs

Brief by evilfactorylabs • Untuk obrolan makan siangmu seputar dunia pemrograman. Terbit sebelum jam 13.37 WIB setiap hari Senin & Selasa.

Serverless

Apa, mengapa, bagaimana, λ itu dia

2019 sedang hangat-hangatnya membahas tentang Serverless. Berdasarkan data yang diambil dari Google Trends tentang kata kunci "serverless", penghujung tahun 2019 adalah puncak dari kepopulerannya.

Kata kunci Serverless memiliki nilai 95 pada rentang tanggal 15-21 Desember 2019, tingkat kepopuleran memiliki rentang nilai 0 - 100 yang mana semakin besar nilai berarti sangat populer.

Sebelum kita membahas lebih dalam tentang Serverless ini, mari kita lihat sedikit "sejarah" tentang bagaimana kita melakukan deployment terhadap aplikasi kita:

  1. Bare Metal
  2. Virtual Machine (Cloud)
  3. Container

Dimulai dari menggunakan Bare Metal, yang mana aplikasi di "deploy" ke server fisik. Alias, benar-benar langsung di server beneran. Tanpa virtualisasi dibawahnya.

Menggunakan server Bare Metal memiliki biaya yang relatif mahal baik dari sisi sumber daya ataupun pemeliharaan. Semua biaya seperti listrik, bandwidth, perangkat keras menjadi urusan langsung yang harus dihadapi.

Belum ditambah biaya pemeliharaan.

Lalu dilanjutkan ke menggunakan VM—atau Cloud™—alias kita menggunakan server orang lain. Yang mana, server tersebut bukanlah server fisik, melainkan sebuah server yang berada di server.

Virtual Machine.

Menggunakan VM tentu menyelesaikan masalah biaya & pemeliharaan diatas, namun setiap pilihan pasti memiliki drawbacks nya. Salah satunya di performa.

Yang paling jelas adalah noisy neighbor effect, mengingat server/mesin yang kita gunakan pada dasarnya adalah mesin "virtual" yang mana berjalan dengan server-server lain yang meskipun berada di server fisik.

Efeknya, proses disk I/O; Penggunaan bandwidth, dan penggunaan CPU mempengaruhi "mesin" lain yang sama-sama berada di mesin fisik yang sama.

Dilanjutkan dengan penggunaan Container. Seperti sebutannya, Container bertugas untuk "membungkus" aplikasi kita ke OS secara langsung. Container yang terkenal adalah Docker, LXC (Linux), dan jails (FreeBSD).

Menjalankan aplikasi kita di container membuat lingkungan menjadi lebih lightweight namun "serupa" dengan lingkungan production. Yang maksudnya, hal-hal yang dibutuhkan oleh aplikasi (sistem operasi, dependensi level sistem operasi ataupun aplikasi, dll) dibungkus menjadi sebuah image dan dijalankan diatas proses yang ter-isolasi.

Yang singkatnya, container salah satunya menyelesaikan masalah "monopoli" penggunaan sumber daya yang dilakukan oleh proses lain diluar aplikasi yang dimaksud namun berdampak ke aplikasi tersebut.

Tentang VM as a service

Meskipun biaya terkait menggunakan bare metal bisa sedikit dipangkas dengan menggunakan layanan colocation, dan karena sekarang 2020, mari kita lupakan sejenak tentang bare metal.

Untuk bisa provision virtual machine, kita harus membayar beberapa rupiah/dollar tergantung dengan "spesifikasi" yang kita inginkan ke penyedia. Yang terkenal ada DigitalOcean, Linode, CloudKilat, dsb.

Biasanya, dengan $5/bulan (atau 90rb/bulan untuk layanan di Indonesia) kita sudah mendapatkan "mesin" dengan 1 Core CPU, RAM 1GB, disk space sekitar 20GB (dan menggunakan SSD!), 1 alamat IP public, dan dengan bandwidth yang bermacam-macam.

Yang tentunya sangat terjangkau. Kita tidak perlu berurusan dengan hardware fail salah satunya, karena itu tanggung jawab penyedia layanan dan sudah menjadi hak kita untuk mendapatkan jaminan sehingga kita bisa fokus ke aplikasi yang kita buat.

Harga untuk "menyewa server" tersebut biasanya dihitung per-jam yang bila diakumulasikan per-bulan akan menjadi harga akhirnya ($5/bulan = $.0075/jam).

Biaya itu sudah absolut (jika tidak over quota) yang maksudnya bila kamu memiliki 4 server (for HA sake) sedangkan 2 server tersebut "tidak berguna digunakan", kamu tetap harus membayarnya.

Dan meskipun kamu mematikan server tersebut pun, kamu tetap harus membayar sebagaimana server tersebut menyala. Karena disk space, alamat IP, alokasi RAM & CPU sudah "diberikan" kepada VM kamu. Cara satu-satunya agar tidak ingin membayar adalah menghapus VM kamu itu sendiri, bukan mematikannya.

Tentang Platform as a Service (PaaS)

Jika menggunakan VM kita harus berurusan dengan hal-hal yang berkaitan dengan server, alternatif lain untuk melakukan "deployment" terhadap aplikasi kamu adalah menggunakan PaaS.

Juga, ingat dengan kondisi "server yang tidak dipakai" yang untuk alasan High Availability (dan pastinya untuk Scalability)? Ya, menggunakan PaaS menyelesaikan masalah tersebut.

Yang biasanya, menawarkan Pay (more) as you use, scale as you need. Alias, PaaS menawarkan auto-scaling sehingga kita bisa hanya membayar yang harus dibayar saja (dan pastinya biaya sewa per-bulan juga).

PaaS seperti VM, kita harus membayar per-jam nya. Namun banyak hal-hal yang di abstraction, seperti, bila kita harus setting proccess manager, web server/reverse proxy dsb di VM, di PaaS itu sudah kerjaan mereka.

Dan ya, pasti ada kekurangannya. Seperti, tidak memiliki kontrol penuh terhadap "mesin" yang aplikasi kita gunakan. Juga, spesifikasi & harga yang ada relatif mahal bila dibandingkan dengan konfigurasi sendiri.

Tentang Serverless (FaaS)

Apakah ada harapan untuk "Pay as you use, scale as you need"?

Inilah mengapa kita membahas tentang Serverless.

Serverless hampir sama seperti PaaS, kita tidak perlu berurusan dengan hal-hal berkaitan dengan hardware.

Oke, di PaaS masih berurusan dengan hardware. Singkatnya, bila ingin menggunakan hardware yang lebih besar (CPU, Disk, dll), berarti harus bayar lebih banyak.

Di Serverless, tidak. Kita tidak perlu membayar hardware yang digunakan, "mesin tambahan" untuk alasan scaling, dsb karena yang kita bayar hanyalah penggunaannya saja. Entah dihitung dari jumlah request yang diproses ataupun dari lama proses dieksekusi tergantung layanan yang digunakan.

Mungkin sudah cukup spoiler tentang Serverless, sekarang mari kita bahas tentang Apa, Mengapa, Bagaimana, dan Kapan menggunakan Serverless.

Apa itu Serverless?

Serverless atau Serverless computing adalah sebuah model dalam proses eksekusi di komputasi cloud. Singkatnya, bila menggunakan VM/PaaS kita membutuhkan "instance" untuk melakukan proses yang aplikasi kita lakukan, di Serverless ini tidak ada instance.

Melainkan disebut function.

Begini, jika kita menggunakan Container, 1 aplikasi = 1 container. Benar ya? Berarti, bila kita memiliki 10 aplikasi = 10 container yang berjalan. Alias, menyebabkan banyak proses yang berlangsung.

Alias lagi, "server" kebanjiran proses. Yang kemungkinan dapat menyebabkan down, crash, dsb.

Di Serverless, tidak ada istilah aplikasi ataupun instance. Melainkan function.

Jika kamu memiliki aplikasi yang berguna untuk mengirim email, ya, itu bisa dibuat menjadi function.

Bedanya, "aplikasi" mu tidak berjalan bila tidak di eksekusi.

Mengapa bisa begitu? Runtime.

Runtime dari container (bila menggunakan Docker) adalah Docker itu sendiri. Jika instance di aplikasi kita menggunakan Alpine Linux, dan bila kita "mematikan" instance kita untuk alasan efisiensi sumber daya, untuk "menyalakannya kembali" ketika instance kita dibutuhkan hampir sama ongkosnya dengan menyalakan kembali sebuah mesin yang memiliki sistem operasi.

Belum ditambah waktu dan sumber daya untuk "process manager" yang menjalankan aplikasimu tersebut.

Kembali ke Serverless, Runtime dari Serverless adalah... Tergantung. Jika kamu menggunakan layanan dari AWS, maka runtime tersebut adalah AWS Lambda, bila Google berarti (Google) Cloud Function dsb.

Ketika kita membuat sebuah function di program kita, function tersebut tidak akan tereksekusi bila tidak dipanggil, benar? Begitupula dengan function di Serverless!

Apakah Serverless berarti tidak ada server? Sama seperti teknologi Wireless, bukan berarti tidak ada kabel. Melainkan, kita tidak berurusan dengan hal-hal terkait kabel. Begitupula dengan Serverless, kita tidak berurusan dengan hal-hal terkait server.

Mengapa Serverless?

Di level rancangan arsitektur aplikasi, mungkin sebagian sudah menggunakan arsitektur Microservices. Yang singkatnya, sebuah layanan/aplikasi dipecah menjadi lebih kecil demi alasan efektivitas dari segi operasi dan efisiensi dari segi pemeliharaan.

Dan rata-rata kita menggunakan cloud, ada yang masih menggunakan bare metal disini?

Kebanyakan (atau sudah pasti?) yang menggunakan arsitektur Microservices pasti men-deploy—what is Bahasa equivalent for that word?—aplikasinya dalam bentuk container.

Dan masih ingatkah dengan yang sudah kita bahas sebelumnya tentang matematika sederhana seputar jumlah container & proses?

Dengan mengubah "(micro)services" tersebut menjadi function, kita bisa mengurangi beberapa beban seputar proses yang diemban oleh server. Dan ya, menambah availability juga, pastinya.

Toh sama-sama berada di cloud juga, toh? Yang pastinya ada drawbacks & pertimbangan yang akan kita bahas nanti.

Fitur inti yang ditawarkan oleh Serverless antaralain elastisitas (daripada skalabilitas), fast cold start, minimum footprint, affordable price, dan terakhir: No servers to maintain.

Sehingga kita bisa (lebih) fokus ke bisnis™.

Bagaimana menggunakan Serverless?

Sama seperti mental model (dan prinsip) ketika kita membuat function di kode: Do one thing (yes, and do it well).

Jika di dunia container "entrypoint" nya adalah perintah untuk menjalankan aplikasi tersebut, di function entrypoint nya adalah fungsi dari "apa yang dilakukan" oleh fungsi tersebut.

Anggaplah seperti fungsi main di beberapa bahasa program yang mana secara otomatis akan dipanggil ketika program dieksekusi.

Jika kita membuat "services" bernama svc-mailer yang tugasnya untuk memproses email, kita bisa membuat function mungkin bernama mailer yang tugasnya... Ya itu.

Salah satu pembedanya adalah "layanan" tidak berjalan di server (yang bisa dikontrol "lumayan" sepenuhnya) oleh kita. Melainkan di platform yang menyediakan layanan Serverless tersebut.

Meskipun kita bisa menjalakan "infrastruktur serverless" di server kita (salah satunya via OpenFaaS which is open source & cloud native compliant) but seriously?

Juga, kita harus menyesuaikan dengan lingkungan/runtime Serverless itu sendiri. Seperti, ketika layanan kita melakukan koneksi ke database. Database tersebut harus "sesuai" dengan lingkungan Serverless, yang mana salah satunya harus bisa berurusan dengan koneksi (the database pooling things).

Kamu bisa mencoba menggunakan layanan yang menyediakan FaaS di vendor berikut:

Kapan menggunakan Serverless?

Hmmm ketika butuh?

Begini.

Punya layanan yang tugasnya cuma buat ngirim email? Pasti kamu menggunakan layanan pihak ketiga untuk mengirim email juga, kan? Layanan "pengirim email" mu hanya berguna untuk "menyuruh" layanan pihak ketiga mengirim email, berdasarkan payload yang dimaksud. Bener?

Tapi, aplikasimu tersebut membutuhkan instance. Ada proses yang berjalan entah itu instance server yang dibuat menggunakan Node.js, Go, atau bahkan Java.

Yang artinya, memakan proses. Dan ya, sudah kita bahas sebelumnya.

Atau, untuk layanan lain seperti... Keperluan ChatOps? Mengirim kode OTP? Menyimpan input form? In house CI/CD? Atau bahkan hanya untuk men-deploy situs statis?

Perlu diingat bahwa penyedia layanan Serverless mengambil biaya dari lamanya suatu program dieksekusi ($0.0000x/jam) ataupun seberapa banyak program (pada dasarnya adalah route endpoint) di akses/eksekusi ($0.00000x/1k eksekusi) tergantung ketentuan mereka, jadi, buat pilihan sebijak mungkin.

Penutup

Belum menemukan perusahaan yang ada di Indonesia yang menggunakan teknologi Serverless/FaaS untuk mentenagai aplikasinya di production. Teknologi ini sangat menjanjikan untuk beberapa kebutuhan tertentu.

Kekurangan dari Serverless ini antara lain:

  • Vendor lock-in possibilities
  • Execution timeout
  • Harder to test & debug
  • Security

Juga, berinteraksi dengan database lumayan menantang. Namun tidak dimasukkan ke poin diatas karena pemilihan database tidak berhubungan dengan arsitektur Serverless secara prinsip.

Teknologi ini masih relatif baru, namun terlihat menjanjikan!

Catatan: Serverless disini tidak ada hubungannya dengan Serverless, Inc.

Menikmati tulisan ini?

Blog ini tidak menampilkan iklan, yang berarti blog ini didanai oleh pembaca seperti kamu. Gabung bersama Loading... yang telah membantu blog ini agar terus bisa mencakup tulisan yang lebih berkualitas dan bermanfaat!

Pendukung

Dukung Mengapa saya harus mendukung?
You've successfully subscribed to Brief by evilfactorylabs
Great! Next, complete checkout for full access to Brief by evilfactorylabs
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.