WEBVTT

00:00:00.000 --> 00:00:03.860
Topik hari ini adalah sesuatu yang hampir semua orang pernah dengar, tapi hampir tidak ada yang bisa menjelaskan.

00:00:04.180 --> 00:00:05.580
Serverless, apa sebenarnya itu?

00:00:05.960 --> 00:00:08.700
Atau sesuatu yang berjalan di ruang hampa, atau sesuatu yang jauh lebih besar.

00:00:08.940 --> 00:00:09.800
Mari kita luruskan satu hal.

00:00:10.380 --> 00:00:11.600
Serverless bukan berarti tanpa server.

00:00:12.000 --> 00:00:13.480
Itu berarti Anda tidak perlu memikirkannya.

00:00:13.660 --> 00:00:16.220
Dan perbedaan itu mengubah segalanya tentang cara Anda membangun perangkat lunak.

00:00:16.500 --> 00:00:18.780
Di akhir episode ini, Anda akan memahami apa itu Azure Function,

00:00:18.920 --> 00:00:21.240
sebagaimana harganya bekerja, dan kapan Anda harus menggunakannya.

00:00:21.820 --> 00:00:24.620
Kita akan membedahnya menjadi blok-blok dasar, dimulai dengan mitos terbesar.

00:00:25.420 --> 00:00:26.640
Apa arti sebenarnya dari serverless?

00:00:26.640 --> 00:00:28.600
Mari kita sekedar luruskan beberapa mitos.

00:00:29.100 --> 00:00:32.240
Nama serverless adalah istilah pemasaran terburuk yang pernah dibuat Microsoft.

00:00:32.660 --> 00:00:35.000
Itu membuat orang berpikir benar-benar tidak ada server yang terlibat.

00:00:35.160 --> 00:00:35.660
Itu tidak benar.

00:00:36.020 --> 00:00:36.960
Dan server jumlahnya sangat baik.

00:00:37.240 --> 00:00:38.380
Anda hanya tidak perlu menyentuhnya semestinya.

00:00:38.740 --> 00:00:42.720
20 tahun yang lalu, jika Anda ingin menjalankan sepotong kode di internet, Anda harus melakukan banyak pekerja.

00:00:42.880 --> 00:00:45.380
Anda harus menyewa mesin virtual, menginstall sistem operasi,

00:00:45.560 --> 00:00:47.740
mengonfigurasi web server, dan mendeploy aplikasi Anda.

00:00:47.900 --> 00:00:51.160
Kemudian Anda akan menghabiskan setiap akhir pekan untuk menambah pembaruan keamanan

00:00:51.160 --> 00:00:52.560
dan memastikan sistem tidak mati pada jam detik.

00:00:52.560 --> 00:00:53.300
Dan ilah masalah.

00:00:53.300 --> 00:00:56.160
Anda mau beri server itu terlepas dari apakah kode Anda berjalan atau tidak.

00:00:56.480 --> 00:00:58.780
Server itu terus menyala, membuang uang saat Anda tidur.

00:00:59.260 --> 00:01:01.020
Serverless membalikkan seluruh model ini.

00:01:01.680 --> 00:01:04.840
Anda menulis kode, mengenggahnya, dan platform menangani sisanya.

00:01:05.300 --> 00:01:08.440
Sistem operasi, tambalan keamanan, benskalaan, dan ketersediaan.

00:01:08.940 --> 00:01:10.540
Tugas Anda hanyalah menulis logika yang penting.

00:01:11.340 --> 00:01:15.420
Anggap saja seperti perbedaan antara menjalankan dapur restoran dan menggunakan mesin penjual otomatis.

00:01:15.760 --> 00:01:18.740
Dapur restoran membutuhkan staff lengkap persediaan konstan dan pemeliharaan.

00:01:19.120 --> 00:01:22.220
Dapur itu memakan biaya setiap hari, bahkan jika tidak ada pelanggan yang datang.

00:01:22.220 --> 00:01:26.960
Mesin penjual otomatis, ia hanya duduk di sudut tanpa melakukan apapun sampai seseorang menekan tombol.

00:01:27.420 --> 00:01:29.700
Kemudian ia hidup, menjalankan tugasnya, dan kembali tidur.

00:01:30.120 --> 00:01:32.100
Anda hanya membayar listrik saat mesin itu benar-benar pekerja.

00:01:32.440 --> 00:01:33.540
Begitulah gambaran singkat dengan serverless.

00:01:34.000 --> 00:01:35.480
Azure Function adalah versi Microsoft untuk ini.

00:01:36.000 --> 00:01:38.260
Ia menjalankan potongan kode kecil sebagai respons terhadap peristiwa.

00:01:38.800 --> 00:01:42.800
Kode Anda tidak aktif sampai ada sesuatu yang membangunkannya, lalu ia berjalan, selesai, dan kembali tidur.

00:01:43.240 --> 00:01:44.520
Jadi seperti apa sebenarnya kode itu?

00:01:45.360 --> 00:01:46.220
Apa itu Azure Function?

00:01:46.220 --> 00:01:49.440
Function adalah satu bagian kode yang melakukan satu tugas spesifik.

00:01:49.440 --> 00:01:53.740
Hanya, bukan aplikasi utuh dengan halaman login, basis data, dan 20 layar.

