Otomatisasi cloud berbasis peristiwa

Mengotomatiskan alur kerja dan tugas berulang di cloud, dengan menggunakan teknologi tanpa server, dapat secara dramatis meningkatkan produktivitas tim DevOps organisasi. Model tanpa server paling cocok untuk skenario otomatisasi yang sesuai dengan pendekatan berbasis peristiwa.

Arsitektur

Skenario

Artikel ini mengilustrasikan dua skenario otomatisasi cloud utama:

1. Penandaan pusat biaya: Implementasi ini melacak pusat biaya setiap sumber daya Azure. Layanan Azure Policymenandai semua sumber daya baru dalam grup dengan ID pusat biaya default. Azure Event Grid memantau peristiwa pembuatan sumber daya, lalu memanggil fungsi Azure. Fungsi berinteraksi dengan ID Microsoft Entra, dan memvalidasi ID pusat biaya untuk sumber daya baru. Jika berbeda, ia memperbarui tag dan mengirimkan email ke pemilik sumber daya. Kueri REST untuk ID Microsoft Entra ditiru untuk mempermudah. ID Microsoft Entra juga dapat diintegrasikan menggunakan modul Microsoft Graph PowerShell atau Microsoft Authentication Library (MSAL) untuk Python.

2. Respons pembatasan: Contoh ini memantau database Azure Cosmos DB untuk pembatasan. Pemberitahuan Azure Monitor dipicu saat permintaan akses data ke Azure Cosmos DB melebihi kapasitas di Unit Permintaan (atau RU). Grup tindakan Azure Monitor dikonfigurasi untuk memanggil fungsi otomatisasi sebagai respons terhadap peringatan ini. Fungsi ini menskalakan RUs ke nilai yang lebih tinggi, meningkatkan kapasitas dan pada gilirannya menghentikan peringatan.

Implementasi referensi untuk skenario satu tersedia di GitHub.

Fungsi dalam skenario otomatisasi cloud tanpa server ini sering ditulis dalam PowerShell dan Python, dua bahasa scripting yang paling umum digunakan dalam otomatisasi sistem. Mereka diterapkan menggunakan Azure Functions Core Tools di Azure CLI. Atau, Anda menggunakan cmdlet Az.Functions PowerShell untuk menyebarkan dan mengelola Azure Functions.

Alur kerja

Skenario otomatisasi berbasis peristiwa paling baik diimplementasikan menggunakan Azure Functions. Mereka mengikuti pola-pola umum ini:

• Menanggapi peristiwa tentang sumber daya. Ini adalah tanggapan terhadap peristiwa seperti sumber daya Azure atau grup sumber daya yang dibuat, dihapus, diubah, dan sebagainya. Pola ini menggunakan Event Grid untuk memicu fungsi untuk peristiwa tersebut. Skenario penandaan pusat biaya adalah contoh dari pola ini. Skenario umum meliputi:

  • memberikan akses tim DevOps ke grup sumber daya yang baru dibuat,
  • mengirim pemberitahuan ke DevOps saat sumber daya dihapus, dan
  • menanggapi peristiwa pemeliharaan untuk sumber daya seperti Azure Virtual Machines (VM).

• Tugas terjadwal. Ini biasanya tugas pemeliharaan yang dijalankan menggunakan fungsi yang dipicu waktu. Contoh dari pola ini adalah:

  • menghentikan sumber daya di malam hari, dan mulai di pagi hari,
  • membaca konten Blob Storage secara berkala, dan mengonversi ke dokumen Azure Cosmos DB,
  • secara berkala memindai sumber daya yang tidak lagi digunakan, dan menghapusnya, dan
  • Pencadangan Otomatis.

• Memproses peringatan Azure. Pola ini menggunakan kemudahan mengintegrasikan peringatan dan grup tindakan Azure Monitor dengan Azure Functions. Fungsi ini biasanya mengambil tindakan perbaikan dalam menanggapi metrik, analisis log, dan peringatan yang berasal dari aplikasi dan infrastruktur. Skenario respons pelambatan adalah contoh dari pola ini. Skenario umum lainnya:

  • memotong tabel ketika SQL Database mencapai ukuran maksimum,
  • memulai ulang layanan di VM saat dihentikan secara keliru, dan
  • mengirim pemberitahuan jika fungsi gagal.

