Bagaimana Anda mengelola ekstensibilitas dalam sistem multi-tenant Anda?

Saya punya beberapa produk multi-penyewa berbasis web besar sekarang, dan segera saya bisa melihat bahwa akan ada banyak penyesuaian yang bersifat spesifik penyewa.

Bidang tambahan di sini atau di sana, mungkin halaman tambahan atau beberapa logika tambahan di tengah alur kerja - hal semacam itu.

Beberapa penyesuaian ini dapat digulirkan ke produk inti, dan itu hebat. Beberapa dari mereka sangat spesifik dan akan menghalangi orang lain.

Saya memiliki beberapa ide dalam pikiran untuk mengelola ini, tetapi tidak satu pun dari mereka yang terlihat bagus. Solusi yang jelas adalah memperkenalkan satu ton pengaturan tingkat klien, memungkinkan berbagai 'fitur' diaktifkan pada basis per-klien. Kelemahan dari itu, tentu saja, adalah kerumitan besar dan kekacauan. Anda dapat memperkenalkan sejumlah besar pengaturan, dan dari waktu ke waktu berbagai jenis logika (presentasi, bisnis) dapat keluar dari kendali. Lalu ada masalah bidang khusus klien, yang meminta sesuatu yang lebih bersih daripada hanya menambahkan sekelompok bidang nullable ke tabel yang ada.

Jadi apa yang dilakukan orang untuk mengelola ini? Force.com tampaknya menjadi master dari ekstensibilitas; jelas mereka telah membuat platform dari bawah ke atas yang super extensible. Anda dapat menambahkan hampir apa saja dengan UI berbasis web mereka. FogBugz melakukan sesuatu yang serupa di mana mereka menciptakan model plugin yang kuat, kalau dipikir-pikir, mungkin sebenarnya terinspirasi oleh Force. Saya tahu mereka menghabiskan banyak waktu dan uang untuk itu dan jika saya tidak salah maksudnya adalah menggunakannya secara internal untuk pengembangan produk di masa depan.

Kedengarannya seperti hal yang saya bisa tergoda untuk membangun tetapi mungkin tidak seharusnya. :)

Apakah investasi besar dalam arsitektur pluggable satu-satunya cara untuk pergi? Bagaimana Anda mengelola masalah ini, dan hasil seperti apa yang Anda lihat?

EDIT: Tampaknya FogBugz menangani masalah dengan membangun platform yang cukup kuat dan kemudian menggunakannya untuk menyatukan layar mereka. Untuk memperluasnya, Anda membuat kelas yang berisi DLL yang mengimplementasikan antarmuka seperti ISearchScreenGridColumn, dan itu menjadi modul. Saya yakin itu sangat mahal untuk membangun mengingat bahwa mereka memiliki banyak pengembang dan mereka bekerja selama berbulan-bulan, ditambah luas permukaan mereka mungkin 5% dari ukuran aplikasi saya.

Saat ini saya serius bertanya-tanya apakah Force.com adalah cara yang tepat untuk menangani ini. Dan saya adalah pria ASP.Net inti yang keras, jadi ini adalah posisi yang aneh untuk menemukan diri saya.

Saya menghadapi masalah yang sama, dan saya akan memberitahu Anda bagaimana saya menyelesaikannya.

1. Pertama, ada perpustakaan "inti", atau mesin. Ini pada dasarnya menjalankan pertunjukan, sama seperti Anda sudah tahu. Ini menangani hal-hal yang umum untuk setiap sistem, mulai dari merender bentuk dinamis, pengguna dan manajemen akun, peran, apa saja, dan melakukannya.

2. Setiap bagian dari sistem terkandung dalam modul. Modul memiliki dependensi (modul lain yang bergantung padanya). Sebagai contoh, sistem "inti" memiliki Keamanan (pengguna, grup, peran, kebijakan kata sandi), Lokal, (terjemahan, negara, budaya), Penyimpanan File, Email, dll. Setiap modul menentukan sendiri menggunakan file xml. File xml pada dasarnya menentukan skema, tabel, kelas perhitungan, definisi layar, dan sebagainya. Ini dibaca ketika aplikasi dimulai jika tanggal file telah berubah .