00:01:54.420 --> 00:01:55.660
Itu adalah satu tugas yang terfokus.

00:01:56.160 --> 00:01:57.680
Bayangkan seperti saklar lampu di rumah Anda.

00:01:57.980 --> 00:02:00.340
Bisa mati atau menyala saat bekerja, lalu mati kembali.

00:02:01.720 --> 00:02:03.400
Server web tradisional justru sebaliknya,

00:02:03.580 --> 00:02:05.960
seperti membiarkan semua lampu di rumah menyala 24 jam sehari,

00:02:06.260 --> 00:02:08.000
7 hari seminggu, bahkan saat tidak ada orang di rumah.

00:02:08.580 --> 00:02:11.160
Azure Functions mendukung banyak bahasa pemrograman yang berbeda.

00:02:11.160 --> 00:02:13.000
Anda bisa menggunakan apapun yang Anda kuasai.

00:02:13.100 --> 00:02:15.480
JavaScript, Python, C-Sarif Java, PowerShell.

00:02:15.960 --> 00:02:17.020
Tidak jawaban yang benar-benar di sini.

00:02:17.020 --> 00:02:18.380
Pilihlah bahasa yang sudah Anda ketahui.

00:02:18.840 --> 00:02:20.460
Sekarang mari kita luluskan kebingungan yang sering terjadi.

00:02:21.000 --> 00:02:22.380
Function app tidak sama dengan function.

00:02:23.180 --> 00:02:24.420
Function app adalah wadahnya.

00:02:25.060 --> 00:02:25.960
Tayangkan seperti kotak peralatan.

00:02:26.400 --> 00:02:27.480
Anda membuat satu function app,

00:02:27.740 --> 00:02:29.900
dan di dalam kotak peralatan itu Anda menambahkan beberapa fungsi.

00:02:30.200 --> 00:02:32.380
Setiap fungsi adalah alat terpisah yang menjalankan tugasnya sendiri.

00:02:32.720 --> 00:02:35.500
Anda mungkin memiliki satu fungsi untuk menangani pendaftaran pengguna,

00:02:35.640 --> 00:02:37.200
fungsi lain untuk memproses gambar yang diunggah,

00:02:37.200 --> 00:02:38.660
dan fungsi ketiga untuk mengirim laporan malam.

00:02:38.820 --> 00:02:41.160
Semuanya berada di kotak peralatan yang sama, tetapi bekerja secara hidup.

00:02:41.720 --> 00:02:42.760
Satu hal lagi tentang fungsi.

00:02:43.120 --> 00:02:44.320
Saya ada di sini fungsi bersifat setelah.

00:02:44.580 --> 00:02:46.420
Artinya fungsi tidak mengingat apapun di antara set proses.

00:02:46.620 --> 00:02:49.600
Jika fungsi Anda memproses file dan selesai, ya sudah selesai.

00:02:49.880 --> 00:02:52.400
Saat dijalankan lagi, fungsi dimulai dari awal tanpa ingatan tentang proses.

00:02:52.620 --> 00:02:53.920
Itu terdengar seperti keterbatasan,

00:02:54.040 --> 00:02:55.740
tetapi sebenarnya itu adalah fitur yang membuatnya begitu hebat.

00:02:56.120 --> 00:02:58.000
Karena fungsi tidak menyimpan memori atau state,

00:02:58.280 --> 00:03:01.600
Azure dapat langsung menjalankan 100 salinan fungsi Anda saat lalu lintas melonjak,

00:03:01.600 --> 00:03:03.800
dan mematikannya secepat itu saat lalu lintas menurut.

00:03:04.060 --> 00:03:06.780
Begitulah cara Anda mendapatkan skalabilitas tanpa harus membayang server yang menurut.

00:03:07.080 --> 00:03:07.800
Pertanyaannya adalah,

00:03:07.800 --> 00:03:09.760
Jika sebuah fungsi hanya diam tidak melakukan apa-apa

00:03:09.760 --> 00:03:11.040
sampai ada sesuatu yang membangunkannya,

00:03:11.160 --> 00:03:12.120
apa sebenarnya yang membangunkannya?

00:03:12.360 --> 00:03:13.480
Disitulah trigger atau pemicu berpengar.

00:03:13.760 --> 00:03:15.020
Trigger adalah kapan hal itu terjadi.

00:03:15.580 --> 00:03:17.920
Setiap fungsi harus memiliki tepat satu trigger, dan itu wajib.

00:03:18.420 --> 00:03:20.120
Trigger adalah peristiwa yang membangunkan fungsi Anda.

00:03:20.700 --> 00:03:23.400
Tanpanya, kode Anda hanya akan diam tidak melakukan apa-apa.

00:03:23.900 --> 00:03:24.840
Bayangkan trigger sepira pintu.

00:03:25.340 --> 00:03:26.720
Fungsi Anda berada dalam rumah sedang menunggu.

00:03:26.940 --> 00:03:28.100
Ia bisa menunggu selama.

00:03:28.420 --> 00:03:30.320
Tidak ada yang terjadi sampai seseorang bunyikan bel pintu.

00:03:30.900 --> 00:03:32.500
Kemudian fungsi tersebut langsung beraksi,