• Mengatur dengan sistem eksternal. Pola ini memungkinkan integrasi dengan sistem eksternal, menggunakan Logic Apps untuk mengatur alur kerja. Konektor Logic Apps dapat dengan mudah berintegrasi dengan beberapa layanan pihak ketiga serta layanan Microsoft seperti Microsoft 365. Azure Functions dapat digunakan untuk otomatisasi yang sebenarnya. Skenario penandaan pusat biaya menunjukkan pola ini. Skenario umum meliputi:

  • memantau proses TI seperti permintaan perubahan atau persetujuan, dan
  • mengirim pemberitahuan email saat tugas otomatisasi selesai.

• Expose sebagai web hook atau API. Tugas otomatisasi menggunakan Azure Functions dapat diintegrasikan ke dalam aplikasi pihak ketiga atau bahkan alat baris perintah, dengan mengekspos fungsi sebagai web hook / API menggunakan pemicu HTTP. Beberapa metode autentikasi tersedia di PowerShell dan Python untuk mengamankan akses eksternal ke fungsi. Otomatisasi terjadi sebagai respons terhadap peristiwa eksternal khusus aplikasi, misalnya, integrasi dengan aplikasi daya atau GitHub. Skenario umum meliputi:

  • memicu otomatisasi untuk layanan yang gagal, dan
  • orientasi pengguna ke sumber daya organisasi.

• Buat antarmuka ChatOps. Pola ini memungkinkan pelanggan untuk membuat antarmuka operasional berbasis obrolan, dan menjalankan fungsi dan perintah pengembangan dan operasi sesuai dengan kolaborasi manusia. Ini dapat berintegrasi dengan Azure Bot Framework dan menggunakan perintah Microsoft Teams atau Slack untuk penyebaran, pemantauan, pertanyaan umum, dan sebagainya. Antarmuka ChatOps membuat sistem real-time untuk mengelola insiden produksi, dengan setiap langkah didokumentasikan secara otomatis di obrolan. Baca Bagaimana ChatOps dapat membantu Anda DevOps lebih baik untuk informasi lebih lanjut.

• Otomatisasi hibrid. Pola ini menggunakan Azure App Service Hybrid Connections untuk menginstal komponen perangkat lunak pada mesin lokal Anda. Komponen ini memungkinkan akses aman ke sumber daya pada mesin itu. Kemampuan untuk mengelola lingkungan hibrida saat ini tersedia pada sistem berbasis Windows menggunakan fungsi PowerShell. Skenario umum meliputi:

  • mengelola mesin lokal Anda, dan
  • mengelola sistem lain di belakang firewall (misalnya, SQL Server lokal) melalui server lompat.

Komponen

Arsitektur terdiri dari komponen-komponen berikut:

• Fungsi-fungsi Azure. Azure Functions menyediakan kemampuan komputasi tanpa server berbasis peristiwa dalam arsitektur ini. Fungsi melakukan tugas otomatisasi, ketika dipicu oleh peristiwa atau peringatan. Dalam dua skenario, fungsi dipanggil dengan permintaan HTTP. Kompleksitas kode harus diminimalkan, dengan mengembangkan fungsi yang stateless dan idempotent.

  Beberapa eksekusi fungsi idempotent menciptakan hasil yang sama. Untuk mempertahankan idempotensi, penskalaan fungsi dalam skenario pelambatan dibuat sederhana. Dalam otomatisasi dunia nyata, pastikan untuk meningkatkan atau menurunkan skala dengan tepat. Baca Optimalkan kinerja dan keandalan Azure Functions untuk praktik terbaik saat menulis fungsi Anda.

• Azure Logic Apps. Logic Apps dapat digunakan untuk melakukan tugas yang lebih sederhana, mudah diimplementasikan menggunakan konektor bawaan. Tugas-tugas ini dapat berkisar dari pemberitahuan email, hingga mengintegrasikan dengan aplikasi manajemen eksternal. Untuk mempelajari cara menggunakan Aplikasi Logika dengan aplikasi pihak ketiga, baca integrasi perusahaan dasar di Azure.

  Logic Apps menyediakan kode atau desainer visual kode rendah, dan dapat digunakan sendiri dalam beberapa skenario otomatisasi. Baca perbandingan antara Azure Functions dan Logic Apps ini untuk melihat layanan mana yang sesuai dengan skenario Anda.

