Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Membandingkan pola penyebaran terpusat dan terdistribusi
Anda dapat menerapkan OPA dalam pola penyebaran terpusat atau terdistribusi, dan metode ideal untuk aplikasi multi-penyewa bergantung pada kasus penggunaan. Untuk contoh pola ini, lihat bagian Menggunakan PDP terpusat dengan PEPs aktif APIs dan Menggunakan PDP terdistribusi dan PEPs pada APIs bagian sebelumnya dalam panduan ini. Karena OPA dapat digunakan sebagai daemon dalam sistem operasi atau wadah, OPA dapat diimplementasikan dalam berbagai cara untuk mendukung aplikasi multi-tenant.
Dalam pola penyebaran terpusat, OPA digunakan sebagai wadah atau daemon dengan RESTful API-nya tersedia untuk layanan lain dalam aplikasi. Ketika layanan memerlukan keputusan dari OPA, RESTful API OPA pusat dipanggil untuk menghasilkan keputusan ini. Pendekatan ini mudah diterapkan dan dipelihara, karena hanya ada satu penyebaran OPA. Kelemahan dari pendekatan ini adalah tidak menyediakan mekanisme apa pun untuk mempertahankan pemisahan data penyewa. Karena hanya ada satu penyebaran OPA, semua data penyewa yang digunakan dalam keputusan OPA, termasuk data eksternal apa pun yang direferensikan oleh OPA, harus tersedia untuk OPA. Anda dapat mempertahankan isolasi data penyewa dengan pendekatan ini, tetapi harus ditegakkan oleh kebijakan dan struktur dokumen OPA atau akses ke data eksternal. Pola penerapan terpusat juga memerlukan latensi yang lebih tinggi, karena setiap keputusan otorisasi harus membuat panggilan RESTful API ke layanan lain.
Dalam pola penyebaran terdistribusi, OPA digunakan sebagai wadah atau daemon di samping layanan aplikasi multi-penyewa. Itu bisa digunakan sebagai wadah sespan atau sebagai daemon yang berjalan secara lokal pada sistem operasi. Untuk mengambil keputusan dari OPA, layanan membuat panggilan RESTful API ke penerapan OPA lokal. (Karena OPA dapat digunakan sebagai paket Go, Anda dapat menggunakan Go secara native untuk mengambil keputusan alih-alih menggunakan panggilan API.) RESTful Tidak seperti pola penyebaran terpusat, pola terdistribusi membutuhkan upaya yang jauh lebih kuat untuk menyebarkan, memelihara, dan memperbarui karena ada di beberapa area aplikasi. Manfaat dari pola penyebaran terdistribusi adalah kemampuan untuk mempertahankan isolasi data penyewa, terutama untuk aplikasi yang menggunakan model SaaS silo. Data khusus penyewa dapat diisolasi dalam penerapan OPA yang khusus untuk penyewa tersebut, karena OPA dalam model terdistribusi digunakan bersama penyewa. Selain itu, pola penyebaran terdistribusi memiliki latensi yang jauh lebih rendah daripada pola penerapan terpusat, karena setiap keputusan otorisasi dapat dibuat secara lokal.
Saat Anda memilih pola penerapan OPA di aplikasi multi-tenant Anda, pastikan untuk mengevaluasi kriteria yang paling penting untuk aplikasi Anda. Jika aplikasi multi-tenant Anda sensitif terhadap latensi, pola penyebaran terdistribusi menawarkan kinerja yang lebih baik dengan mengorbankan penerapan dan pemeliharaan yang lebih kompleks. Meskipun Anda dapat mengelola beberapa kompleksitas ini melalui DevOps dan otomatisasi, masih membutuhkan upaya tambahan jika dibandingkan dengan pola penyebaran terpusat.
Jika aplikasi multi-tenant Anda menggunakan model SaaS siloed, Anda dapat menggunakan pola penyebaran OPA terdistribusi untuk meniru pendekatan siloed untuk isolasi data penyewa. Ini karena ketika OPA berjalan bersama setiap layanan aplikasi khusus penyewa, Anda dapat menyesuaikan setiap penyebaran OPA agar hanya berisi data yang terkait dengan penyewa tersebut. Siloing data OPA dalam pola penerapan OPA terpusat tidak dimungkinkan. Jika Anda menggunakan pola penyebaran terpusat atau pola terdistribusi bersama dengan model SaaS yang dikumpulkan, isolasi data penyewa harus dipertahankan dalam model dokumen OPA.