00:03:32.500 --> 00:03:34.760
membukakan pintu, melakukan tugasnya, dan kembali menunggu.

00:03:35.020 --> 00:03:37.200
Ada empat trigger yang paling sering ditemui oleh pemula.

00:03:37.920 --> 00:03:40.180
HTTP trigger adalah titik awal yang paling umum.

00:03:40.780 --> 00:03:42.960
Seseorang mengunjungi URL atau melakukan panggilan API,

00:03:43.160 --> 00:03:44.120
dan fungsi Anda langsung aktif.

00:03:44.400 --> 00:03:45.960
Begitulah cara Anda membangun API ringan

00:03:45.960 --> 00:03:47.640
tanpa harus menyiapkan server web lengkap.

00:03:48.200 --> 00:03:50.360
Lalu ada timer trigger yang berjalan sesuai jadwal.

00:03:50.920 --> 00:03:52.080
Anda mengatur ekspresi Chrome,

00:03:52.280 --> 00:03:54.640
seperti menjalankan setiap jam atau tengah malam setiap hari,

00:03:54.880 --> 00:03:57.400
dan fungsi Anda berjalan tepat pada waktu tersebut.

00:03:58.300 --> 00:03:59.880
Sangat cocok untuk tugas pemeliharaan,

00:03:59.880 --> 00:04:01.800
dan pekerjaan pembersihan, atau membuat laporan harian.

00:04:01.800 --> 00:04:04.800
Pemicu blop aktif saat file diunggah ke penyimpanan Azure.

00:04:05.460 --> 00:04:07.500
Katakanlah seseorang mengunggah PDF ke folder tertentu.

00:04:08.020 --> 00:04:09.320
Pemicu blop mendeteksi unggahan itu

00:04:09.320 --> 00:04:11.000
dan menjalankan fungsi Anda secara otomatis.

00:04:11.400 --> 00:04:13.040
Ini sangat berguna untuk pemrosesan gambar,

00:04:13.120 --> 00:04:14.620
konversi dokumen, dan validasi file.

00:04:15.240 --> 00:04:17.500
Dan pemicu antrean aktif saat pesan muncul di antrean.

00:04:18.260 --> 00:04:20.260
Antrean adalah cara untuk memisahkan berbagai sistem Anda.

00:04:20.900 --> 00:04:22.520
Satu layanan memasukkan pesan ke antrean,

00:04:22.600 --> 00:04:25.060
dan fungsi Anda mengambil serta memprosesnya kapanpun siap.

00:04:25.680 --> 00:04:28.260
Hal itu mencegah satu layanan yang lambat menghambat layanan lainnya.

00:04:28.260 --> 00:04:29.400
Ini poin kuncinya.

00:04:29.400 --> 00:04:33.240
Saat pemicu aktif, ia mengirimkan data ke fungsi Anda secara otomatis.

00:04:33.840 --> 00:04:35.840
Anda tidak permulakan polling atau memeriksa apakah suatu kata-kata.

00:04:36.240 --> 00:04:37.860
Pemicu memberikan semua yang Anda butuhkan

00:04:37.860 --> 00:04:39.180
dan fungsi Anda tinggal memprosesnya.

00:04:39.620 --> 00:04:42.320
Fungsi tanpa pemicu hanyalah kode yang diam dan tidak melakukan apapun.

00:04:42.800 --> 00:04:44.100
Pemicu lalu memberikan tujuan pada fungsi tersebut.

00:04:44.460 --> 00:04:46.280
Jadi pemicu memberitahu fungsi Anda kapan harus berjalan.

00:04:46.840 --> 00:04:48.640
Namun dari mana data itu berasal dan kemana pergi.

00:04:49.100 --> 00:04:49.920
Disitulah binding berperan.

00:04:50.980 --> 00:04:52.480
Binding, data masuk, data keluar.

00:04:53.200 --> 00:04:55.440
Binding adalah cara untuk memberitahu fungsi Anda data

00:04:55.440 --> 00:04:57.440
apa yang harus dibaca dan kemana harus mengirim hasil

00:04:57.440 --> 00:04:58.540
tanpa menulis kode tambahan.

00:04:59.000 --> 00:05:00.460
Itu terdengar rumit, jadi tinggal saya menyerana.

00:05:00.920 --> 00:05:01.480
Ada dua jenis.

00:05:01.820 --> 00:05:03.480
Binding input membawa data geram fungsi Anda.

00:05:03.900 --> 00:05:05.460
Binding output mengirim data keluar.

00:05:06.160 --> 00:05:08.120
Tanpa binding, Anda harus menulis kode SDK

00:05:08.120 --> 00:05:11.660
setiap kali ingin berkomunikasi dengan akun penyimpanan basis data atau antrean.

00:05:12.000 --> 00:05:13.340
Anda harus menangani string koneksi,

00:05:13.480 --> 00:05:14.400
mengelola percobaan ulang,

00:05:14.520 --> 00:05:15.560
membuat serialisasi data,

00:05:15.780 --> 00:05:16.760
dan deserialisasi respons.

00:05:17.100 --> 00:05:18.860
Itu adalah banyak kode boilerplate hanya untuk membaca satu.

00:05:19.260 --> 00:05:21.160
Dengan binding, Anda cukup mendeklarasikan apa yang Anda butuh.

00:05:21.160 --> 00:05:23.120
Anda berkata, saya ingin membaca dari kontainer blob ini.

00:05:23.560 --> 00:05:25.060
Atau saya ingin menulis keantrean ini.

00:05:25.620 --> 00:05:26.620
Runtime akan menangani sisanya.

00:05:27.020 --> 00:05:27.860
Ia membuka koneksi,

00:05:28.100 --> 00:05:28.640
membaca data,

00:05:28.840 --> 00:05:30.600
dan meneruskannya ke fungsi Anda sebagai parameter.

00:05:31.320 --> 00:05:32.360
Saat fungsi Anda selesai,

00:05:32.540 --> 00:05:35.140
ia mengambil nilai kembalian dan menulisnya ke tempat yang Anda tentukan.

00:05:35.720 --> 00:05:36.760
Anggap binding seperti pipa.

00:05:37.460 --> 00:05:40.300
Anda menghubungkan fungsi Anda ke akun penyimpanan basis data atau antrean.

00:05:40.780 --> 00:05:42.560
Data mengalir pipa-pipa itu secara otomatis.

00:05:43.300 --> 00:05:45.020
Fungsi Anda tidak perlu tahu cara kerja pipa tersebut.

00:05:45.640 --> 00:05:47.960
Ia hanya menerima apa yang masuk dan mengirim apa yang perlu keluar.

00:05:48.220 --> 00:05:49.340
Berikut adalah contohnya.

00:05:49.700 --> 00:05:50.900
Katakanlah Anda memiliki binding input.

00:05:51.440 --> 00:05:52.380
Saat fungsi Anda dimulai,

00:05:52.500 --> 00:05:54.300
ia otomatis membaca file dari penyimpanan blob

00:05:54.300 --> 00:05:55.740
dan memberikannya kepada Anda sebagai parameter.

00:05:55.940 --> 00:05:57.520
Anda tidak perlu menulis kode SDK penyimpanan blob.

00:05:57.940 --> 00:05:59.460
Anda hanya perlu data tersebut dan memprosesnya.

00:05:59.760 --> 00:06:00.160
Contoh lain,

00:06:00.360 --> 00:06:01.260
binding output antrean Q.

00:06:01.680 --> 00:06:02.780
Fungsi Anda memproses suatu,

00:06:03.020 --> 00:06:04.580
dan pada akhirnya Anda mengembalikan sebuah nilai.

00:06:04.900 --> 00:06:06.040
Runtime mengambil nilai tersebut,

00:06:06.260 --> 00:06:06.880
mengubah formatnya,

00:06:07.080 --> 00:06:08.100
dan memasukkannya ke antrean.

00:06:08.440 --> 00:06:09.640
Anda tidak perlu menulis kode antrean.

00:06:09.900 --> 00:06:10.900
Anda cukup mengembalikan sebuah nilai.

00:06:11.140 --> 00:06:12.020
Binding bersifat opsional.

00:06:12.400 --> 00:06:13.860
Anda bisa memiliki 0, 1, atau banyak.

00:06:14.520 --> 00:06:16.680
Beberapa fungsi hanya memerlukan pemicu tanpa binding sama sekali.

00:06:17.540 --> 00:06:20.160
Fungsi lain mungkin memiliki 3 atau 4 bindingan terhubung kelayanan berbeda.

00:06:20.760 --> 00:06:23.760
Kombinasi antara pemicu dan binding inilah yang membuat Azure Functions begitu hebat.

00:06:24.300 --> 00:06:26.860
Anda menulis logika bisnis kode pengambilan keputusan yang sebenarnya

00:06:26.860 --> 00:06:28.780
platform menangani semua integrasinya.

00:06:29.540 --> 00:06:32.140
Fungsi Anda tetap kecil, fokus, dan mudah dipahami.

00:06:34.080 --> 00:06:34.620
Cerita tentang harga.

00:06:35.060 --> 00:06:36.900
Harga inilah yang paling mengejutkan bagi banyak pemutu.

00:06:37.300 --> 00:06:39.440
Bagi banyak orang, paket konsumsi adalah pilihan default,

00:06:39.560 --> 00:06:41.780
dan Anda sebaiknya mulai dengan paket ini 90% dari waktu.

00:06:42.220 --> 00:06:42.880
Begini cara kerjanya.

00:06:43.340 --> 00:06:45.180
Anda membayar hanya saat fungsi Anda benar-benar pencarian.

00:06:45.180 --> 00:06:46.920
Ketika tidak aktif, Anda tidak membayar apapun.

00:06:47.260 --> 00:06:48.120
No liter special phone.

00:06:49.000 --> 00:06:50.180
Dua komponen membentuk tagihannya.

00:06:50.720 --> 00:06:53.540
Pertama, jumlah eksekusi seberapa sering fungsi Anda dijalankan.

00:06:54.140 --> 00:06:57.500
Kedua, waktu eksekusi yang diukur dalam satuan yang disebut GB detik.

00:06:57.920 --> 00:06:59.860
Itu pada dasarnya adalah berapa lama fungsi Anda berjalan

00:06:59.860 --> 00:07:01.480
dikalikan dengan berapa banyak memori yang digunakan.

