Mendukung multitenancy

Apa saja tantangan khas yang muncul saat mengubah aplikasi penyewa tunggal menjadi aplikasi multitenant? Keamanan dan isolasi data menurut saya yang paling signifikan. Apa yang lainnya?

Saya salah satu arsitek untuk upaya otomatisasi yang cukup signifikan, dan secara historis hanya perusahaan kami yang menggunakannya. Kami ingin memungkinkan orang lain untuk menggunakannya juga. Setiap kali kita berbicara tentang "menjadikannya multitenant", percakapan berkisar seputar menjaga pengguna dengan satu penyewa dari data yang dimiliki penyewa lain, dan memastikan bahwa pengguna dengan satu penyewa tidak dapat (baik secara sengaja atau tidak sengaja) membuat dampak pada pengguna lain. lingkungan penyewa. Yang saya bertanya-tanya adalah apakah keamanan / isolasi data benar-benar satu-satunya masalah utama di sini, atau apakah ada beberapa masalah utama lain yang tidak kita pikirkan.

architecture multitenancy

— Grant Palin
sumber

Solusi termudah? Sebuah instance baru dari keseluruhan sistem, termasuk perangkat keras, kosong, dari awal, satu sistem baru per penyewa. Jika sistem dan data cukup berharga, ini mungkin pilihan yang cukup bagus. Jika Anda tidak menyukai perangkat keras baru untuk setiap contoh - gunakan virtualisasi. Ini mungkin tidak paling efisien tetapi tentu saja akan menghemat banyak sakit kepala.

— SF.

Mungkin dari perspektif desain, ini yang paling mudah, tetapi dari perspektif administratif sepertinya tidak. Setidaknya sysadmin kami tidak terlalu bersemangat dengan proposal ini. (Dan ya, kami menggunakan VMs.) Cara yang lebih banyak untuk mengelola (pemantauan, penyebaran, dll.) Kami sebenarnya sedang mencari cara untuk membuat ini lebih mudah dikelola untuk mendapatkan beberapa isolasi fisik di sini tetapi di muka itu, ini pendekatan tampaknya perdagangan kesederhanaan dev untuk kesederhanaan admin ...?

Jawaban:

Selain siloing data, Anda mungkin mengalami masalah dengan

Ketersediaan - dengan penyewa tunggal, mereka hanya dapat melakukan DoS sendiri, tetapi bahkan ketika data dihilangkan dengan benar, penyewa masih dapat menghabiskan sumber daya.
Logging - semua pesan log diasumsikan sebagai penyewa tunggal. Kecuali jika Anda silo log per penyewa, pesan log Anda mungkin menjadi kurang berguna.
Concurrency - aplikasi penyewa tunggal dapat berjalan di bawah beban moderat, atau pertengkaran tinggi untuk beberapa kunci dapat secara efektif membuat serial operasi tertentu. Jika kunci dikalikan per penyewa, Anda mungkin mulai melihat interleaving operasi yang tidak terjadi sebelumnya. Kondisi ras yang sangat tidak mungkin terwujud, sekarang mungkin akan terwujud.
Sumber baru pertentangan sumber daya - di mana sebelumnya Anda mungkin memiliki soket dan file m menangani, sekarang gandakan yang per-penyewa.
Pengorbanan konfigurasi / mundur kompatibilitas - di mana sebelum Anda dapat menghapus komponen saat Anda meluncurkan pengganti, Anda sekarang mungkin memiliki satu penyewa menuntut komponen, dan satu penyewa menuntut bahwa komponen lama yang diganti tinggal di sekitar tanpa batas.
Target panggilan pengadilan - saat ini Anda adalah target panggilan pengadilan untuk masalah yang terkait dengan perusahaan Anda. Dengan beberapa penyewa, Anda mungkin harus menanggapi permintaan panggilan pengadilan bahkan ketika Anda bukan pihak dalam tindakan hukum.

Beberapa di antaranya berasumsi bahwa Anda menjalankan semua penyewa di ruang alamat yang sama (mesin atau cluster). Jika setiap penyewa menjalankan perangkat lunak Anda pada perangkat kerasnya, Anda dapat memperdebatkan beberapa hal di atas dan menambahkan:

Kesulitan mengakses mesin untuk debug.
Mendukung permintaan untuk versi yang lebih lama.
Permintaan untuk mengizinkan kontraktor pihak ketiga untuk mengonfigurasi.
Kontrol perangkat keras yang dijalankannya kurang.
Kurang kontrol atas siklus tambalan / pembaruan OS yang digunakan.

— Mike Samuel
sumber

