Memigrasikan aplikasi web dengan menggunakan Azure API Management

Azure API Management

Azure Monitor

Azure App Service

Dalam skenario ini, perusahaan e-niaga di industri perjalanan memigrasikan aplikasi web warisan dengan menggunakan Azure API Management. Perusahaan menghosting UI baru sebagai aplikasi platform as a service (PaaS) di Azure. UI baru bergantung pada API HTTP yang sudah ada dan baru. API ini disebarkan dengan antarmuka yang dirancang lebih efektif yang meningkatkan performa, menyederhanakan integrasi, dan memungkinkan ekstensibilitas di masa mendatang.

Architecture

Diagram menunjukkan alur antara sistem lokal, internet, dan layanan Azure. Di sebelah kiri, dalam kotak berlabel lokal, ikon bola dunia mewakili layanan HTTP dan API yang ada. Dalam kotak yang sama, ikon jendela browser mewakili UI web berbasis browser yang ada. Panah dua arah yang menyambungkan ikon ini menunjukkan komunikasi antara UI web berbasis browser yang ada dan layanan HTTP dan API yang ada. Ikon bangunan mewakili pusat data lokal. Di sebelah kanan, dalam kotak berlabel Azure, ikon cloud mewakili instans API Management. Panah dua arah yang melewati ikon kunci menyambungkan ikon ini dan layanan dan API HTTPS lokal yang ada. Kotak Azure juga berisi ikon API baru dan ikon bola dunia yang mewakili antarmuka pengguna web berbasis browser baru. Panah dua arah yang melewati ikon kunci menghubungkan instans API Management dan API baru. Panah dua arah lainnya menghubungkan instans API Management dan UI web berbasis browser baru. Antara kotak lokal dan kotak Azure, ikon cloud mewakili internet. Panah yang melewati ikon kunci menunjuk dari ikon pengguna e-commerce ke UI web berbasis browser yang ada dan ke UI web berbasis browser yang baru.

Unduh arsitektur ini dalam bentuk file Visio.

Workflow

Alur kerja berikut ini sesuai dengan diagram sebelumnya:

1. Aplikasi web lokal yang ada terus secara langsung menggunakan layanan web lokal yang ada.

2. Panggilan dari aplikasi web yang ada ke layanan HTTP yang ada tetap tidak berubah. Panggilan ini bersifat internal untuk jaringan perusahaan.

3. API Management melakukan panggilan dari Azure ke layanan internal yang ada.

   • Tim keamanan memungkinkan lalu lintas dari instans API Management untuk melewati firewall perusahaan ke layanan lokal yang ada dengan menggunakan protokol transportasi aman seperti Hypertext Transfer Protocol Secure (HTTPS) melalui Keamanan Lapisan Transportasi (TLS).

   • Tim operasi memungkinkan panggilan masuk ke layanan hanya dari instans API Management. Ini memenuhi persyaratan ini dengan menambahkan alamat IP instans API Management ke daftar izinkan dalam perimeter jaringan perusahaan.

   • Modul baru dalam alur permintaan lokal untuk layanan Hypertext Transfer Protocol (HTTP) hanya bertindak pada koneksi yang berasal dari eksternal. Alur memvalidasi sertifikat yang disediakan API Management.

4. API baru memiliki karakteristik berikut:

   • Hanya instans API Management, yang menyediakan fasad API, yang menampilkan API baru. Anda tidak langsung mengakses API baru.

   • Anda mengembangkan dan menerbitkan API baru sebagai aplikasi API web Azure PaaS.

   • Anda menyiapkan API baru dengan menggunakan pengaturan fitur Web Apps pada Azure App Service agar hanya menerima IP virtual (VIP) dari API Management.

   • Web Apps menghosting API baru dengan protokol transportasi aman seperti HTTPS atau TLS diaktifkan.

   • Azure App Service menyediakan kemampuan otorisasi melalui MICROSOFT Entra ID dan Open Authorization (OAuth) 2.

5. Aplikasi web berbasis browser baru bergantung pada instans API Management untuk API HTTP yang ada dan API baru.

6. Perusahaan e-niaga perjalanan dapat mengarahkan beberapa pengguna ke UI baru untuk pratinjau atau pengujian sambil mempertahankan UI lama dan fungsionalitas yang ada secara berdampingan.

Siapkan instans API Management untuk memetakan layanan HTTP warisan ke kontrak API baru. Dalam konfigurasi ini, UI web baru tidak menyadari integrasi dengan serangkaian layanan warisan atau API dan API baru.

Di masa depan, tim proyek dapat secara bertahap memindahkan fungsionalitas ke API baru dan menghentikan layanan asli. Tim menangani perubahan ini dalam konfigurasi API Management, membiarkan UI front-end tidak terpengaruh dan menghindari pekerjaan pembangunan ulang.

Components

• API Management adalah platform manajemen dan gateway untuk API di semua lingkungan. Dalam arsitektur ini, ia berfungsi sebagai fasad untuk API warisan yang ada dan API baru. Aplikasi klien baru menggunakan satu antarmuka yang konsisten, dan tim dapat memodernisasi sistem lama secara bertahap di balik antarmuka tersebut dengan dampak minimal pada pengembangan front-end.

• App Service adalah solusi PaaS turnkey untuk hosting web yang menyediakan fitur siap pakai seperti keamanan, penyeimbangan beban, penskalaan otomatis, dan manajemen otomatis. Dalam arsitektur ini, App Service menyediakan hosting turnkey yang fleksibel sehingga tim DevOps dapat fokus pada pengiriman fitur.

Alternatives

• Jika organisasi berencana untuk memindahkan infrastrukturnya, termasuk komputer virtual (VM) yang menghosting aplikasi warisan, sepenuhnya ke Azure, API Management dapat berfungsi sebagai fasad untuk titik akhir HTTP yang dapat diatasi.

• Jika organisasi menjaga titik akhir yang ada tetap privat dan tidak mengeksposnya secara publik, instans API Management organisasi dapat menautkan ke jaringan virtual Azure.

  • Saat API Management ditautkan ke jaringan virtual Azure, organisasi dapat langsung mengatasi layanan back-end melalui alamat IP privat.

  • Dalam skenario lokal, instans API Management dapat terhubung ke layanan internal secara privat melalui Azure VPN Gateway dan koneksi VPN Internet Protocol Security (IPsec) situs-ke-situs atau Azure ExpressRoute. Skenario ini kemudian menjadi hibrid Azure dan lokal.

• Organisasi dapat menjaga instans API Management tetap privat dengan menyebarkannya dalam mode internal. Organisasi kemudian dapat menggunakan penyebaran dengan Azure Application Gateway untuk memungkinkan akses publik untuk beberapa API sementara yang lain tetap internal. Untuk informasi selengkapnya, lihat Mengintegrasikan API Management di jaringan virtual internal dengan menggunakan Application Gateway.

• Organisasi mungkin memutuskan untuk menghosting API lokalnya. Salah satu alasan untuk perubahan ini mungkin karena organisasi tidak dapat memindahkan dependensi database hilir yang berada dalam cakupan untuk proyek ini ke cloud. Dalam skenario ini, organisasi dapat memanfaatkan API Management secara lokal dengan menggunakan gateway yang dihost sendiri.

  Gateway yang di-host sendiri adalah penyebaran ter-kontainer dari gateway API Management yang terhubung ke Azure melalui soket keluar. Untuk menggunakan gateway yang dihost sendiri, Anda harus memenuhi prasyarat berikut:

  • Anda harus menyebarkan gateway yang dihost sendiri dengan menggunakan sumber daya induk di Azure, yang menambahkan biaya tambahan.

  • Anda harus menggunakan tingkat Premium API Management.

Detail skenario

Perusahaan e-niaga di industri perjalanan ingin memodernisasi tumpukan perangkat lunak berbasis browser warisannya. Tumpukan yang ada sebagian besar monolitik, tetapi beberapa layanan HTTP berbasis Simple Object Access Protocol (SOAP) ada dari proyek terbaru. Perusahaan mempertimbangkan pembuatan aliran pendapatan tambahan untuk memonetisasi beberapa kekayaan intelektual internalnya.