3. Modul khusus pelanggan memiliki file xml sendiri dan DLL sendiri. Semuanya ditambah dan berfungsi sesuai dan transparan dengan seluruh sistem. Tepat untuk mengganti tampilan MVC yang ada dengan yang kustom, dengan kode kustom dan model tampilan kustom.

4. Jika pelanggan ingin memperluas fungsionalitas yang ada, xml / sistem menyediakan metode di mana saya dapat "menurunkan" satu modul dari yang lain. Modul baru memiliki semua fungsi yang ada, tetapi dengan persyaratan khusus pelanggan dalam DLL baru dan dengan file XML diperpanjang yang dapat membuat modifikasi. Peringatannya adalah, mereka tidak dapat benar-benar menghapus bidang yang ada dalam sistem ini, tetapi kami dapat memperluasnya dan menyediakan objek dan fungsi yang sama sekali baru.

Memiliki banyak logika versi dan lapisan kode untuk dikelola tidak menambah nilai pada aplikasi / situs web Anda. Ini juga membutuhkan lebih banyak kekuatan otak untuk memahami apa yang sedang terjadi dan mengalihkan perhatian Anda dari inti dari apa yang Anda lakukan.

Saya menyarankan berbeda. Saya menyarankan untuk menjaga hal-hal yang sederhana tetap rumit.

Pertahankan basis kode tunggal yang sama untuk semua orang. Setiap fitur yang Anda tambahkan adalah fitur untuk semua. Hanya batasi jumlah item atau penyimpanan atau hal yang dapat diukur, bukan fitur. Alasannya adalah mengkuantifikasi hal-hal seperti penyimpanan, jumlah entri data, dll. Sangat mudah untuk diprogram dan dapat diterapkan hanya pada segelintir hal yang benar-benar membatasi pengguna dari menjadi liar di aplikasi Anda. Ini hanya perlu diprogram pada penambahan item alih-alih melakukan beberapa logika fitur. Bagaimana jika fitur diikat ke fitur lain? Menjadi sangat rumit untuk kode untuk ini.

Untuk memenuhi syarat jawaban saya, saya telah membangun kerangka kerja e-commerce yang saya miliki untuk banyak klien dan telah belajar cara keras untuk mempertahankan semua keanehan mereka. Saya akhirnya memutuskan rantai dan membuat situs web administrasi tunggal yang multi penyewa untuk e-niaga. Saya kemudian memiliki situs web yang menarik data dari panggilan layanan web. Hal ini memungkinkan tim yang berbeda dalam teknologi yang berbeda untuk mengimplementasikan fitur spesifik untuk situs e-commerce sementara saya terus dibayar setiap bulan pada infrastruktur yang sama dan saya tidak peduli apa yang mereka lakukan. Saya hanya membatasi penggunaan dengan angka, bukan fitur. Caranya lebih mudah. Klien dapat memilih vendor mereka sendiri untuk membangun situs web mereka dan saya tidak lagi terlibat dalam keputusan itu.

Saya juga memiliki layanan berlangganan untuk SAAS manajemen konten. Ini berfungsi oleh tingkatan penggunaan juga dan klien dapat menambahkan plugin mereka sendiri jika mereka mau sementara saya meminta tim saya menambahkan lebih banyak fitur untuk semua.

Ini hanya pengalaman saya dari membenturkan kepala saya ke dinding setelah sekian lama, kemudian menemukan sesuatu yang lebih sederhana.

Jika sesuatu selalu spesifik untuk setiap klien, jangan membuat kerangka untuk itu. Hancurkan menjadi bagian-bagian yang paling sederhana sehingga bagian kerangka bekerja untuk semua dan kemudian hentikan sisanya sehingga Anda dapat memperluasnya untuk individu.

