Software as a Service (SaaS) adalah topik kompleks dengan banyak poin yang perlu dipertimbangkan. Vendor perangkat lunak independen (ISV) yang membangun solusi SaaS mereka di Azure perlu menyelesaikan masalah dan membuat keputusan seperti:
- Model penyewaan mana yang harus saya gunakan?
- Bagaimana cara menyiapkan solusi identitas untuk digunakan dalam arsitektur multipenyewa?
- Bagaimana cara menangani onboarding pelanggan baru?
Arsitektur ini bertujuan untuk menjawab beberapa pertanyaan ini dan menyediakan tempat awal ke dunia SaaS. Arsitektur ini dapat disesuaikan agar sesuai dengan berbagai skenario.
Kemungkinan kasus penggunaan
Berikut ini adalah beberapa contoh kasus penggunaan di mana Anda dapat menggunakan arsitektur ini:
- Modernisasi aplikasi yang ada untuk mendukung multitenansi penuh sebagai bagian dari pergeseran ke model bisnis berbasis SaaS.
- Kembangkan penawaran SaaS yang benar-benar baru.
- Memigrasikan penawaran SaaS dari layanan cloud lain ke Azure.
Sistem
Unduh file PowerPoint arsitektur ini.
Terminologi
Tabel berikut ini menjelaskan istilah yang muncul di artikel ini.
| Persyaratan | Deskripsi | Contoh |
|---|---|---|
| Vendor SaaS atau ISV | Entitas yang memiliki aplikasi dan kode SaaS dan menjual produk SaaS. | Contoso Inc, menjual aplikasi SaaS mereka: Contoso Tickets. |
| Penyewa | Instans aplikasi SaaS yang dibeli dari Vendor SaaS. | Kedai Kopi Keempat. |
| Admin pelanggan SaaS | Orang siapa yang membeli atau mengelola penyewa aplikasi. | Joe, pemilik Fourth Coffee Shop. |
| Pengguna pelanggan SaaS | Orang yang menggunakan penyewa aplikasi tanpa mengelolanya dan biasanya milik perusahaan atau grup yang sama dengan admin pelanggan SaaS. | Jill, manajer acara di Fourth Coffee Shop, dan Susan, pelanggan Fourth Coffee Shop. |
| Pengguna akhir | Admin pelanggan SaaS, pengguna pelanggan SaaS, atau jenis pengguna lain yang diperkenalkan. Ini adalah istilah umum untuk menjelaskan pengguna yang masuk ke aplikasi. | Joe, Jill, dan Susan adalah semua pengguna akhir (dari perspektif ISV). |
| Aplikasi front-end | Aplikasi front-end apa pun. | Aplikasi Onboarding & admin dan aplikasi SaaS adalah aplikasi front-end. |
Alur kerja
Admin pelanggan SaaS menavigasi ke situs yang dihosting di aplikasi Onboarding &admin.
Admin pelanggan SaaS masuk dengan menggunakan alur kerja masuk pengguna.
Admin pelanggan SaaS menyelesaikan alur onboarding.
Admin pelanggan SaaS menavigasi ke area admin penyewa di aplikasi Onboarding &admin dan menambahkan Pengguna Pelanggan SaaS ke penyewa yang baru dibuat.
Pengguna pelanggan SaaS menavigasi ke aplikasi SaaS dan menggunakan aplikasi SaaS.
Rincian masuk pengguna
Alur kerja masuk pengguna terdiri dari langkah-langkah berikut:
Pengguna akhir menavigasi ke aplikasi front-end dan memilih tombol Masuk.
Aplikasi Front-end mengalihkan pengguna akhir ke halaman masuk yang dihosting oleh penyedia identitas.
Pengguna Akhir memasukkan informasi akun dan mengirimkan formulir masuk ke Penyedia identitas.
Penyedia Identitas mengeluarkan permintaan POST dengan alamat email pengguna akhir dan ID objek untuk mengambil izin dan peran mereka.
API Data izin mencari informasi pengguna akhir di penyimpanan Data izin dan mengembalikan daftar izin dan peran yang ditetapkan untuk pengguna akhir tersebut.
Penyedia Identitas menambahkan izin dan peran sebagai klaim kustom ke token ID, yang merupakan token web JSON (JWT).
Penyedia Identitas mengembalikan token ID kepada pengguna akhir dan memulai pengalihan ke aplikasi front-end.
Pengguna akhir dialihkan ke titik akhir masuk pada aplikasi front-end dan menyajikan token ID.
Aplikasi Front-end memvalidasi token ID yang disajikan.
Aplikasi Front-end mengembalikan halaman masuk yang berhasil dan pengguna akhir sekarang masuk.
Untuk informasi selengkapnya tentang cara kerja alur masuk ini, lihat Protokol Koneksi OpenID.
Onboard penyewa baru
Alur kerja onboarding penyewa terdiri dari langkah-langkah berikut:
Admin pelanggan SaaS menavigasi ke aplikasi Onboarding &admin dan melengkapi formulir pendaftaran.
Aplikasi Onboarding &admin mengeluarkan permintaan POST ke API data Penyewa untuk membuat penyewa baru.
API data Penyewa membuat penyewa baru di penyimpanan data penyewa.
API data Penyewa mengeluarkan permintaan POST ke API Data izin untuk memberikan izin admin pelanggan SaaS kepada penyewa yang baru dibuat.
API Data izin membuat rekaman izin baru di penyimpanan Data izin.
API Data izin berhasil dikembalikan.
API data Penyewa berhasil dikembalikan.
Aplikasi Onboarding &admin mengeluarkan permintaan POST ke penyedia pemberitahuan Email untuk mengirim pesan email "penyewa dibuat" ke admin pelanggan SaaS.
Penyedia pemberitahuan Email mengirimkan email.
Penyedia pemberitahuan Email berhasil ditampilkan.
Aplikasi Onboarding &admin mengeluarkan permintaan ke Penyedia identitas untuk me-refresh token ID admin pelanggan SaaS sehingga akan menyertakan klaim JWT ke penyewa yang baru dibuat.
Penyedia Identitas mengeluarkan permintaan POST dengan alamat email dan ID objek admin pelanggan SaaS untuk mengambil izin dan peran mereka.
API Data izin mencari informasi admin pelanggan SaaS di penyimpanan Data izin dan mengembalikan daftar izin dan peran yang ditetapkan ke admin pelanggan SaaS.
Penyedia Identitas menambahkan izin dan peran sebagai klaim kustom ke token ID.
IdP mengembalikan token ID ke Onboarding &Admin App.
Aplikasi Onboarding &admin mengembalikan pesan sukses dan token ID baru ke Admin Pelanggan SaaS.
Menambahkan pengguna ke penyewa
Penambahan pengguna ke alur kerja penyewa terdiri dari langkah-langkah berikut:
Admin pelanggan SaaS meminta untuk melihat daftar penyewa dari area admin penyewa di aplikasi Onboarding &admin.
Aplikasi Onboarding &admin mengeluarkan permintaan GET ke API data Penyewa untuk mendapatkan daftar penyewa untuk admin pelanggan SaaS.
API data Penyewa mengeluarkan permintaan GET ke API Data izin untuk mendapatkan daftar penyewa yang dapat diakses oleh admin pelanggan SaaS.
API Data izin mengembalikan daftar izin penyewa.
API data Penyewa mencari informasi penyewa di penyimpanan data Penyewa dan mengembalikan daftar data penyewa berdasarkan daftar izin penyewa yang diterima.
Aplikasi Onboarding &admin mengembalikan daftar data penyewa ke admin pelanggan SaaS.
Admin pelanggan SaaS memilih penyewa dari daftar untuk menambahkan pengguna pelanggan SaaS ke dan memasukkan alamat email untuk pengguna pelanggan SaaS.
Aplikasi Onboarding &admin mengeluarkan permintaan POST ke API data Penyewa untuk menambahkan izin bagi pengguna pelanggan SaaS pada penyewa yang ditentukan.
API data Penyewa memverifikasi bahwa admin pelanggan SaaS memiliki klaim JWT yang valid ke penyewa yang ditentukan dan memiliki izin tulis pengguna di atasnya.
API data Penyewa mengeluarkan permintaan POST ke API Data izin untuk menambahkan izin bagi pengguna pelanggan SaaS pada penyewa yang ditentukan.
API Data izin mengeluarkan permintaan GET ke Penyedia identitas untuk mencari pengguna pelanggan SaaS dengan alamat email yang disediakan.
IdP mengembalikan ID objek pengguna pelanggan SaaS.
API Data izin menambahkan rekaman izin di penyimpanan Data izin untuk pengguna pelanggan SaaS pada penyewa yang ditentukan dengan menggunakan ID objek mereka.
API Data izin berhasil dikembalikan.
API data Penyewa berhasil dikembalikan.
Aplikasi Onboarding &admin berhasil dikembalikan.
Komponen
Arsitektur ini menggunakan layanan Azure berikut:
App Service memungkinkan Anda membangun dan menghosting aplikasi web dan aplikasi API dalam bahasa pemrograman yang Anda pilih tanpa perlu mengelola infrastruktur.
Azure Active Directory B2C dengan mudah mengaktifkan manajemen identitas dan akses untuk aplikasi pengguna akhir.
Azure SQL Database adalah layanan terkelola database hubungan tujuan umum yang mendukung data relasional, data spasial, JSON, dan XML.
Azure Logic Apps memungkinkan Anda dengan cepat membangun integrasi yang kuat menggunakan alat GUI sederhana.
Alternatif
Efektivitas pilihan alternatif apa pun sangat tergantung pada model penyewaan yang ingin Anda dukung aplikasi SaaS Anda. Berikut ini adalah beberapa contoh pendekatan alternatif yang dapat Anda ikuti saat menerapkan solusi ini:
Solusi saat ini menggunakan Azure Active Directory B2C sebagai penyedia identitas. Anda dapat menggunakan idP lain, seperti ID Microsoft Entra.
Untuk persyaratan keamanan dan kepatuhan yang lebih ketat, Anda dapat memilih untuk menerapkan jaringan privat untuk komunikasi lintas layanan.
Alih-alih menggunakan panggilan REST antar layanan, Anda dapat menerapkan gaya arsitektur berbasis peristiwa untuk olahpesan lintas layanan.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian prinsip panduan yang dapat Anda ikuti untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Keamanan
Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.
Solusi ini bergantung pada identitas sebagai paradigma keamanannya. Autentikasi dan otorisasi untuk aplikasi web dan API diatur oleh platform identitas Microsoft, yang bertanggung jawab untuk menerbitkan dan memverifikasi token ID pengguna (JWT).
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.
Komponen dalam solusi ini memiliki beberapa biaya yang terkait dengan operasi mereka, tetapi biayanya sederhana untuk sebagian besar aplikasi web dan solusi SaaS. Selain itu, Anda dapat mengontrol biaya dengan mengelola pengaturan sumber daya berikut:
Anda dapat menskalakan paket App Service yang menjalankan aplikasi agar sesuai dengan throughput yang Anda butuhkan. Selain itu, Anda dapat menjalankan setiap aplikasi pada paket terpisah jika memerlukan throughput yang lebih tinggi, tetapi Anda akan dikenakan biaya yang lebih tinggi sebagai hasilnya. Untuk mengetahui informasi selengkapnya, lihat Gambaran umum paket Azure App Service.
Azure AD B2C menyediakan dua SKU: Premium P1 dan Premium P2. Kedua SKU menyertakan jatah gratis untuk jumlah pengguna aktif bulanan (MAUs), tetapi Anda perlu mengevaluasi fitur mana yang disediakan setiap SKU untuk menentukan mana yang diperlukan untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat Harga ID Eksternal Microsoft Entra.
Azure SQL memiliki beberapa model pembelian agar sesuai dengan berbagai kasus penggunaan, termasuk kemampuan untuk skala otomatis. Anda perlu mengevaluasi penggunaan pada database Anda sendiri untuk memastikan Anda mengukurnya dengan benar. Untuk informasi selengkapnya, lihat Membandingkan model pembelian berbasis vCore dan DTU dari Azure SQL Database.
Efisiensi kinerja
Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Gambaran umum pilar efisiensi performa.
Arsitektur ini harus dapat menskalakan untuk dengan mudah memenuhi sebagian besar beban kerja menengah hingga menengah. Karena arsitektur sebagian besar menggunakan layanan platform Azure (PaaS), Anda memiliki banyak opsi untuk menyesuaikan skala solusi berdasarkan kebutuhan dan beban Anda.
Menyebarkan skenario ini
Jika Anda ingin menyebarkan skenario ini, lihat Azure SaaS Dev Kit di GitHub. Ini adalah implementasi referensi yang dapat disebarkan dari arsitektur ini.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Landon Pierce | Teknisi Pelanggan
Kontributor lain:
- Chris Ayers | Insinyur Pelanggan Senior
- John Downs | Insinyur Pelanggan Senior
- LaBrina Mencintai | Manajer Teknik SVC Utama
- Gary Moore | Programmer/Writer
- Nick Pinheiro | Konsultan Senior
- William Salazar | Insinyur Pelanggan Senior
- Ali Sanjabi | Insinyur Pelanggan Senior
- Arsen Vladimirskiy | Insinyur Pelanggan Utama
- Jason Young | Manajer Teknik SVC Utama
Langkah berikutnya
Berikut adalah beberapa sumber daya tambahan yang direkomendasikan untuk membangun aplikasi SaaS di Azure:
- Solusi multipenyewa arsitek di Azure - Menjelaskan praktik terbaik.
- Pertimbangan ISV untuk zona pendaratan Azure
- Kerangka Kerja Microsoft Azure Well-Architected
- Aplikasi WingTips Tickets SaaS - Menyediakan detail tentang tradeoff antara berbagai model penyewaan dalam lapisan database.
Sumber daya terkait
- Model penyewaan yang perlu dipertimbangkan untuk solusi multipenyewa
- Pendekatan arsitektural untuk komputasi dalam solusi multi-penyewa
- Pendekatan arsitektural untuk penyimpanan dan data dalam solusi multi-penyewa
- Pertimbangan Azure App Service dan Azure Functions untuk multisewa
- SaaS Multi-penyewaan di Azure
- Pola Desain Cloud