Tujuan untuk proyek ini termasuk mengatasi utang teknis, perbaikan pemeliharaan yang sedang berlangsung, dan akselerasi pengembangan fitur dengan lebih sedikit bug regresi. Proyek ini menggunakan proses berulang untuk menghindari risiko dan melakukan langkah-langkah berikut secara paralel:

• Tim pengembangan memodernisasi back end aplikasi, yang terdiri dari database relasional yang dihosting di VM.

• Tim pengembangan internal menulis fungsionalitas bisnis baru dan mengeksposnya melalui API HTTP baru.

• Tim pengembangan kontrak membangun UI berbasis browser baru, yang dihosting Azure.

Perusahaan ini memberikan fitur aplikasi baru secara bertahap. Fitur-fitur ini secara bertahap menggantikan fungsionalitas UI klien dan server berbasis browser yang ada yang dihosting secara lokal yang mendukung bisnis e-niaga perusahaan.

Anggota tim manajemen tidak ingin memodernisasi secara tidak perlu. Mereka juga ingin mempertahankan kontrol cakupan dan biaya. Untuk mencapai tujuan ini, mereka memutuskan untuk mempertahankan layanan HTTP SOAP yang ada. Mereka juga bermaksud untuk meminimalkan perubahan pada UI yang ada. Mereka dapat menggunakan API Management untuk mengatasi banyak persyaratan dan batasan proyek.

Kemungkinan kasus penggunaan

Skenario ini menyoroti cara memodernisasi tumpukan perangkat lunak berbasis browser warisan.

Anda dapat menggunakan skenario ini untuk tugas-tugas berikut:

• Lihat bagaimana bisnis Anda dapat memperoleh manfaat dari menggunakan ekosistem Azure.
• Merencanakan migrasi layanan ke Azure.
• Pelajari bagaimana pergeseran ke Azure mungkin memengaruhi API yang ada.

Considerations

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

Reliability

Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

• Aktifkan zona ketersediaan saat Anda menyebarkan instans API Management Anda. Opsi untuk menyebarkan API Management ke zona ketersediaan hanya tersedia di tingkat layanan Premium.

• Gunakan zona ketersediaan yang memiliki instans gateway tambahan yang disebarkan ke berbagai wilayah. Kombinasi ini meningkatkan ketersediaan layanan jika satu wilayah offline. Penyebaran multiregion hanya tersedia di tingkat layanan Premium.

• Integrasikan dengan Application Insights, yang menampilkan metrik melalui Azure Monitor untuk pemantauan. Misalnya, Anda dapat menggunakan metrik kapasitas untuk menentukan beban keseluruhan pada sumber daya API Management dan apakah Anda memerlukan lebih banyak unit peluasan skala. Lacak kapasitas dan kesehatan sumber daya untuk meningkatkan keandalan.

• Pastikan bahwa dependensi hilir, seperti layanan back-end yang menghosting API yang dicakup API Management, juga tangguh.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

API Management memiliki delapan tingkatan:

• Konsumsi
• Pengembang
• Dasar dan Dasar v2
• Standar dan Standar Versi 2
• Premium dan Premium v2

Untuk informasi selengkapnya tentang perbedaan tingkatan ini, lihat harga API Management.

Anda dapat menskalakan API Management dengan menambahkan dan menghapus unit. Setiap unit memiliki kapasitas yang tergantung pada tingkatannya.

Note

Anda dapat menggunakan tingkat Pengembang untuk mengevaluasi fitur API Management. Jangan gunakan untuk produksi.

Untuk melihat biaya yang diproyeksikan untuk kebutuhan penyebaran Anda, Anda dapat memodifikasi jumlah unit skala dan instans App Service di kalkulator harga Azure.

Contributors

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Ben Gimblett | Insinyur Pelanggan Senior

Kontributor lainnya:

• Andrew Cardy | Insinyur Perangkat Lunak Senior

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah selanjutnya

• Ikhtisar Layanan Aplikasi
• Gambaran umum API Management
• Menyiapkan lingkungan penahapan di App Service
• Mengubah dan melindungi API Anda
• Menjelajahi App Service

Sumber daya terkait