00:07:01.580 --> 00:07:02.480
Jata gratisnya sangat besar.

00:07:02.820 --> 00:07:04.820
Anda mendapatkan 1 juta eksekusi per bulan

00:07:04.820 --> 00:07:07.120
dan 400 ribu GB detik sepenuhnya gratis.

00:07:07.560 --> 00:07:09.940
Untuk sebagian besar proyek kecil, aplikasi hobi, dan prototipe,

00:07:10.100 --> 00:07:11.300
Anda tidak akan pernah membayar special phone.

00:07:11.640 --> 00:07:11.860
Amin.

00:07:11.860 --> 00:07:15.020
Jika Anda melebih jatah gratis, tarifnya masih sangat murah.

00:07:15.440 --> 00:07:16.600
20 sen berjuta eksekusi.

00:07:16.920 --> 00:07:17.580
Itu bukan salah satu.

00:07:17.760 --> 00:07:19.300
20 sen untuk sejuta kali berjalanan.

00:07:19.520 --> 00:07:22.280
Anggap saja seperti membayar listrik hanya saat Anda menyalakan saklar.

00:07:22.740 --> 00:07:25.080
Tidak ada biaya dasar bulanan untuk pemasangan kabel di dinding Anda.

00:07:25.620 --> 00:07:27.200
Anda hanya membayar daya yang benar-benar Anda gunakan.

00:07:27.800 --> 00:07:28.480
Ada paket lain juga.

00:07:29.220 --> 00:07:31.380
Flex Consumption lebih baru dan memberi Anda dukungan jaringan film.

00:07:31.860 --> 00:07:33.520
Premium menjaga fungsi Anda tetap aktif,

00:07:33.600 --> 00:07:34.480
jadi tidak ada jaringan awal.

00:07:34.480 --> 00:07:38.220
Dedicate memberi Anda kapasitas tetap pada paket app service tradisional.

00:07:38.860 --> 00:07:41.460
Namun untuk memulai consumption adalah pilihan yang tepat hampir setiap saat.

00:07:41.800 --> 00:07:42.400
Atau peringatan meskipun.

00:07:42.720 --> 00:07:46.000
Jatah gratis dibagikan ke seluruh aplikasi fungsi Anda dalam langgan yang sama.

00:07:46.340 --> 00:07:47.920
Jika Anda memiliki 10 aplikasi fungsi,

00:07:48.040 --> 00:07:49.800
semuanya menggunakan jatah 1 juta eksekusi yang sama.

00:07:50.120 --> 00:07:52.660
Jadi perhatikan hal itu jika Anda mulai membangun lebih dari beberapa aplikasi.

00:07:53.100 --> 00:07:53.740
Harganya sangat bagus.

00:07:53.740 --> 00:07:56.060
Namun mari kita buat ini nyata dengan contoh konkret.

00:07:56.840 --> 00:07:57.840
Skenario Dunia Nyata

00:07:57.840 --> 00:08:00.800
Bayangkan Anda mengolah situs web di mana pengguna mengunggah foto profil.

00:08:01.200 --> 00:08:03.420
Gambar-gambar tersebut berukuran besar sekitar 10 MBP gambar.

00:08:04.020 --> 00:08:05.400
Dan itu menimbulkan beberapa masalah nyata.

00:08:05.880 --> 00:08:07.420
File besar lebih mahal untuk disimpan,

00:08:07.560 --> 00:08:10.060
memperlambat situs web Anda setiap kali seseorang memuat halaman,

00:08:10.180 --> 00:08:12.140
dan membuat pengguna frustrasi karena harus melunggu foto.

00:08:12.540 --> 00:08:15.800
Jadi Anda perlu cara untuk mengecilkan gambar tersebut secara otomatis.

00:08:16.180 --> 00:08:19.320
Tanpa Azure Functions, Anda harus membuat pekerja latar belakang dari awal.

00:08:19.860 --> 00:08:21.720
Artinya Anda perlu menyiapkan server terpisah,

00:08:21.840 --> 00:08:23.320
membuat antrean untuk mengatur beban kerja,

00:08:23.320 --> 00:08:25.560
dan menulis kode untuk menangani semua bagian yang berjalan.

00:08:25.960 --> 00:08:28.200
Itu adalah kerumitan yang tidak perlu untuk sesuatu yang sederhana

00:08:28.200 --> 00:08:29.260
seperti mengecilkan gambar.

00:08:30.000 --> 00:08:32.920
Dengan Azure Functions, Anda hanya butuh satu pemicu blob dan satu fungsi.

00:08:33.740 --> 00:08:34.780
Tidak perlu pusing memikirkan server.

00:08:35.220 --> 00:08:36.520
Ijinkan saya menjelaskan cara kerjaannya.

00:08:36.980 --> 00:08:38.960
Seorang pengguna mengunggah foto melalui situs web Anda,

00:08:39.080 --> 00:08:40.720
dan file tersebut masuk ke penyimpanan blob Azure.

00:08:41.180 --> 00:08:43.460
Saat file tiba, pemicu blob akan aktif secara otomatis.

00:08:43.660 --> 00:08:45.720
Fungsi Anda aktif, menjalankan kode kompresi,