• Event Grid. Event Grid memiliki dukungan bawaan untuk acara dari layanan Azure lainnya, serta acara khusus (juga disebut topik kustom). Peristiwa operasional seperti pembuatan sumber daya dapat dengan mudah disebarkan ke fungsi otomatisasi, menggunakan mekanisme bawaan Event Grid.

  Event Grid menyederhanakan otomatisasi berbasis-acara dengan model publish-subscribe, memungkinkan otomatisasi yang andal untuk acara yang dikirimkan melalui HTTPS.

• Azure Monitor. Peringatan Azure Monitor dapat memantau kondisi kritis, dan mengambil tindakan korektif menggunakan grup tindakan Azure Monitor. Grup tindakan ini mudah diintegrasikan dengan Azure Functions. Ini berguna untuk mengawasi dan memperbaiki kondisi kesalahan dalam infrastruktur Anda, seperti pelambatan database.

• Tindakan otomatisasi. Blok luas ini mewakili layanan lain yang dapat berinteraksi dengan fungsi Anda, untuk menyediakan fungsionalitas otomatisasi. Misalnya, ID Microsoft Entra untuk validasi tag seperti dalam skenario pertama, atau database yang akan disediakan seperti dalam skenario kedua.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Ketahanan

Azure Functions

Menangani batas waktu HTTP

Untuk menghindari batas waktu HTTP untuk tugas otomatisasi yang lebih lama, antre acara ini dalam Bus Layanan, dan tangani otomatisasi aktual di fungsi lain. Skenario otomatisasi respons pembatasan menggambarkan pola ini, meskipun provisi RU Azure Cosmos DB yang sebenarnya cepat.

Fungsi Tahan Lama, yang mempertahankan keadaan di antara doa, memberikan alternatif untuk pendekatan di atas. Fungsi Tahan Lama hanya mendukung bahasa tertentu.

Kegagalan log

Sebagai praktik terbaik, fungsi harus mencatat kegagalan apa pun dalam melakukan tugas otomatisasi. Hal ini memungkinkan pemecahan masalah yang tepat dari kondisi kesalahan. Azure Functions secara langsung mendukung integrasi dengan Aplikasi Insights sebagai sistem telemetri.

Konkurensi

Verifikasi persyaratan konkurensi untuk fungsi otomatisasi Anda. Konkurensi dibatasi dengan mengatur variabel maxConcurrentRequests dalam file host.json. Pengaturan ini membatasi jumlah contoh fungsi bersamaan yang berjalan di aplikasi fungsi Anda. Karena setiap contoh mengkonsumsi CPU dan memori, nilai ini perlu disesuaikan untuk operasi intensif CPU. Turunkan maxConcurrentRequests jika panggilan fungsi Anda tampak terlalu lambat atau tidak dapat diselesaikan. Lihat bagian Mengonfigurasi perilaku host untuk menangani konkurensi dengan lebih baik untuk detail selengkapnya.

Idempotensi

Pastikan fungsi otomatisasi Anda adalah idempotent. Baik Azure Monitor dan Event Grid dapat memancarkan peringatan atau peristiwa yang menunjukkan perkembangan seperti peristiwa langganan Anda diselesaikan, dipecat, sedang berlangsung, dll., Sumber daya Anda sedang disediakan, dibuat dengan sukses, dll., Atau bahkan mengirim peringatan palsu karena kesalahan konfigurasi. Pastikan fungsi Anda hanya bertindak berdasarkan peringatan dan peristiwa yang relevan, dan abaikan semua yang lain, sehingga peristiwa yang salah atau salah dikonfigurasi tidak menyebabkan hasil yang tidak diinginkan. Untuk informasi selengkapnya, lihat Merancang Azure Functions untuk input yang identik.

Event Grid