• Merancang pengalaman pengembang API yang hebat dengan menggunakan API Management dan GitHub

Dalam skenario ini, perusahaan e-niaga di industri perjalanan memigrasikan aplikasi web warisan dengan menggunakan Azure API Management. Perusahaan menghosting UI baru sebagai aplikasi platform as a service (PaaS) di Azure. UI baru bergantung pada API HTTP yang sudah ada dan baru. API ini disebarkan dengan antarmuka yang dirancang lebih efektif yang meningkatkan performa, menyederhanakan integrasi, dan memungkinkan ekstensibilitas di masa mendatang.

Architecture

Diagram menunjukkan alur antara sistem lokal, internet, dan layanan Azure. Di sebelah kiri, dalam kotak berlabel lokal, ikon bola dunia mewakili layanan HTTP dan API yang ada. Dalam kotak yang sama, ikon jendela browser mewakili UI web berbasis browser yang ada. Panah dua arah yang menyambungkan ikon ini menunjukkan komunikasi antara UI web berbasis browser yang ada dan layanan HTTP dan API yang ada. Ikon bangunan mewakili pusat data lokal. Di sebelah kanan, dalam kotak berlabel Azure, ikon cloud mewakili instans API Management. Panah dua arah yang melewati ikon kunci menyambungkan ikon ini dan layanan dan API HTTPS lokal yang ada. Kotak Azure juga berisi ikon API baru dan ikon bola dunia yang mewakili antarmuka pengguna web berbasis browser baru. Panah dua arah yang melewati ikon kunci menghubungkan instans API Management dan API baru. Panah dua arah lainnya menghubungkan instans API Management dan UI web berbasis browser baru. Antara kotak lokal dan kotak Azure, ikon cloud mewakili internet. Panah yang melewati ikon kunci menunjuk dari ikon pengguna e-commerce ke UI web berbasis browser yang ada dan ke UI web berbasis browser yang baru.

Unduh arsitektur ini dalam bentuk file Visio.

Workflow

Alur kerja berikut ini sesuai dengan diagram sebelumnya:

1. Aplikasi web lokal yang ada terus secara langsung menggunakan layanan web lokal yang ada.

2. Panggilan dari aplikasi web yang ada ke layanan HTTP yang ada tetap tidak berubah. Panggilan ini bersifat internal untuk jaringan perusahaan.

3. API Management melakukan panggilan dari Azure ke layanan internal yang ada.

   • Tim keamanan memungkinkan lalu lintas dari instans API Management untuk melewati firewall perusahaan ke layanan lokal yang ada dengan menggunakan protokol transportasi aman seperti Hypertext Transfer Protocol Secure (HTTPS) melalui Keamanan Lapisan Transportasi (TLS).

   • Tim operasi memungkinkan panggilan masuk ke layanan hanya dari instans API Management. Ini memenuhi persyaratan ini dengan menambahkan alamat IP instans API Management ke daftar izinkan dalam perimeter jaringan perusahaan.

   • Modul baru dalam alur permintaan lokal untuk layanan Hypertext Transfer Protocol (HTTP) hanya bertindak pada koneksi yang berasal dari eksternal. Alur memvalidasi sertifikat yang disediakan API Management.

4. API baru memiliki karakteristik berikut:

   • Hanya instans API Management, yang menyediakan fasad API, yang menampilkan API baru. Anda tidak langsung mengakses API baru.

   • Anda mengembangkan dan menerbitkan API baru sebagai aplikasi API web Azure PaaS.

   • Anda menyiapkan API baru dengan menggunakan pengaturan fitur Web Apps pada Azure App Service agar hanya menerima IP virtual (VIP) dari API Management.

   • Web Apps menghosting API baru dengan protokol transportasi aman seperti HTTPS atau TLS diaktifkan.

   • Azure App Service menyediakan kemampuan otorisasi melalui MICROSOFT Entra ID dan Open Authorization (OAuth) 2.

5. Aplikasi web berbasis browser baru bergantung pada instans API Management untuk API HTTP yang ada dan API baru.

6. Perusahaan e-niaga perjalanan dapat mengarahkan beberapa pengguna ke UI baru untuk pratinjau atau pengujian sambil mempertahankan UI lama dan fungsionalitas yang ada secara berdampingan.

