Topik hari ini adalah sesuatu yang hampir semua orang pernah dengar, tapi hampir tidak ada yang bisa menjelaskan. Serverless, apa sebenarnya itu? Atau sesuatu yang berjalan di ruang hampa, atau sesuatu yang jauh lebih besar. Mari kita luruskan satu hal. Serverless bukan berarti tanpa server. Itu berarti Anda tidak perlu memikirkannya. Dan perbedaan itu mengubah segalanya tentang cara Anda membangun perangkat lunak. Di akhir episode ini, Anda akan memahami apa itu Azure Function, sebagaimana harganya bekerja, dan kapan Anda harus menggunakannya. Kita akan membedahnya menjadi blok-blok dasar, dimulai dengan mitos terbesar. Apa arti sebenarnya dari serverless? Mari kita sekedar luruskan beberapa mitos. Nama serverless adalah istilah pemasaran terburuk yang pernah dibuat Microsoft. Itu membuat orang berpikir benar-benar tidak ada server yang terlibat. Itu tidak benar. Dan server jumlahnya sangat baik. Anda hanya tidak perlu menyentuhnya semestinya. 20 tahun yang lalu, jika Anda ingin menjalankan sepotong kode di internet, Anda harus melakukan banyak pekerja. Anda harus menyewa mesin virtual, menginstall sistem operasi, mengonfigurasi web server, dan mendeploy aplikasi Anda. Kemudian Anda akan menghabiskan setiap akhir pekan untuk menambah pembaruan keamanan dan memastikan sistem tidak mati pada jam detik. Dan ilah masalah. Anda mau beri server itu terlepas dari apakah kode Anda berjalan atau tidak. Server itu terus menyala, membuang uang saat Anda tidur. Serverless membalikkan seluruh model ini. Anda menulis kode, mengenggahnya, dan platform menangani sisanya. Sistem operasi, tambalan keamanan, benskalaan, dan ketersediaan. Tugas Anda hanyalah menulis logika yang penting. Anggap saja seperti perbedaan antara menjalankan dapur restoran dan menggunakan mesin penjual otomatis. Dapur restoran membutuhkan staff lengkap persediaan konstan dan pemeliharaan. Dapur itu memakan biaya setiap hari, bahkan jika tidak ada pelanggan yang datang. Mesin penjual otomatis, ia hanya duduk di sudut tanpa melakukan apapun sampai seseorang menekan tombol. Kemudian ia hidup, menjalankan tugasnya, dan kembali tidur. Anda hanya membayar listrik saat mesin itu benar-benar pekerja. Begitulah gambaran singkat dengan serverless. Azure Function adalah versi Microsoft untuk ini. Ia menjalankan potongan kode kecil sebagai respons terhadap peristiwa. Kode Anda tidak aktif sampai ada sesuatu yang membangunkannya, lalu ia berjalan, selesai, dan kembali tidur. Jadi seperti apa sebenarnya kode itu? Apa itu Azure Function? Function adalah satu bagian kode yang melakukan satu tugas spesifik. Hanya, bukan aplikasi utuh dengan halaman login, basis data, dan 20 layar. Itu adalah satu tugas yang terfokus. Bayangkan seperti saklar lampu di rumah Anda. Bisa mati atau menyala saat bekerja, lalu mati kembali. Server web tradisional justru sebaliknya, seperti membiarkan semua lampu di rumah menyala 24 jam sehari, 7 hari seminggu, bahkan saat tidak ada orang di rumah. Azure Functions mendukung banyak bahasa pemrograman yang berbeda. Anda bisa menggunakan apapun yang Anda kuasai. JavaScript, Python, C-Sarif Java, PowerShell. Tidak jawaban yang benar-benar di sini. Pilihlah bahasa yang sudah Anda ketahui. Sekarang mari kita luluskan kebingungan yang sering terjadi. Function app tidak sama dengan function. Function app adalah wadahnya. Tayangkan seperti kotak peralatan. Anda membuat satu function app, dan di dalam kotak peralatan itu Anda menambahkan beberapa fungsi. Setiap fungsi adalah alat terpisah yang menjalankan tugasnya sendiri. Anda mungkin memiliki satu fungsi untuk menangani pendaftaran pengguna, fungsi lain untuk memproses gambar yang diunggah, dan fungsi ketiga untuk mengirim laporan malam. Semuanya berada di kotak peralatan yang sama, tetapi bekerja secara hidup. Satu hal lagi tentang fungsi. Saya ada di sini fungsi bersifat setelah. Artinya fungsi tidak mengingat apapun di antara set proses. Jika fungsi Anda memproses file dan selesai, ya sudah selesai. Saat dijalankan lagi, fungsi dimulai dari awal tanpa ingatan tentang proses. Itu terdengar seperti keterbatasan, tetapi sebenarnya itu adalah fitur yang membuatnya begitu hebat. Karena fungsi tidak menyimpan memori atau state, Azure dapat langsung menjalankan 100 salinan fungsi Anda saat lalu lintas melonjak, dan mematikannya secepat itu saat lalu lintas menurut. Begitulah cara Anda mendapatkan skalabilitas tanpa harus membayang server yang menurut. Pertanyaannya adalah, Jika sebuah fungsi hanya diam tidak melakukan apa-apa sampai ada sesuatu yang membangunkannya, apa sebenarnya yang membangunkannya? Disitulah trigger atau pemicu berpengar. Trigger adalah kapan hal itu terjadi. Setiap fungsi harus memiliki tepat satu trigger, dan itu wajib. Trigger adalah peristiwa yang membangunkan fungsi Anda. Tanpanya, kode Anda hanya akan diam tidak melakukan apa-apa. Bayangkan trigger sepira pintu. Fungsi Anda berada dalam rumah sedang menunggu. Ia bisa menunggu selama. Tidak ada yang terjadi sampai seseorang bunyikan bel pintu. Kemudian fungsi tersebut langsung beraksi, membukakan pintu, melakukan tugasnya, dan kembali menunggu. Ada empat trigger yang paling sering ditemui oleh pemula. HTTP trigger adalah titik awal yang paling umum. Seseorang mengunjungi URL atau melakukan panggilan API, dan fungsi Anda langsung aktif. Begitulah cara Anda membangun API ringan tanpa harus menyiapkan server web lengkap. Lalu ada timer trigger yang berjalan sesuai jadwal. Anda mengatur ekspresi Chrome, seperti menjalankan setiap jam atau tengah malam setiap hari, dan fungsi Anda berjalan tepat pada waktu tersebut. Sangat cocok untuk tugas pemeliharaan, dan pekerjaan pembersihan, atau membuat laporan harian. Pemicu blop aktif saat file diunggah ke penyimpanan Azure. Katakanlah seseorang mengunggah PDF ke folder tertentu. Pemicu blop mendeteksi unggahan itu dan menjalankan fungsi Anda secara otomatis. Ini sangat berguna untuk pemrosesan gambar, konversi dokumen, dan validasi file. Dan pemicu antrean aktif saat pesan muncul di antrean. Antrean adalah cara untuk memisahkan berbagai sistem Anda. Satu layanan memasukkan pesan ke antrean, dan fungsi Anda mengambil serta memprosesnya kapanpun siap. Hal itu mencegah satu layanan yang lambat menghambat layanan lainnya. Ini poin kuncinya. Saat pemicu aktif, ia mengirimkan data ke fungsi Anda secara otomatis. Anda tidak permulakan polling atau memeriksa apakah suatu kata-kata. Pemicu memberikan semua yang Anda butuhkan dan fungsi Anda tinggal memprosesnya. Fungsi tanpa pemicu hanyalah kode yang diam dan tidak melakukan apapun. Pemicu lalu memberikan tujuan pada fungsi tersebut. Jadi pemicu memberitahu fungsi Anda kapan harus berjalan. Namun dari mana data itu berasal dan kemana pergi. Disitulah binding berperan. Binding, data masuk, data keluar. Binding adalah cara untuk memberitahu fungsi Anda data apa yang harus dibaca dan kemana harus mengirim hasil tanpa menulis kode tambahan. Itu terdengar rumit, jadi tinggal saya menyerana. Ada dua jenis. Binding input membawa data geram fungsi Anda. Binding output mengirim data keluar. Tanpa binding, Anda harus menulis kode SDK setiap kali ingin berkomunikasi dengan akun penyimpanan basis data atau antrean. Anda harus menangani string koneksi, mengelola percobaan ulang, membuat serialisasi data, dan deserialisasi respons. Itu adalah banyak kode boilerplate hanya untuk membaca satu. Dengan binding, Anda cukup mendeklarasikan apa yang Anda butuh. Anda berkata, saya ingin membaca dari kontainer blob ini. Atau saya ingin menulis keantrean ini. Runtime akan menangani sisanya. Ia membuka koneksi, membaca data, dan meneruskannya ke fungsi Anda sebagai parameter. Saat fungsi Anda selesai, ia mengambil nilai kembalian dan menulisnya ke tempat yang Anda tentukan. Anggap binding seperti pipa. Anda menghubungkan fungsi Anda ke akun penyimpanan basis data atau antrean. Data mengalir pipa-pipa itu secara otomatis. Fungsi Anda tidak perlu tahu cara kerja pipa tersebut. Ia hanya menerima apa yang masuk dan mengirim apa yang perlu keluar. Berikut adalah contohnya. Katakanlah Anda memiliki binding input. Saat fungsi Anda dimulai, ia otomatis membaca file dari penyimpanan blob dan memberikannya kepada Anda sebagai parameter. Anda tidak perlu menulis kode SDK penyimpanan blob. Anda hanya perlu data tersebut dan memprosesnya. Contoh lain, binding output antrean Q. Fungsi Anda memproses suatu, dan pada akhirnya Anda mengembalikan sebuah nilai. Runtime mengambil nilai tersebut, mengubah formatnya, dan memasukkannya ke antrean. Anda tidak perlu menulis kode antrean. Anda cukup mengembalikan sebuah nilai. Binding bersifat opsional. Anda bisa memiliki 0, 1, atau banyak. Beberapa fungsi hanya memerlukan pemicu tanpa binding sama sekali. Fungsi lain mungkin memiliki 3 atau 4 bindingan terhubung kelayanan berbeda. Kombinasi antara pemicu dan binding inilah yang membuat Azure Functions begitu hebat. Anda menulis logika bisnis kode pengambilan keputusan yang sebenarnya platform menangani semua integrasinya. Fungsi Anda tetap kecil, fokus, dan mudah dipahami. Cerita tentang harga. Harga inilah yang paling mengejutkan bagi banyak pemutu. Bagi banyak orang, paket konsumsi adalah pilihan default, dan Anda sebaiknya mulai dengan paket ini 90% dari waktu. Begini cara kerjanya. Anda membayar hanya saat fungsi Anda benar-benar pencarian. Ketika tidak aktif, Anda tidak membayar apapun. No liter special phone. Dua komponen membentuk tagihannya. Pertama, jumlah eksekusi seberapa sering fungsi Anda dijalankan. Kedua, waktu eksekusi yang diukur dalam satuan yang disebut GB detik. Itu pada dasarnya adalah berapa lama fungsi Anda berjalan dikalikan dengan berapa banyak memori yang digunakan. Jata gratisnya sangat besar. Anda mendapatkan 1 juta eksekusi per bulan dan 400 ribu GB detik sepenuhnya gratis. Untuk sebagian besar proyek kecil, aplikasi hobi, dan prototipe, Anda tidak akan pernah membayar special phone. Amin. Jika Anda melebih jatah gratis, tarifnya masih sangat murah. 20 sen berjuta eksekusi. Itu bukan salah satu. 20 sen untuk sejuta kali berjalanan. Anggap saja seperti membayar listrik hanya saat Anda menyalakan saklar. Tidak ada biaya dasar bulanan untuk pemasangan kabel di dinding Anda. Anda hanya membayar daya yang benar-benar Anda gunakan. Ada paket lain juga. Flex Consumption lebih baru dan memberi Anda dukungan jaringan film. Premium menjaga fungsi Anda tetap aktif, jadi tidak ada jaringan awal. Dedicate memberi Anda kapasitas tetap pada paket app service tradisional. Namun untuk memulai consumption adalah pilihan yang tepat hampir setiap saat. Atau peringatan meskipun. Jatah gratis dibagikan ke seluruh aplikasi fungsi Anda dalam langgan yang sama. Jika Anda memiliki 10 aplikasi fungsi, semuanya menggunakan jatah 1 juta eksekusi yang sama. Jadi perhatikan hal itu jika Anda mulai membangun lebih dari beberapa aplikasi. Harganya sangat bagus. Namun mari kita buat ini nyata dengan contoh konkret. Skenario Dunia Nyata Bayangkan Anda mengolah situs web di mana pengguna mengunggah foto profil. Gambar-gambar tersebut berukuran besar sekitar 10 MBP gambar. Dan itu menimbulkan beberapa masalah nyata. File besar lebih mahal untuk disimpan, memperlambat situs web Anda setiap kali seseorang memuat halaman, dan membuat pengguna frustrasi karena harus melunggu foto. Jadi Anda perlu cara untuk mengecilkan gambar tersebut secara otomatis. Tanpa Azure Functions, Anda harus membuat pekerja latar belakang dari awal. Artinya Anda perlu menyiapkan server terpisah, membuat antrean untuk mengatur beban kerja, dan menulis kode untuk menangani semua bagian yang berjalan. Itu adalah kerumitan yang tidak perlu untuk sesuatu yang sederhana seperti mengecilkan gambar. Dengan Azure Functions, Anda hanya butuh satu pemicu blob dan satu fungsi. Tidak perlu pusing memikirkan server. Ijinkan saya menjelaskan cara kerjaannya. Seorang pengguna mengunggah foto melalui situs web Anda, dan file tersebut masuk ke penyimpanan blob Azure. Saat file tiba, pemicu blob akan aktif secara otomatis. Fungsi Anda aktif, menjalankan kode kompresi, dan menyimpan versi yang lebih kecil kembali ke penyimpanan. Semua ini terjadi dalam hitungan detik. Pengguna tidak perlu menunggu karena seluruh proses berjalan di latar belakang sepenuhnya tidak terlihat. Contoh sehari-hari lainnya, mengirim email selamat datang saat seseorang mendaftar kelayanan Anda. Pemicu HTTP menangkap pendaftaran dari situs web Anda. Fungsi Anda aktif, mengambil alamat email pengguna, mengirim pesan selamat datang melalui SendGrid, lalu selesai, pengguna menerima email mereka berseketikan. Tidak perlu menyiapkan server email, tidak perlu mengelola antara yang kirim. Hanya satu fungsi, satu tugas. Selesai. Inilah pekerjaan yang dirancang khusus untuk Azure Function. Tugas kecil, terfokus, dan berbasis peristiwa. Bukan aplikasi besar, bukan alur kerja yang kompleks, hanya satu hal yang dilakukan dengan baik, dipicu oleh sesuatu yang terjadi di tempat lain. Kapan menggunakan Azure Functions? Jadi kapan Anda harus menggunakan fungsi, dan kapan harus menggunakan hal lain? Berikut adalah cepat untuk mentuskan. Tanyakan pada diri sendiri apakah tugas tersebut singkat, berbasis peristiwa, dan tidak memiliki status status. Jika Anda menjawab, ya untuk ketiganya, Azure Functions mungkin adalah alat yang tepat. Mari kita mulai yang baik. API dan webhook adalah pasangan yang sempurna. Anda memerlukan titik akhiringan yang merespons permintaan HTTPE melakukan satu hal dan mengembalikan hasil, dan itulah tujuan dibuatnya pemicu HTTPE. Pempresesan file dan gambar adalah contoh besar. File masuk ke penyimpanan, fungsi Anda aktif, mengubahnya, dan menyimpan hasilnya, semua tanpa server. Tugas terjadwal seperti pembersihan malam atau pembuatan laporan sangat cocok dengan pemicu pengatur waktu. Transformasi data untuk pipeline ETL juga sering dilakukan. Dan fungsi menjadi perkat integrasi yang sempurna, menghubungkan dua layanan, yang tidak saling terhubung secara alami. Sekarang mari kita bahas kapan fungsi kurang tepat untuk digunakan. Proses yang berjalan lama adalah masalah, karena pada paket konsumsi, fungsi memiliki batas waktu default 5 menit atau hingga 10 menit jika dikonfigurasi. Jika tugas Anda memakan waktu lebih lama dari itu, Anda memerlukan. Aplikasi Stateful juga tidak cocok. Fungsi tidak menyimpan apapun di antara setiap proses berjalan. Jika Anda perlu mempertahankan status sesi atau melacak progres antar langkah, itu tidak sesuai dengan desainnya. Beban kerja komputasi berat juga tidak tepat. Jika Anda membutuhkan CPU yang terus menerus selama beberapa menit atau jam, mesin virtual atau kontainer adalah beban. Dan alur kerja kompleks, di mana satu tugas bergantung pada tugas lainnya, lebih baik ditangani oleh Durable Functions atau Logic Apps. Berikut adalah gambar singkat mengenai alternatif. Azure Logic Apps adalah opsi tanpa kode untuk menghubungkan perbagai lain. Jika Anda tidak perlu menulis kode kustom, Logic Apps dapat menyelesaikannya dengan desainer visual. Azure App Service ditujukan untuk aplikasi web penuh yang berjalan 2 part per Twitch. Jika Anda membutuhkan situs web atau api lengkap yang selalu aktif, itulah alatnya. Azure Container Apps memberikan Anda layanan mikro dalam kontainer dengan kontrol lebih atas rantai. Dan Azure Virtual Machines memberi Anda kendali penuh atas sistem operasi jika Anda membutuhkannya. Berikut aturan praktis yang sederhana. Jika Anda dapat mendeskripsikan tugas dalam satu kalimat, kemungkinan besar itu adalah kandidat yang baik untuk Anda. Kompres gambar saat diunggah. Kirim email selamat datang saat seorang mendaftar. Jalankan tugas pembersihan setiap malam pada tengah. Satu kalimat, satu tugas, satu fungsi. Kesalahan umum pemula yang harus dihindari. Sekarang mari kita bahas beberapa hal yang perlu diwaspare. Inilah kesalahan yang hampir menjebak semua orang saat baru memulai. Kesalahan umum pemula adalah menganggap fungsi selalu gratis. Hiba gratisnya memang besar, saya tahu 1 juta eksekusi terdengar banyak. Tetapi jika fungsi Anda viral atau diserang bot, eksekusi itu akan bertambah dengan cepat. Jadi, pantau penggunaan Anda, atur peringatan anggaran di Azure, dan hindari tagihan tak terduga di akhir bulan. Kesalahan lainnya adalah mengabaikan cold start. Pertama kali fungsi Anda berjalan setelah tidak aktif waktu yang dibutuhkan lebih lama. Ada paket konsumsi itu bisa memakan waktu beberapa detik. Untuk sebagian besar kasus menggunakan detik-detik. Namun, jika Anda membangun API yang sensitif terhadap latensi di mana setiap mili detik berarti, pertimbangkan paket premium atau aktifkan always ready instances. Lalu ada kesalahan menulis fungsi yang berjalan terlalu. Paket konsumsi memiliki batas waktu 5 menit sebagai standar, maksimal 10 menit. Jika fungsi Anda membutuhkan 15 menit untuk memproses file, prosesnya akan dihentikan di tengah jalan. Pecah pekerjaan itu menjadi bagian lebih kecil atau menggunakan paket hosting yang berbeda. Hal lain yang sering terlewatkan adalah tidak menggunakan penerapan run from package. Ini adalah perubahan konfigurasi sederhana yang meningkatkan call start dan membuat penerapan lebih andal. Alih-alih menyalin file satu persatu, Anda menerapkan paket zip. Hanya satu kotak centang di portal lakukan. Mengekspos endpoint HTTP tanpa autentikasi adalah jebakan lainnya. Sangat mudah untuk membiarkan fungsi tetap anonim saat pengujian, lalu lupa menguncinya. Tetapkan tingkat otorisasi Anda dengan benas jauh. Gunakan kunci fungsi admin. Jangan biarkan pintu terbuka. Menggunakan kembali akun penyimpanan di beberapa aplikasi fungsi juga merupakan. Dalam pengembangan berbagai itu tidak masalah. Dalam produksi, setiap aplikasi fungsi harus memiliki akun penyimpanan sendiri. Jika tidak, Anda akan mengalami masalah noise neighbor di mana lalu lintas satu fungsi lainnya. Dan terakhir, tidak mengaktifkan application insights. Tampaknya Anda seperti tampang tanda-tanda. Anda tidak akan melihat kegagalan, kesalahan, atau masalah kini. Anda tidak akan tahu jika fungsi Anda berjalan terlalu lama atau gagal secara dimenai. Aktifkan sejak hari pertama. Hanya butuh 30 detik dan menghemat waktu berjam-jam untuk dibagi. Aturan emas untuk semua ini adalah menjaga fungsi Anda tetap kecil, terfokus, dan stable. Satu pekerjaan per fungsi tidak lebih. Jadi, itulah sistemnya. Azure Functions adalah komputasi serverless yang menjalankan potongan kode kecil sebagai respons terhadap peristiwa. Anda hanya membayar saat kode Anda berjalan. Triggers memberi tahu fungsi Anda kapan harus aktif, bindings menghubungkannya ke data yang diperlukan, dan paket konsumsi membuatnya hampir gratis untuk proyek kecil. Langkah terbaik yang bisa Anda lakukan sekarang adalah membuat fungsi yang dipicu HTTP sederhana di portal Azure. Hanya butuh 5 menit dan tidak memakan biaya. Perlanggananlah ke Microsoft Knowledge Nuggets untuk penjelasan yang lebih mudah dan bagikan ini kepada seseorang yang terus bertanya apa arti serverless.