Masalah terbesar dalam multi-tenancy menurut saya adalah kustomisasi. Ini terjadi secara rutin jika Anda menjual aplikasi bisnis ke perusahaan. Itu bisa bervariasi dari sesuatu yang sederhana seperti setiap pelanggan menginginkan kulit mereka sendiri hingga kemampuan untuk mengonfigurasi bidang, aturan, formulir, dan laporan tambahan. Tingkat penyesuaian yang Anda butuhkan untuk mendukung memainkan peran penting dalam arsitektur.

— Sriram
sumber

Jawaban Mike sangat baik, dan banyak poin di sana hampir meremehkan kompleksitas mereka karena betapa singkatnya mereka, jadi ingatlah itu.

Satu hal yang akan saya tambahkan adalah Anda harus memiliki alat manajemen yang baik untuk membuat (dan kemudian, mengelola) penyewa baru. Bergantung pada arsitektur fisik yang Anda gunakan, ini bisa jauh dari sepele, dan merupakan sesuatu yang sering diabaikan. Manfaat suatu perangkat lunak sebagai produk layanan baru benar-benar berperan ketika ada sejumlah besar penyewa, sehingga cukup banyak upaya harus dilakukan untuk memenuhi kebutuhan ini.

Untuk memperluas jawaban Sriram; kustomisasi per penyewa cukup banyak dilarang, segala sesuatu yang penyewa mungkin ingin ubah harus dapat dikonfigurasi . Misalnya, jika solusi Anda tidak memenuhi penambahan dinamis bidang data di setidaknya beberapa area utama, Anda kemungkinan akan dibanjiri dengan permintaan untuk penyesuaian. Ini salah satu dari beberapa kasus di mana sedikit tambahan kompleksitas dimuka tidak benar-benar membayar off (katakanlah itu bertentangan YAGNI, atau setidaknya, tingkat konfigurasi hampir merupakan persyaratan utama, sehingga Anda yang akan membutuhkan itu).

— Daniel B
sumber

Mengapa kustomisasi "dilarang"? Secara teknis hal ini dapat dicapai. Ada banyak pola berbeda yang memungkinkan penggunaan kembali sistem inti untuk beberapa penyewa sambil tetap menyediakan potongan-potongan khusus untuk penyewa individu. Jika seorang pelanggan bersedia membayar Anda untuk penyesuaian, akan masuk akal untuk mempertimbangkannya. Ada banyak produk multitenant yang memiliki kustomisasi per-klien karena alasan ini. Ini lebih dalam semangat YAGNI IMO untuk memungkinkan diperpanjang dan tidak standar untuk membuat semuanya dapat dikonfigurasi.

— RationalGeek

Yah, saya merujuk ke perangkat lunak sebagai implementasi layanan, secara umum (dari "multi-tenancy"). Tentu, ini dapat dicapai secara teknis, tetapi bertentangan dengan dasar-dasar SaaS. Dalam arti finansial, Anda mencapai biaya yang lebih rendah dengan berbagi implementasi dan mungkin infrastruktur untuk banyak penyewa. Hal ini memungkinkan Anda untuk menawarkan produk Anda dengan harga yang lebih rendah, sehingga menangkap "ekor panjang" dari pasar (sejumlah besar orang hanya bersedia membayar sedikit). Anda dapat mempertahankan mungkin 5 cabang sistem, tetapi tidak 15000, dan itulah yang SaaS bertujuan.

— Daniel B

Di tingkat perusahaan, saya sering melihat vendor SaaS yang bersedia melakukan penyesuaian signifikan terhadap kode mereka untuk mendapatkan pelanggan. Ketika seorang pelanggan membayar 6 atau 7 angka untuk layanan ini, ini mungkin merupakan model bisnis yang masuk akal.

— RationalGeek

Ya, dalam kasus-kasus itu, saya kira begitu. Sebagian besar perubahan yang saya lihat diimplementasikan sebagai fitur baru yang dapat dikonfigurasi yang, secara default, dimatikan untuk klien yang sudah ada. Masalahnya, saya pikir, adalah ketika 3 atau 4 klien pertama masing-masing mendapatkan perlakuan khusus karena solusinya belum lepas landas. Solusinya berakhir terlalu spesifik, dan menciptakan budaya "OK, kami hanya akan meretasnya". Tapi ya, saya setuju dengan komentar Anda di sekitar pelanggan besar.

— Daniel B

Ini adalah perbedaan yang bermanfaat yang kalian lakukan di seputar penyesuaian kemampuan. Saya pikir konsep yang sama mungkin berlaku untuk pengelolaan juga. Multitenancy kami mungkin bertujuan untuk pelanggan yang relatif sedikit lebih besar daripada pelanggan berekor panjang. Jika tujuan utama multitenancy adalah untuk menangkap ekor panjang, maka itu mungkin bukan pendekatan yang tepat bagi kita. Terima kasih atas refleksi ini.