00:08:45.860 --> 00:08:48.040
dan menyimpan versi yang lebih kecil kembali ke penyimpanan.

00:08:48.620 --> 00:08:49.800
Semua ini terjadi dalam hitungan detik.

00:08:49.800 --> 00:08:53.120
Pengguna tidak perlu menunggu karena seluruh proses berjalan di latar belakang

00:08:53.120 --> 00:08:54.200
sepenuhnya tidak terlihat.

00:08:54.940 --> 00:08:56.000
Contoh sehari-hari lainnya,

00:08:56.560 --> 00:08:58.860
mengirim email selamat datang saat seseorang mendaftar kelayanan Anda.

00:08:59.400 --> 00:09:01.640
Pemicu HTTP menangkap pendaftaran dari situs web Anda.

00:09:02.400 --> 00:09:04.280
Fungsi Anda aktif, mengambil alamat email pengguna,

00:09:04.480 --> 00:09:06.040
mengirim pesan selamat datang melalui SendGrid,

00:09:06.160 --> 00:09:08.520
lalu selesai, pengguna menerima email mereka berseketikan.

00:09:09.240 --> 00:09:10.400
Tidak perlu menyiapkan server email,

00:09:10.580 --> 00:09:11.720
tidak perlu mengelola antara yang kirim.

00:09:12.180 --> 00:09:13.300
Hanya satu fungsi, satu tugas.

00:09:13.300 --> 00:09:13.760
Selesai.

00:09:14.160 --> 00:09:16.400
Inilah pekerjaan yang dirancang khusus untuk Azure Function.

00:09:16.400 --> 00:09:18.720
Tugas kecil, terfokus, dan berbasis peristiwa.

00:09:18.920 --> 00:09:20.820
Bukan aplikasi besar, bukan alur kerja yang kompleks,

00:09:20.960 --> 00:09:22.320
hanya satu hal yang dilakukan dengan baik,

00:09:22.440 --> 00:09:24.020
dipicu oleh sesuatu yang terjadi di tempat lain.

00:09:24.900 --> 00:09:26.040
Kapan menggunakan Azure Functions?

00:09:26.820 --> 00:09:28.240
Jadi kapan Anda harus menggunakan fungsi,

00:09:28.340 --> 00:09:29.480
dan kapan harus menggunakan hal lain?

00:09:30.180 --> 00:09:31.420
Berikut adalah cepat untuk mentuskan.

00:09:31.720 --> 00:09:33.680
Tanyakan pada diri sendiri apakah tugas tersebut singkat,

00:09:33.740 --> 00:09:35.500
berbasis peristiwa, dan tidak memiliki status status.

00:09:36.160 --> 00:09:37.640
Jika Anda menjawab, ya untuk ketiganya,

00:09:37.640 --> 00:09:39.560
Azure Functions mungkin adalah alat yang tepat.

00:09:40.340 --> 00:09:41.160
Mari kita mulai yang baik.

00:09:41.920 --> 00:09:43.640
API dan webhook adalah pasangan yang sempurna.

00:09:43.640 --> 00:09:47.220
Anda memerlukan titik akhiringan yang merespons permintaan HTTPE

00:09:47.220 --> 00:09:49.240
melakukan satu hal dan mengembalikan hasil,

00:09:49.400 --> 00:09:51.260
dan itulah tujuan dibuatnya pemicu HTTPE.

00:09:52.160 --> 00:09:53.820
Pempresesan file dan gambar adalah contoh besar.

00:09:54.200 --> 00:09:56.460
File masuk ke penyimpanan, fungsi Anda aktif,

00:09:56.580 --> 00:09:58.180
mengubahnya, dan menyimpan hasilnya,

00:09:58.320 --> 00:09:59.120
semua tanpa server.

00:09:59.780 --> 00:10:01.520
Tugas terjadwal seperti pembersihan malam

00:10:01.520 --> 00:10:04.040
atau pembuatan laporan sangat cocok dengan pemicu pengatur waktu.

00:10:05.080 --> 00:10:07.400
Transformasi data untuk pipeline ETL juga sering dilakukan.

00:10:08.080 --> 00:10:10.180
Dan fungsi menjadi perkat integrasi yang sempurna,

00:10:10.420 --> 00:10:11.320
menghubungkan dua layanan,

00:10:11.500 --> 00:10:12.800
yang tidak saling terhubung secara alami.

00:10:12.800 --> 00:10:15.340
Sekarang mari kita bahas kapan fungsi kurang tepat untuk digunakan.

00:10:15.840 --> 00:10:17.380
Proses yang berjalan lama adalah masalah,

00:10:17.780 --> 00:10:19.000
karena pada paket konsumsi,

00:10:19.440 --> 00:10:21.300
fungsi memiliki batas waktu default 5 menit

00:10:21.300 --> 00:10:23.420
atau hingga 10 menit jika dikonfigurasi.

00:10:24.060 --> 00:10:25.740
Jika tugas Anda memakan waktu lebih lama dari itu,

00:10:25.800 --> 00:10:26.280
Anda memerlukan.

00:10:26.800 --> 00:10:28.160
Aplikasi Stateful juga tidak cocok.

00:10:28.920 --> 00:10:30.960
Fungsi tidak menyimpan apapun di antara setiap proses berjalan.

