Edit

Bagikan melalui

Memigrasikan aplikasi web dengan menggunakan Azure API Management

Azure API Management
Azure Monitor
Azure App Service

Dalam skenario ini, perusahaan e-commerce di industri perjalanan memigrasikan aplikasi web lama dengan menggunakan Azure API Management. UI baru akan dihosting sebagai aplikasi platform as a service (PaaS) di Azure, dan itu akan bergantung pada API HTTP yang ada dan baru. API ini akan dikirim dengan serangkaian antarmuka yang dirancang dengan lebih baik, yang akan memungkinkan performa yang lebih baik, integrasi yang lebih mudah, dan ekstensibilitas di masa depan.

Sistem

Diagram arsitektur

Unduh file Visio arsitektur ini.

Alur kerja

  1. Aplikasi web lokal yang ada terus 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. Panggilan masuk dilakukan dari Azure ke layanan internal yang ada:
  4. API baru:
  5. Aplikasi web berbasis browser baru bergantung pada instans Azure API Management untuk API HTTP yang ada dan API baru.
  6. Perusahaan e-niaga perjalanan sekarang dapat mengarahkan beberapa pengguna ke UI baru (untuk pratinjau atau pengujian) sambil mempertahankan UI lama dan fungsionalitas yang ada secara berdampingan.

Instans API Management dikonfigurasi untuk memetakan layanan HTTP warisan ke kontrak API baru. Dalam konfigurasi ini, UI Web baru tidak menyadari integrasi dengan sekumpulan layanan/API warisan dan API baru.

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

Komponen

  • Azure API Management mengabstraksi API backend serta menambahkan fungsionalitas pemotongan silang dan penemuan untuk pengembang dan aplikasi. Dalam skenario ini, rekomposisi API backend warisan yang ada dan penambahan fungsionalitas API baru dimungkinkan dengan menggunakan API Management sebagai fasad bagi aplikasi klien baru untuk dikonsumsi secara konsisten dan menggunakan standar modern. Karena API Management fasad baik API yang ada maupun baru, pengembang dapat memodernisasi backend warisan di belakang fasad API Management dengan cara berulang dan dengan dampak minimal hingga nol pada pengembangan ujung depan baru.
  • Azure App Service adalah layanan Platform as a Service (PaaS) turn-key untuk hosting web yang menyediakan fitur out of the box seperti keamanan, penyeimbangan beban, penskalaan otomatis, dan manajemen otomatis. Azure App Service adalah pilihan yang bagus untuk API baru yang dikembangkan untuk solusi ini karena menyediakan hosting turn-key yang fleksibel, memungkinkan tim DevOps untuk fokus pada pengiriman fitur.

Alternatif

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

  • Jika organisasi telah memutuskan untuk menjaga titik akhir yang ada tetap privat dan tidak mengeksposnya secara publik, instans API Management organisasi dapat ditautkan ke Azure Virtual Network:

  • Organisasi dapat menjaga instans API Management tetap privat dengan menyebarkannya dalam mode internal. Organisasi kemudian dapat menggunakan penyebaran dengan Azure Application Gateway untuk mengaktifkan akses publik untuk beberapa API sementara yang lain tetap internal. Untuk informasi selengkapnya, lihat Mengintegrasikan API Management pada jaringan virtual internal dengan 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. Jika demikian, organisasi masih dapat memanfaatkan API Management secara lokal dengan menggunakan gateway yang dihost sendiri.

    Gateway yang dihost sendiri adalah penyebaran kontainer gateway API Management yang terhubung kembali ke Azure pada soket keluar. Prasyarat pertama adalah gateway yang dihost sendiri tidak dapat disebarkan tanpa sumber daya induk di Azure, yang membawa biaya tambahan. Kedua, tingkat Premium API Management diperlukan.

Detail skenario

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

Tujuan untuk proyek ini termasuk mengatasi utang teknis, meningkatkan pemeliharaan yang sedang berlangsung, dan mempercepat pengembangan fitur dengan bug regresi yang lebih sedikit. Proyek ini akan menggunakan proses berulang untuk menghindari risiko, dengan beberapa langkah dilakukan secara paralel:

  • Tim pengembangan akan memodernisasi back end aplikasi, yang terdiri dari database relasional yang dihosting di VM.
  • Tim pengembangan in-house akan menulis fungsionalitas bisnis baru yang akan diekspos melalui API HTTP baru.
  • Tim pengembangan kontrak akan membuat UI berbasis browser baru, yang akan dihosting di Azure.

Fitur aplikasi baru akan dikirimkan secara bertahap. Fitur-fitur ini akan secara bertahap menggantikan fungsionalitas UI klien/server berbasis browser yang ada (dihosting secara lokal) yang sekarang mendukung bisnis e-niaga perusahaan.

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

Kemungkinan kasus penggunaan

Skenario ini menyoroti modernisasi tumpukan perangkat lunak berbasis browser warisan.

Anda dapat menggunakan skenario ini untuk:

  • Lihat bagaimana bisnis Anda dapat memperoleh manfaat dari menggunakan ekosistem Azure.
  • Rencanakan untuk memigrasikan layanan ke Azure.
  • Pelajari bagaimana pergeseran ke Azure akan memengaruhi API yang ada.

Pertimbangan

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

Keandalan

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

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

API Management ditawarkan dalam empat tingkatan: Pengembang, Dasar, Standar, dan Premium. Untuk panduan terperinci tentang perbedaan tingkat ini, lihat panduan harga Azure API Management.

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

Catatan

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

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

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Dokumentasi produk:

Pelajari modul: