Sayangnya, istilah ini tidak memiliki padanan bahasa Rusia yang bagus. Wikipedia memberi "multi-sewa, banyak sewa." Hal ini terkadang disebut "kepemilikan ganda". Istilah-istilah ini bisa jadi agak membingungkan, karena pokok bahasannya tidak secara inheren terkait dengan penyewaan atau kepemilikan. Ini adalah pertanyaan tentang arsitektur perangkat lunak dan organisasi operasinya. Dan yang terakhir ini tidak kalah pentingnya.
Kami mulai merumuskan pemahaman kami tentang multitenancy pada saat yang sama ketika kami mulai merancang pendekatan model kerja cloud (layanan) di 1C:Enterprise. Ini terjadi beberapa tahun yang lalu. Dan sejak itu pemahaman kita terus berkembang. Kami terus-menerus menemukan lebih banyak aspek baru dari subjek ini (pro, kontra, kesulitan, fitur, dll.).
Terkadang pengembang memahami multitenancy sebagai subjek yang sangat sederhana: “agar data beberapa organisasi dapat disimpan dalam satu database, Anda perlu menambahkan kolom dengan pengidentifikasi organisasi ke semua tabel dan menyetel filter di dalamnya.” Kami, tentu saja, juga mulai mempelajari masalah ini mulai saat ini. Namun mereka segera menyadari bahwa ini hanyalah satu pembukaan lahan (yang juga tidak mudah). Secara umum, ini adalah “seluruh negara”.
Ide dasar dari multitenancy dapat digambarkan seperti ini. Aplikasi tipikalnya adalah pondok yang dirancang untuk menampung satu keluarga, yang menggunakan infrastrukturnya (dinding, atap, pasokan air, pemanas, dll.). Aplikasi multitenancy adalah gedung apartemen. Di dalamnya, setiap keluarga menggunakan infrastruktur yang sama, namun infrastruktur itu sendiri diterapkan untuk seluruh rumah.
Apakah pendekatan multitenancy baik atau buruk? Anda dapat menemukan pendapat yang sangat berbeda mengenai hal ini. Sepertinya tidak ada “baik atau buruk” sama sekali. Anda perlu membandingkan pro dan kontra dalam konteks tugas spesifik yang sedang diselesaikan. Tapi ini adalah topik terpisah...
Dalam pengertian yang paling sederhana, tujuan multitenancy adalah mengurangi biaya pemeliharaan aplikasi dengan “mensosialisasikan” biaya infrastruktur. Ini adalah gerakan yang sama seperti mengurangi biaya aplikasi dengan menggunakan solusi produksi (mungkin dengan penyesuaian dan modifikasi), daripada menulisnya “sesuai pesanan.” Hanya dalam satu kasus pembangunan disosialisasikan, dan di kasus lain - eksploitasi.
Selain itu, kami ulangi, tidak ada link langsung ke metode penjualan. Arsitektur multitenancy juga dapat digunakan dalam infrastruktur TI perusahaan atau departemen untuk mengotomatisasi sejumlah besar cabang dan perusahaan induk serupa.
Bisa dibilang multitenancy bukan hanya soal mengatur penyimpanan data. Ini adalah model bagaimana aplikasi beroperasi secara keseluruhan (termasuk bagian penting dari arsitekturnya, model penerapannya, dan organisasi pemeliharaannya).
Hal yang paling sulit dan menarik tentang model multitenancy, menurut kami, adalah inti dari penerapan “bifurcates.” Sebagian dari fungsi tersebut berfungsi dengan area data tertentu (apartemen) dan “tidak tertarik” dengan kenyataan bahwa ada penghuni di apartemen lain. Dan ada pula yang memandang rumah secara keseluruhan dan berfungsi untuk semua penghuninya sekaligus. Pada saat yang sama, pihak yang terakhir tidak dapat mengabaikan fakta bahwa ini adalah apartemen yang terpisah, dan perlu untuk memastikan tingkat rincian dan keamanan yang diperlukan.
Di 1C:Enterprise, model multitenancy diimplementasikan pada level beberapa teknologi. Ini adalah mekanisme platform 1C:Enterprise, mekanismenya"Dan"", mekanisme (perpustakaan subsistem standar).
Masing-masing item ini berkontribusi pada pembangunan keseluruhan infrastruktur gedung apartemen. Mengapa hal ini diterapkan pada beberapa teknologi, dan bukan pada satu teknologi, misalnya dalam satu platform? Pertama-tama, karena beberapa mekanisme, menurut pendapat kami, cukup tepat untuk dimodifikasi untuk opsi penerapan tertentu. Namun secara umum, ini adalah pertanyaan yang sulit, dan kita selalu dihadapkan pada pilihan - pada tingkat apa yang lebih baik untuk menerapkan aspek multitenancy ini atau itu.
Tentu saja, bagian dasar dari mekanisme tersebut perlu diterapkan di platform. Misalnya saja pemisahan data yang sebenarnya. Di sinilah orang biasanya mulai membicarakan multitenancy. Namun pada akhirnya, model multitenancy “berjalan” melalui sebagian besar mekanisme platform dan memerlukan penyempurnaan, dan dalam beberapa kasus, pemikiran ulang.
Di tingkat platform, kami menerapkan mekanisme dasar yang tepat. Mereka memungkinkan Anda membuat aplikasi yang berjalan dalam model multitenancy. Namun agar aplikasi dapat “hidup dan bekerja” dalam model seperti itu, Anda perlu memiliki sistem untuk mengelola “aktivitas kehidupan” mereka. Teknologi 1cFresh dan lapisan logika bisnis terpadu di tingkat BSP bertanggung jawab atas hal ini. Sama seperti di gedung apartemen, infrastruktur menyediakan segala yang dibutuhkan penghuninya, demikian pula teknologi 1cFresh menyediakan semua yang mereka perlukan untuk aplikasi yang berjalan dalam model multitenancy. Dan agar aplikasi dapat berinteraksi dengan infrastruktur ini (tanpa modifikasi signifikan), “konektor” yang sesuai ditempatkan di dalamnya dalam bentuk subsistem BSP.
Dari sudut pandang mekanisme platform, mudah untuk melihat bahwa seiring dengan bertambahnya pengalaman dan pengembangan kasus penggunaan cloud “1C:Enterprise”, kami memperluas komposisi mekanisme yang terlibat dalam arsitektur ini. Mari kita beri satu contoh. Dalam model multitenancy, peran peserta layanan aplikasi berubah secara signifikan. Peran (tingkat tanggung jawab) mereka yang bertanggung jawab mengoperasikan aplikasi meningkat secara signifikan. Mereka perlu memiliki alat kontrol aplikasi yang lebih kuat. Karena pengguna aplikasi (penghuni) pertama-tama percaya pada penyedia yang bekerja sama dengannya. Untuk melakukan ini, kami menerapkan yang baru . Mekanisme ini memungkinkan administrator penyedia untuk membatasi kebebasan pengembang aplikasi hingga tingkat keamanan yang diperlukan - pada dasarnya, untuk mengisolasi pengoperasian aplikasi untuk setiap penyewa dalam kotak pasir tertentu.
Yang tidak kalah menarik adalah arsitektur untuk mengelola aplikasi yang beroperasi dalam mode multitenancy (yang diterapkan dalam teknologi 1cFresh dan BSP). Di sini, dibandingkan dengan model penerapan konvensional, persyaratan untuk otomatisasi proses manajemen meningkat secara signifikan. Ada lusinan proses seperti itu: membuat area data baru (“apartemen”), memperbarui aplikasi, memperbarui informasi peraturan, pencadangan, dll. Dan, tentu saja, persyaratan untuk tingkat keandalan dan ketersediaan semakin meningkat. Misalnya, untuk memastikan interaksi yang andal antara aplikasi dan komponen sistem kontrol, kami menerapkan teknologi sistem panggilan asinkron dengan pengiriman terjamin.
Poin yang sangat halus adalah cara mensosialisasikan data dan proses. Tampaknya sederhana (jika menurut seseorang) hanya pada pandangan pertama. Tantangan terbesarnya adalah keseimbangan antara sentralisasi data dan proses serta desentralisasi. Di satu sisi, sentralisasi memungkinkan Anda mengurangi biaya (ruang disk, sumber daya prosesor, upaya administrator...). Di sisi lain, hal itu membatasi kebebasan “penyewa”. Inilah salah satu momen “bifurkasi” aplikasi, ketika pengembang perlu memikirkan secara bersamaan tentang aplikasi dalam arti sempit (melayani satu “apartemen”) dan dalam arti luas (melayani semua “penyewa” sekaligus) .
Sebagai contoh dari “dilema” tersebut, kita dapat mengutip informasi peraturan dan referensi. Tentu saja, ada godaan besar untuk menjadikannya umum bagi semua “penyewa” rumah. Ini memungkinkan Anda menyimpannya dalam satu salinan dan memperbaruinya untuk semua orang sekaligus. Namun kebetulan beberapa warga membutuhkan perubahan khusus. Anehnya, dalam praktiknya hal ini terjadi, bahkan untuk informasi yang ditentukan oleh regulator (badan pemerintah). Ini ternyata menjadi pertanyaan yang sulit: bersosialisasi atau tidak? Tentu saja kita tergoda untuk menjadikan informasi tersebut bersifat umum bagi semua orang dan bersifat pribadi bagi mereka yang menginginkannya. Dan ini sudah mengarah pada implementasi yang sangat sulit. Tapi kami sedang mengerjakan ini...
Contoh lainnya adalah desain implementasi proses reguler (dieksekusi sesuai jadwal, diprakarsai oleh sistem kendali, dll). Di satu sisi, mereka dapat diimplementasikan untuk setiap area data secara terpisah. Lebih mudah dan nyaman. Namun, di sisi lain, granularitas yang begitu halus menimbulkan beban yang besar pada sistem. Untuk mengurangi beban, Anda perlu menerapkan proses yang disosialisasikan. Tapi mereka membutuhkan studi yang lebih cermat.
Tentu saja hal ini menimbulkan pertanyaan yang sangat penting. Bagaimana pengembang aplikasi dapat memastikan multitenancy? Apa yang perlu mereka lakukan untuk ini? Tentu saja, kami berusaha untuk memastikan bahwa beban masalah teknologi dan infrastruktur berada di pundak teknologi yang disediakan, dan pengembang aplikasi hanya memikirkan tugas-tugas logika bisnis. Namun seperti masalah arsitektur penting lainnya, pengembang aplikasi perlu memiliki pemahaman tentang cara bekerja dalam model multitenancy dan beberapa upaya akan diperlukan saat mengembangkan aplikasi. Mengapa? Karena ada poin yang tidak bisa diberikan oleh teknologi secara otomatis tanpa memperhitungkan semantik datanya. Misalnya definisi yang sama tentang batasan sosialisasi informasi. Namun kami berusaha menjaga agar kesulitan-kesulitan ini tidak terlalu besar. Sudah ada contoh implementasi aplikasi tersebut.
Poin penting dalam konteks penerapan multitenancy di 1C:Enterprise adalah kami membuat model hybrid di mana satu aplikasi dapat beroperasi dalam mode multitenancy dan mode normal. Ini adalah tugas yang sangat sulit dan menjadi bahan diskusi terpisah.
Sumber: www.habr.com