Jika alur kerja Anda menggunakan Kisi Peristiwa, periksa apakah skenario Anda dapat menghasilkan volume peristiwa yang tinggi, cukup untuk menyumbat kisi. Lihat Pengiriman pesan Event Grid dan coba lagi untuk memahami cara menangani peristiwa saat pengiriman tidak diakui, dan ubah logika Anda sesuai dengan itu. Alur kerja pusat biaya tidak menerapkan pemeriksaan tambahan untuk ini, karena hanya mengawasi acara pembuatan sumber daya dalam grup sumber daya. Memantau sumber daya yang dibuat dalam seluruh langganan, dapat menghasilkan jumlah peristiwa yang lebih besar, membutuhkan penanganan yang lebih tangguh.

Azure Monitor

Jika sejumlah besar peringatan dihasilkan, dan otomatisasi memperbarui sumber daya Azure, batas pelambatan Azure Resource Manager dapat dicapai. Hal ini dapat berdampak negatif pada sisa infrastruktur dalam langganan tersebut. Hindari situasi ini dengan membatasi frekuensi peringatan yang dihasilkan oleh Azure Monitor. Anda juga dapat membatasi peringatan yang dihasilkan untuk kesalahan tertentu. Lihat dokumentasi tentang peringatan Azure Monitor untuk informasi selengkapnya.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Mengontrol akses ke fungsi

Batasi akses ke fungsi yang dipicu HTTP dengan mengatur tingkat otorisasi. Dengan autentikasi anonim, fungsi ini mudah diakses dengan URL seperti http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. Autentikasi tingkat fungsi dapat mengaburkan titik akhir http, dengan memerlukan tombol fungsi di URL. Tingkat ini diatur dalam file function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

Untuk lingkungan produksi, strategi tambahan mungkin diperlukan untuk mengamankan fungsi. Dalam skenario ini, fungsi dijalankan dalam platform Azure oleh layanan Azure lainnya, dan tidak akan terkena Internet. Otorisasi fungsi terkadang cukup untuk fungsi yang diakses sebagai kait web.

Pertimbangkan untuk menambahkan lapisan keamanan di atas autentikasi fungsi, seperti,

• autentikasi dengan sertifikat klien, atau
• memastikan penelepon adalah bagian dari atau memiliki akses ke direktori yang menyelenggarakan fungsi tersebut, dengan mengaktifkan App Service Authentication.

Autentikasi tingkat fungsi adalah satu-satunya opsi yang tersedia untuk grup tindakan Azure Monitor menggunakan Azure Functions.

Jika fungsi perlu dipanggil dari aplikasi atau layanan pihak ketiga, disarankan untuk menyediakan akses ke sana dengan lapisan API Management. Lapisan ini harus memberlakukan autentikasi. API Management memiliki tingkat konsumsi yang terintegrasi dengan Azure Functions, yang memungkinkan Anda membayar hanya jika API dijalankan. Untuk informasi selengkapnya, baca Buat dan ungkapkan fungsi Anda dengan OpenAPI.

Jika layanan panggilan mendukung titik akhir layanan atau tautan pribadi, opsi yang lebih mahal berikut dapat dipertimbangkan:

• Gunakan paket App Service khusus, di mana Anda dapat mengunci fungsi dalam jaringan virtual untuk membatasi akses ke sana. Ini tidak mungkin dalam model tanpa server berbasis konsumsi.
• Gunakan paket Azure Functions Premium, yang mencakup jaringan virtual khusus untuk digunakan oleh aplikasi fungsi Anda.

Untuk membandingkan harga dan fitur antara opsi ini, baca skala dan penyelenggara Azure Functions.

Kontrol apa yang dapat diakses oleh fungsi

Identitas terkelola untuk sumber daya Azure, fitur Microsoft Entra, menyederhanakan cara fungsi mengautentikasi dan mengakses sumber daya dan layanan Azure lainnya. Kode tidak perlu mengelola kredensial autentikasi, karena dikelola oleh ID Microsoft Entra.

Ada dua jenis identitas terkelola:

• Identitas terkelola yang ditetapkan sistem: Ini dibuat sebagai bagian dari sumber daya Azure, dan tidak dapat dibagikan di antara beberapa sumber daya. Ini bisa dihapus ketika sumber daya dihapus. Gunakan ini untuk skenario, yang melibatkan sumber daya Azure tunggal atau yang membutuhkan identitas independen. Kedua skenario menggunakan identitas yang ditetapkan sistem karena mereka hanya memperbarui satu sumber daya. Identitas terkelola hanya diperlukan untuk memperbarui sumber daya lain. Misalnya, fungsi dapat membaca tag sumber daya tanpa identitas terkelola. Lihat petunjuk ini untuk menambahkan identitas yang ditetapkan sistem ke fungsi Anda.

• Identitas terkelola yang ditetapkan pengguna: Ini dibuat sebagai sumber daya Azure yang berdiri sendiri. Ini dapat dibagikan di berbagai sumber daya, dan perlu dihapus secara eksplisit ketika tidak lagi diperlukan. Baca petunjuk ini tentang cara menambahkan identitas yang ditetapkan pengguna ke fungsi Anda. Gunakan ini untuk skenario yang:

  • Memerlukan akses ke beberapa sumber daya yang dapat berbagi satu identitas, atau
  • Perlu pra-otorisasi untuk mengamankan sumber daya selama penyediaan, atau
  • Memiliki sumber daya yang sering didaur ulang, sementara izin harus konsisten.

Setelah identitas ditetapkan ke fungsi Azure, tetapkan peran menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk mengakses sumber daya. Misalnya, untuk memperbarui sumber daya, peran Kontributor perlu ditetapkan ke identitas fungsi.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Berikut ini adalah beberapa pertimbangan untuk menurunkan biaya.

Azure Logic Apps

Aplikasi logika memiliki model harga bayar sesuai pilihan. Pemicu, tindakan, dan eksekusi konektor diukur setiap kali aplikasi logika berjalan. Semua tindakan yang berhasil dan tidak berhasil, termasuk pemicu, dianggap sebagai eksekusi.

Aplikasi logika juga memiliki model harga tetap. Jika Anda perlu menjalankan aplikasi logika yang berkomunikasi dengan sumber daya aman di jaringan virtual Azure, Anda dapat membuatnya di Lingkungan Layanan Integrasi (ISE).

Untuk mengetahui detailnya, lihat Model harga untuk Azure Logic Apps.

Dalam arsitektur ini, aplikasi logika digunakan dalam skenario penandaan pusat biaya untuk mengatur alur kerja.

Konektor bawaan digunakan untuk menyambungkan ke Azure Functions dan mengirim pemberitahuan email saat tugas otomatisasi selesai. Fungsinya diekspos sebagai web hook / API menggunakan pemicu HTTP. Aplikasi logika dipicu hanya saat permintaan HTTPS terjadi. Ini adalah cara yang hemat biaya bila dibandingkan dengan desain di mana fungsi terus-menerus jajak pendapat dan memeriksa kriteria tertentu. Setiap permintaan pemungutan suara diukur sebagai tindakan.

Untuk informasi selengkapnya, lihat Harga Logic Apps.

Azure Functions

Azure Functions tersedia dengan tiga paket harga berikut.

• Paket konsumsi. Ini adalah paket tanpa server yang paling hemat biaya yang tersedia, di mana Anda hanya membayar untuk saat fungsi Anda berjalan. Di bawah rencana ini, fungsi dapat berjalan hingga 10 menit sekaligus.

• Paket premium. Pertimbangkan untuk menggunakan Azure Functions Premium merencanakan skenario otomatisasi dengan persyaratan tambahan, seperti jaringan virtual khusus, durasi eksekusi yang lebih lama, dan sebagainya. Fungsi-fungsi ini dapat berjalan hingga satu jam, dan harus dipilih untuk tugas otomatisasi yang lebih lama seperti menjalankan pencadangan, pengindeksan basis data, atau menghasilkan laporan.

• Paket Azure App Service. Skenario otomatisasi hibrid yang menggunakan Koneksi Hibrida Azure App Service, harus menggunakan paket Layanan Aplikasi. Fungsi yang dibuat di bawah paket ini dapat berjalan untuk durasi tak terbatas, mirip dengan aplikasi web.