00:10:31.380 --> 00:10:32.860
Jika Anda perlu mempertahankan status sesi

00:10:32.860 --> 00:10:34.120
atau melacak progres antar langkah,

00:10:34.280 --> 00:10:35.380
itu tidak sesuai dengan desainnya.

00:10:35.940 --> 00:10:37.480
Beban kerja komputasi berat juga tidak tepat.

00:10:37.920 --> 00:10:39.600
Jika Anda membutuhkan CPU yang terus menerus

00:10:39.600 --> 00:10:40.800
selama beberapa menit atau jam,

00:10:40.800 --> 00:10:42.340
mesin virtual atau kontainer adalah beban.

00:10:42.720 --> 00:10:43.760
Dan alur kerja kompleks,

00:10:44.020 --> 00:10:45.600
di mana satu tugas bergantung pada tugas lainnya,

00:10:45.820 --> 00:10:48.020
lebih baik ditangani oleh Durable Functions atau Logic Apps.

00:10:48.420 --> 00:10:49.980
Berikut adalah gambar singkat mengenai alternatif.

00:10:50.480 --> 00:10:52.180
Azure Logic Apps adalah opsi tanpa kode

00:10:52.180 --> 00:10:53.220
untuk menghubungkan perbagai lain.

00:10:53.620 --> 00:10:55.000
Jika Anda tidak perlu menulis kode kustom,

00:10:55.220 --> 00:10:57.040
Logic Apps dapat menyelesaikannya dengan desainer visual.

00:10:57.620 --> 00:10:59.680
Azure App Service ditujukan untuk aplikasi web penuh

00:10:59.680 --> 00:11:00.800
yang berjalan 2 part per Twitch.

00:11:01.260 --> 00:11:02.700
Jika Anda membutuhkan situs web

00:11:02.700 --> 00:11:03.860
atau api lengkap yang selalu aktif,

00:11:03.960 --> 00:11:04.380
itulah alatnya.

00:11:04.980 --> 00:11:06.940
Azure Container Apps memberikan Anda layanan mikro

00:11:06.940 --> 00:11:08.860
dalam kontainer dengan kontrol lebih atas rantai.

00:11:08.860 --> 00:11:10.800
Dan Azure Virtual Machines memberi Anda kendali penuh

00:11:10.800 --> 00:11:12.320
atas sistem operasi jika Anda membutuhkannya.

00:11:12.880 --> 00:11:14.080
Berikut aturan praktis yang sederhana.

00:11:14.520 --> 00:11:16.740
Jika Anda dapat mendeskripsikan tugas dalam satu kalimat,

00:11:17.000 --> 00:11:18.820
kemungkinan besar itu adalah kandidat yang baik untuk Anda.

00:11:19.480 --> 00:11:20.620
Kompres gambar saat diunggah.

00:11:21.440 --> 00:11:23.000
Kirim email selamat datang saat seorang mendaftar.

00:11:24.000 --> 00:11:25.720
Jalankan tugas pembersihan setiap malam pada tengah.

00:11:26.340 --> 00:11:27.800
Satu kalimat, satu tugas, satu fungsi.

00:11:28.880 --> 00:11:30.320
Kesalahan umum pemula yang harus dihindari.

00:11:30.760 --> 00:11:32.540
Sekarang mari kita bahas beberapa hal yang perlu diwaspare.

00:11:32.780 --> 00:11:35.680
Inilah kesalahan yang hampir menjebak semua orang saat baru memulai.

00:11:35.680 --> 00:11:38.720
Kesalahan umum pemula adalah menganggap fungsi selalu gratis.

00:11:39.500 --> 00:11:40.660
Hiba gratisnya memang besar,

00:11:40.820 --> 00:11:42.700
saya tahu 1 juta eksekusi terdengar banyak.

00:11:43.100 --> 00:11:45.040
Tetapi jika fungsi Anda viral atau diserang bot,

00:11:45.180 --> 00:11:47.160
eksekusi itu akan bertambah dengan cepat.

00:11:47.860 --> 00:11:49.200
Jadi, pantau penggunaan Anda,

00:11:49.420 --> 00:11:50.640
atur peringatan anggaran di Azure,

00:11:50.780 --> 00:11:52.500
dan hindari tagihan tak terduga di akhir bulan.

00:11:52.800 --> 00:11:54.400
Kesalahan lainnya adalah mengabaikan cold start.

00:11:54.880 --> 00:11:56.880
Pertama kali fungsi Anda berjalan setelah tidak aktif

00:11:56.880 --> 00:11:57.840
waktu yang dibutuhkan lebih lama.

00:11:57.840 --> 00:12:00.120
Ada paket konsumsi itu bisa memakan waktu beberapa detik.

00:12:00.440 --> 00:12:01.720
Untuk sebagian besar kasus menggunakan detik-detik.

00:12:01.720 --> 00:12:04.360
Namun, jika Anda membangun API yang sensitif terhadap latensi

00:12:04.360 --> 00:12:05.480
di mana setiap mili detik berarti,

00:12:05.760 --> 00:12:08.180
pertimbangkan paket premium atau aktifkan always ready instances.

00:12:09.260 --> 00:12:10.980
Lalu ada kesalahan menulis fungsi yang berjalan terlalu.