Siapkan instans API Management untuk memetakan layanan HTTP warisan ke kontrak API baru. Dalam konfigurasi ini, UI web baru tidak menyadari integrasi dengan serangkaian layanan warisan atau API dan API baru.

Di masa depan, tim proyek dapat secara bertahap memindahkan fungsionalitas ke API baru dan menghentikan layanan asli. Tim menangani perubahan ini dalam konfigurasi API Management, membiarkan UI front-end tidak terpengaruh dan menghindari pekerjaan pembangunan ulang.

Components

• API Management adalah platform manajemen dan gateway untuk API di semua lingkungan. Dalam arsitektur ini, ia berfungsi sebagai fasad untuk API warisan yang ada dan API baru. Aplikasi klien baru menggunakan satu antarmuka yang konsisten, dan tim dapat memodernisasi sistem lama secara bertahap di balik antarmuka tersebut dengan dampak minimal pada pengembangan front-end.

• App Service adalah solusi PaaS turnkey untuk hosting web yang menyediakan fitur siap pakai seperti keamanan, penyeimbangan beban, penskalaan otomatis, dan manajemen otomatis. Dalam arsitektur ini, App Service menyediakan hosting turnkey yang fleksibel sehingga tim DevOps dapat fokus pada pengiriman fitur.

Alternatives

• Jika organisasi berencana untuk memindahkan infrastrukturnya, termasuk komputer virtual (VM) yang menghosting aplikasi warisan, sepenuhnya ke Azure, API Management dapat berfungsi sebagai fasad untuk titik akhir HTTP yang dapat diatasi.

• Jika organisasi menjaga titik akhir yang ada tetap privat dan tidak mengeksposnya secara publik, instans API Management organisasi dapat menautkan ke jaringan virtual Azure.

  • Saat API Management ditautkan ke jaringan virtual Azure, organisasi dapat langsung mengatasi layanan back-end melalui alamat IP privat.

  • Dalam skenario lokal, instans API Management dapat terhubung ke layanan internal secara privat melalui Azure VPN Gateway dan koneksi VPN Internet Protocol Security (IPsec) situs-ke-situs atau Azure ExpressRoute. Skenario ini kemudian menjadi hibrid Azure dan lokal.

• Organisasi dapat menjaga instans API Management tetap privat dengan menyebarkannya dalam mode internal. Organisasi kemudian dapat menggunakan penyebaran dengan Azure Application Gateway untuk memungkinkan akses publik untuk beberapa API sementara yang lain tetap internal. Untuk informasi selengkapnya, lihat Mengintegrasikan API Management di jaringan virtual internal dengan menggunakan Application Gateway.

• Organisasi mungkin memutuskan untuk menghosting API lokalnya. Salah satu alasan untuk perubahan ini mungkin karena organisasi tidak dapat memindahkan dependensi database hilir yang berada dalam cakupan untuk proyek ini ke cloud. Dalam skenario ini, organisasi dapat memanfaatkan API Management secara lokal dengan menggunakan gateway yang dihost sendiri.

  Gateway yang di-host sendiri adalah penyebaran ter-kontainer dari gateway API Management yang terhubung ke Azure melalui soket keluar. Untuk menggunakan gateway yang dihost sendiri, Anda harus memenuhi prasyarat berikut:

  • Anda harus menyebarkan gateway yang dihost sendiri dengan menggunakan sumber daya induk di Azure, yang menambahkan biaya tambahan.

  • Anda harus menggunakan tingkat Premium API Management.

Detail skenario

Perusahaan e-niaga di industri perjalanan ingin memodernisasi tumpukan perangkat lunak berbasis browser warisannya. Tumpukan yang ada sebagian besar monolitik, tetapi beberapa layanan HTTP berbasis Simple Object Access Protocol (SOAP) ada dari proyek terbaru. Perusahaan mempertimbangkan pembuatan aliran pendapatan tambahan untuk memonetisasi beberapa kekayaan intelektual internalnya.