Dalam skenario otomatisasi ini, Azure Functions digunakan untuk tugas seperti memperbarui tag di ID Microsoft Entra, atau mengubah konfigurasi Azure Cosmos DB dengan meningkatkan RU ke nilai yang lebih tinggi. Rencana Konsumsi adalah yang sesuai untuk kasus penggunaan ini karena tugas-tugas itu interaktif dan tidak berjalan lama.

Azure Cosmos DB

Tagihan Azure Cosmos DB untuk throughput yang tersedia dan penyimpanan yang dikonsumsi per jam. Throughput yang tersedia dinyatakan dalam Request Unit per detik (RU/dtk), yang dapat digunakan untuk operasi database biasa, seperti penyisipan, pembacaan. Penyimpanan ditagih untuk setiap GB yang digunakan untuk data dan indeks yang Anda simpan. Lihat Model harga Azure Cosmos DB untuk informasi selengkapnya.

Dalam arsitektur ini, ketika permintaan akses data ke Azure Cosmos DB melebihi kapasitas di Unit Permintaan (atau RU), Azure Monitor memicu pemberitahuan. Grup tindakan Azure Monitor dikonfigurasi untuk memanggil fungsi otomatisasi sebagai respons terhadap peringatan ini. Fungsi ini membandingkan RUs ke nilai yang lebih tinggi. Ini membantu menjaga biaya turun karena Anda hanya membayar sumber daya yang dibutuhkan beban kerja Anda per jam.

Untuk mendapatkan perkiraan biaya cepat beban kerja Anda, gunakan kalkulator kapasitas Azure Cosmos DB.

Untuk informasi selengkapnya, lihat bagian Biaya di Microsoft Azure Well-Architected Framework.

Pertimbangan penyebaran

Untuk alur kerja otomatisasi kritis yang mengelola perilaku aplikasi Anda, penerapan waktu henti nol harus dicapai menggunakan saluran DevOps yang efisien. Untuk informasi selengkapnya, baca penerapan backend tanpa server.

Jika otomatisasi mencakup beberapa aplikasi, simpan sumber daya yang dibutuhkan oleh otomatisasi dalam grup sumber daya terpisah. Satu kelompok sumber daya dapat dibagi antara otomatisasi dan sumber daya aplikasi, jika otomatisasi mencakup satu aplikasi.

Jika alur kerja melibatkan sejumlah fungsi otomatisasi, kelompokkan fungsi yang melayani satu skenario dalam satu aplikasi fungsi. Baca Kelola aplikasi fungsi untuk informasi selengkapnya.

Saat Anda menyebarkan aplikasi Anda, Anda harus memantaunya. Pertimbangkan untuk menggunakan Application Insights guna memungkinkan pengembang memantau performa dan mendeteksi masalah.

Untuk informasi selengkapnya, lihat bagian DevOps di Microsoft Azure Well-Architected Framework.

Tindakan imperatif pada sumber daya Azure

Dalam kedua skenario di atas, hasil akhirnya adalah perubahan status sumber daya Azure melalui interaksi Azure Resource Manager langsung. Meskipun ini adalah hasil yang diinginkan, pertimbangkan dampaknya terhadap lingkungan Anda jika sumber daya yang dimodifikasi awalnya digunakan secara deklaratif, seperti oleh templat Bicep atau Terraform. Kecuali perubahan tersebut direplikasi kembali ke template sumber Anda, penggunaan berikutnya dari template tersebut dapat membatalkan perubahan yang dibuat oleh otomatisasi ini. Pertimbangkan dampak pencampuran perubahan penting pada sumber daya Azure yang secara rutin diterapkan melalui templat.

Menyebarkan skenario ini

Untuk menerapkan skenario pusat biaya, lihat langkah-langkah penerapan di GitHub.

Langkah berikutnya

• Pelatihan: Pengantar Azure Functions
• Dokumentasi: Pengantar Azure Functions
• Apa itu Azure Event Grid?

Sumber daya terkait

• Panduan kode: Aplikasi tanpa server dengan Functions
• Desain arsitektur fungsi tanpa server
• Arsitektur referensi fungsi tanpa server