00:12:11.680 --> 00:12:14.180
Paket konsumsi memiliki batas waktu 5 menit sebagai standar,

00:12:14.260 --> 00:12:14.980
maksimal 10 menit.

00:12:15.700 --> 00:12:18.360
Jika fungsi Anda membutuhkan 15 menit untuk memproses file,

00:12:18.460 --> 00:12:19.940
prosesnya akan dihentikan di tengah jalan.

00:12:20.420 --> 00:12:21.960
Pecah pekerjaan itu menjadi bagian lebih kecil

00:12:21.960 --> 00:12:23.100
atau menggunakan paket hosting yang berbeda.

00:12:23.100 --> 00:12:24.920
Hal lain yang sering terlewatkan adalah

00:12:24.920 --> 00:12:26.660
tidak menggunakan penerapan run from package.

00:12:27.060 --> 00:12:28.640
Ini adalah perubahan konfigurasi sederhana

00:12:28.640 --> 00:12:30.920
yang meningkatkan call start dan membuat penerapan lebih andal.

00:12:31.980 --> 00:12:33.620
Alih-alih menyalin file satu persatu,

00:12:33.920 --> 00:12:34.900
Anda menerapkan paket zip.

00:12:35.340 --> 00:12:36.820
Hanya satu kotak centang di portal lakukan.

00:12:37.440 --> 00:12:40.380
Mengekspos endpoint HTTP tanpa autentikasi adalah jebakan lainnya.

00:12:40.920 --> 00:12:43.500
Sangat mudah untuk membiarkan fungsi tetap anonim saat pengujian,

00:12:43.720 --> 00:12:44.460
lalu lupa menguncinya.

00:12:45.140 --> 00:12:47.140
Tetapkan tingkat otorisasi Anda dengan benas jauh.

00:12:47.380 --> 00:12:48.360
Gunakan kunci fungsi admin.

00:12:48.740 --> 00:12:49.620
Jangan biarkan pintu terbuka.

00:12:49.760 --> 00:12:52.240
Menggunakan kembali akun penyimpanan di beberapa aplikasi fungsi

00:12:52.240 --> 00:12:52.780
juga merupakan.

00:12:53.040 --> 00:12:54.380
Dalam pengembangan berbagai itu tidak masalah.

00:12:54.380 --> 00:12:57.500
Dalam produksi, setiap aplikasi fungsi harus memiliki akun penyimpanan sendiri.

00:12:58.120 --> 00:12:59.900
Jika tidak, Anda akan mengalami masalah noise neighbor

00:12:59.900 --> 00:13:01.360
di mana lalu lintas satu fungsi lainnya.

00:13:02.100 --> 00:13:04.020
Dan terakhir, tidak mengaktifkan application insights.

00:13:04.380 --> 00:13:05.540
Tampaknya Anda seperti tampang tanda-tanda.

00:13:05.800 --> 00:13:08.380
Anda tidak akan melihat kegagalan, kesalahan, atau masalah kini.

00:13:08.620 --> 00:13:10.700
Anda tidak akan tahu jika fungsi Anda berjalan terlalu lama

00:13:10.700 --> 00:13:11.500
atau gagal secara dimenai.

00:13:11.720 --> 00:13:12.600
Aktifkan sejak hari pertama.

00:13:13.020 --> 00:13:15.160
Hanya butuh 30 detik dan menghemat waktu berjam-jam untuk dibagi.

00:13:15.540 --> 00:13:17.020
Aturan emas untuk semua ini adalah

00:13:17.020 --> 00:13:19.320
menjaga fungsi Anda tetap kecil, terfokus, dan stable.

00:13:19.920 --> 00:13:21.420
Satu pekerjaan per fungsi tidak lebih.

00:13:21.420 --> 00:13:22.660
Jadi, itulah sistemnya.

00:13:23.080 --> 00:13:24.800
Azure Functions adalah komputasi serverless

00:13:24.800 --> 00:13:27.040
yang menjalankan potongan kode kecil sebagai respons terhadap peristiwa.

00:13:27.320 --> 00:13:28.720
Anda hanya membayar saat kode Anda berjalan.

00:13:29.180 --> 00:13:31.220
Triggers memberi tahu fungsi Anda kapan harus aktif,

00:13:31.340 --> 00:13:32.880
bindings menghubungkannya ke data yang diperlukan,

00:13:33.020 --> 00:13:35.520
dan paket konsumsi membuatnya hampir gratis untuk proyek kecil.

00:13:36.060 --> 00:13:37.660
Langkah terbaik yang bisa Anda lakukan sekarang

00:13:37.660 --> 00:13:40.460
adalah membuat fungsi yang dipicu HTTP sederhana di portal Azure.

00:13:40.980 --> 00:13:42.520
Hanya butuh 5 menit dan tidak memakan biaya.

00:13:43.000 --> 00:13:44.580
Perlanggananlah ke Microsoft Knowledge Nuggets

00:13:44.580 --> 00:13:45.700
untuk penjelasan yang lebih mudah

00:13:45.700 --> 00:13:47.540
dan bagikan ini kepada seseorang yang terus bertanya

00:13:47.540 --> 00:13:48.480
apa arti serverless.