Tujuan untuk proyek ini termasuk mengatasi utang teknis, perbaikan pemeliharaan yang sedang berlangsung, dan akselerasi pengembangan fitur dengan lebih sedikit bug regresi. Proyek ini menggunakan proses berulang untuk menghindari risiko dan melakukan langkah-langkah berikut secara paralel:

• Tim pengembangan memodernisasi back end aplikasi, yang terdiri dari database relasional yang dihosting di VM.

• Tim pengembangan internal menulis fungsionalitas bisnis baru dan mengeksposnya melalui API HTTP baru.

• Tim pengembangan kontrak membangun UI berbasis browser baru, yang dihosting Azure.

Perusahaan ini memberikan fitur aplikasi baru secara bertahap. Fitur-fitur ini secara bertahap menggantikan fungsionalitas UI klien dan server berbasis browser yang ada yang dihosting secara lokal yang mendukung bisnis e-niaga perusahaan.

Anggota tim manajemen tidak ingin memodernisasi secara tidak perlu. Mereka juga ingin mempertahankan kontrol cakupan dan biaya. Untuk mencapai tujuan ini, mereka memutuskan untuk mempertahankan layanan HTTP SOAP yang ada. Mereka juga bermaksud untuk meminimalkan perubahan pada UI yang ada. Mereka dapat menggunakan API Management untuk mengatasi banyak persyaratan dan batasan proyek.

Kemungkinan kasus penggunaan

Skenario ini menyoroti cara memodernisasi tumpukan perangkat lunak berbasis browser warisan.

Anda dapat menggunakan skenario ini untuk tugas-tugas berikut:

• Lihat bagaimana bisnis Anda dapat memperoleh manfaat dari menggunakan ekosistem Azure.
• Merencanakan migrasi layanan ke Azure.
• Pelajari bagaimana pergeseran ke Azure mungkin memengaruhi API yang ada.

Considerations

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

Reliability

Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

• Aktifkan zona ketersediaan saat Anda menyebarkan instans API Management Anda. Opsi untuk menyebarkan API Management ke zona ketersediaan hanya tersedia di tingkat layanan Premium.

• Gunakan zona ketersediaan yang memiliki instans gateway tambahan yang disebarkan ke berbagai wilayah. Kombinasi ini meningkatkan ketersediaan layanan jika satu wilayah offline. Penyebaran multiregion hanya tersedia di tingkat layanan Premium.

• Integrasikan dengan Application Insights, yang menampilkan metrik melalui Azure Monitor untuk pemantauan. Misalnya, Anda dapat menggunakan metrik kapasitas untuk menentukan beban keseluruhan pada sumber daya API Management dan apakah Anda memerlukan lebih banyak unit peluasan skala. Lacak kapasitas dan kesehatan sumber daya untuk meningkatkan keandalan.

• Pastikan bahwa dependensi hilir, seperti layanan back-end yang menghosting API yang dicakup API Management, juga tangguh.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

API Management memiliki delapan tingkatan:

• Konsumsi
• Pengembang
• Dasar dan Dasar v2
• Standar dan Standar Versi 2
• Premium dan Premium v2

Untuk informasi selengkapnya tentang perbedaan tingkatan ini, lihat harga API Management.

Anda dapat menskalakan API Management dengan menambahkan dan menghapus unit. Setiap unit memiliki kapasitas yang tergantung pada tingkatannya.

Note

Anda dapat menggunakan tingkat Pengembang untuk mengevaluasi fitur API Management. Jangan gunakan untuk produksi.

Untuk melihat biaya yang diproyeksikan untuk kebutuhan penyebaran Anda, Anda dapat memodifikasi jumlah unit skala dan instans App Service di kalkulator harga Azure.

Contributors

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Ben Gimblett | Insinyur Pelanggan Senior

Kontributor lainnya:

• Andrew Cardy | Insinyur Perangkat Lunak Senior

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah selanjutnya

• Ikhtisar Layanan Aplikasi
• Gambaran umum API Management
• Menyiapkan lingkungan penahapan di App Service
• Mengubah dan melindungi API Anda
• Menjelajahi App Service

Sumber daya terkait

• Merancang pengalaman pengembang API yang hebat dengan menggunakan API Management dan GitHub