Produk perangkat lunak yang saya kerjakan memiliki bidang ekstra untuk ekstensibilitas pengguna. Setiap item data untuk bidang ini dapat dikunci ke baris yang ada di tabel utama dalam aplikasi. Misalnya, jika perangkat lunak Anda berisi daftar pesanan untuk setiap pelanggan dan setiap pelanggan, maka tabel data yang dapat disesuaikan akan memiliki kolom untuk kunci asing ke tabel pelanggan dan tabel pesanan, hanya satu yang tidak akan nol. Entah itu atau sejumlah tabel masing-masing memiliki bidang khusus untuk satu tabel.

Ini adalah cara sederhana dan performan untuk menyimpan data ekstra untuk pengguna. Informasi tambahan perlu disimpan tentang nama dan jenis bidang ini.

Itu mencakup bidang khusus untuk pelanggan. Untuk perilaku khusus, API layanan web akan memungkinkan ekstensi.

1) Menjalankan kode orang lain pada kotak yang Anda miliki adalah masalah yang cukup sulit. Entah Anda dapat mempercayai mereka atau Anda dapat menunda tanggung jawab secara wajar, Anda harus sangat mem-sandbox kode mereka dan memiliki dedikasi yang lebih tinggi daripada rata-rata untuk keamanan. Karena sistem plugin Anda memungkinkan lebih banyak fungsionalitas, kesulitan membuatnya lebih aman tumbuh. Hal-hal seperti penolakan layanan (plugin menggunakan terlalu banyak sumber daya), kebocoran informasi (plugin dapat mengakses data penyewa lain), dll. Bisa sangat nyata dan menyusahkan, saya tidak akan mengambil bagian dalam hal ini kecuali saya bisa membuat orang sangat berkenalan dengan masalah-masalah ini atau orang-orang yang sangat cakap dengan banyak waktu untuk memperbaikinya.

2) Ya, modularitas dan kemampuan penyesuaian sangat sulit. Hal-hal seperti pola Strategi dapat membantu (nama mewah untuk pointer fungsi; di Jawa biasanya diterapkan dengan mendeklarasikan Antarmuka yang dapat diimplementasikan oleh pengguna kelas untuk menyesuaikan perilaku kode Anda), tetapi Anda ingin sangat terisolasi dan dipisahkan kode untuk ini berfungsi.

3) Dari sisi data, ini mungkin salah satu contoh penyimpanan schemaless yang bermanfaat. Jika Anda memiliki model data relasional, memiliki tabel dengan banyak kolom untuk pelanggan yang berbeda bermasalah (ya, Anda berakhir dengan banyak kolom nullable, yang buruk , salah satu alasannya adalah bahwa sulit atau tidak mungkin untuk mengatur kendala yang benar [yaitu kendala yang tidak memungkinkan kombinasi null yang tidak valid muncul]). Menambahkan tabel khusus pelanggan (yaitu usersdan foo_users, dengan usersmemegang bidang yang valid untuk semua pelanggan dan foo_usersmemiliki pengajuan spesifik Foo) lebih baik; Anda dapat memiliki kendala yang benar dengan mudah, tetapi RDBMS Anda mungkin tidak menanganinya dengan anggun (karena bergabung dengan ledakan, batasan jumlah tabel, dll.) dan mungkin akan terlihat jelek di kode Anda.

Anda mungkin akhirnya menerapkan penyimpanan nilai kunci dalam RDBMS Anda, yang membuat model data Anda kurang relasional-ish dan akan menyebabkan ketidaknyamanan (yaitu database relasional bekerja paling baik dengan model relasional-ish). Saya tidak yakin apakah solusi NoSQL akan sesuai dengan masalah secara keseluruhan, tetapi skema-implementasi sebagian besar mungkin merupakan keuntungan.