Multi tenancy atau multi instance?

Saya mencoba membangun solusi SaaS berbasis web, dan saya menemukan jalan di mana saya tidak yakin untuk menggunakan multi tenancy atau multi instance. Saya akan mencoba menggambarkan apa yang saya coba capai, dan masing-masing pendekatan kelebihan dan kekurangan (pendapat saya, sesuai dengan apa yang saya baca). Harap sertakan saran Anda jika saya melewatkan sesuatu dalam satu pendekatan di atas yang lain.

Aplikasi yang saya coba bangun adalah, seperti yang saya sebutkan, solusi SaaS di mana perusahaan dapat membuat akun mereka, dan setiap akun / perusahaan memiliki pengguna, pelanggan, produk, layanan ... dll. Setiap pengguna; yang merupakan karyawan perusahaan; terkait dengan satu akun / perusahaan hanya akan memiliki akses ke pelanggan, produk, dan layanan perusahaannya. Perusahaan dapat memiliki jumlah pelanggan, produk dan layanan yang tidak terbatas, sehingga setiap perusahaan harus memiliki pusat data sendiri.

Untuk itu saya memutuskan untuk membuat database bersama (menyimpan semua kredensial pengguna untuk keperluan login) dan beberapa skema bersama database (database per akun / perusahaan). Pada dasarnya, Multi Tenancy .

Kemudian seseorang menyarankan untuk menggunakan Multi Instance sebagai gantinya, di mana masing-masing perusahaan akan memiliki contoh aplikasi sendiri (yaitu kode, perpustakaan, database, kerangka kerja ... dll) benar-benar terpisah dari perusahaan lain. Ini kedengarannya lebih baik karena saya tidak harus mengurus lapisan tambahan di mana saya perlu memastikan bahwa setiap pengguna penyewa hanya memiliki akses ke data perusahaan mereka. Saya pikir itu baik untuk menyebutkan bahwa saya bergantung pada Docker untuk mencapai pendekatan ini (saya belum pernah menggunakannya sebelumnya), tapi saya pikir itu tidak memiliki fitur (lebih lanjut tentang itu nanti) yang akan saya butuhkan di masa depan (setidaknya saya tidak dapat menemukannya dengan sedikit pencarian).

Namun, setiap pendekatan datang dengan pro dan kontra, jadi saya tidak bisa membuat keputusan dengan pendekatan mana yang harus dilakukan. Berikut adalah daftar, tetapi terbuka dengan saya karena saya tidak memiliki pengetahuan di keduanya, sehingga mungkin ada sesuatu yang saya tidak sadari, atau solusi untuk masalah yang tidak saya temukan di web: [Setiap pendekatan memiliki daftar terurut yang saya ikuti perbandingan satu per satu]

Multi Tenancy :

1. Host bersama / perangkat keras, kode bersama, dan multi basis data.
2. Lebih mudah untuk memperluas fungsionalitas kode dan memperbaiki bug (kode bersama).
3. Lebih sulit untuk memperluas perangkat keras (bisa menggunakan layanan cloud), atau memindahkan basis data penyewa individu ke sistem lain tanpa melakukan perubahan pada kode.
4. Yang paling penting, seperti yang saya sebutkan sebelumnya, saya perlu menambahkan lapisan tambahan ke sistem untuk memastikan bahwa pengguna benar-benar milik perusahaannya, dan tidak mengakses informasi perusahaan lain.

Multi Instance :

1. Host / perangkat keras yang dibagikan atau tidak digunakan bersama, kode per instance, dan database per instance.
2. Lebih sulit untuk memperluas fungsionalitas atau memperbaiki bug (Saya tidak yakin apakah ada cara untuk melakukannya di Docker di mana Anda dapat menambahkan fungsionalitas / fitur ke satu instance atau wadah Docker, dan menyebarkannya ke yang lain).
3. Lebih mudah untuk memindahkan seluruh instance ke host / perangkat keras yang berbeda.
4. Sebagai contoh, saya tidak perlu mengurus layer itu karena setiap instance akan memiliki database sendiri.

Semua kelebihan dan kekurangannya berlebihan jika saya ingin melakukan sesuatu secara manual (seperti membuat contoh untuk setiap penyewa secara manual), dan itulah mengapa saya meragukan solusi Docker, kecuali ada cara untuk menyelesaikannya, yang mungkin merupakan masalah utama alasan pertanyaan. Saya akan sangat menghargai jika Anda akan menjawab pertanyaan dengan referensi untuk solusi, dan mengapa menurut Anda pendekatan ini lebih baik daripada yang lain.

Dalam hal itu akan membantu (mungkin?), Kami menggunakan Laravel sebagai kerangka kerja utama untuk back-end (semua TETAP).

Saya bertanya pada diri sendiri pertanyaan yang sama saat ini.

Saya condong ke arah solusi penyewaan tunggal multi-instance tetapi belum mengambil keputusan yang pasti. Izinkan saya membagikan beberapa pemikiran saya:

Keuntungan historis utama dari arsitektur multi-tenant adalah penggunaan sumber daya infrastruktur yang lebih baik , dengan saling menguntungkan (OS tunggal, Database tunggal, lapisan aplikasi tunggal) dan lebih baik menempati sumber daya tersebut (ketika satu pengguna pergi, pengguna lain dapat menggunakan sumber daya yang sama) .

Ini juga sangat menyederhanakan siklus hidup perangkat lunak : Anda menggunakan versi baru untuk Anda satu contoh, semua pelanggan diperbarui pada saat yang sama.

Namun tampaknya, bahwa kemajuan baru-baru ini dalam teknologi cloud membuat kelas pertama keunggulan sebagian besar tersedia dalam arsitektur multi-instance (instance-per-pelanggan) (saya berpikir secara khusus tentang platform seperti Jelastic di sini tapi saya yakin ada orang lain yang menyediakan fitur yang sama):

• PaaS berbasis kontainer
• Penyediaan dan penskalaan otomatis wadah (wadah elastis)

Jadi manajemen perangkat keras dan platform bukan lagi urusan penyedia Perangkat Lunak. Sumber daya disatukan jauh lebih efisien daripada sebelumnya di tingkat infrastruktur dan plaform .

Masih akan ada overhead untuk multi-instance (beberapa aplikasi dan middleware akan dijalankan N kali, bukan hanya satu), tetapi jauh lebih rendah daripada ketika menggunakan mesin (virtual) terpisah per instance. Basis data tetap dapat dibagikan (satu skema per instance, beberapa skema per server DB)

Juga:

• Otomatisasi pembuatan instance baru dimungkinkan melalui API PaaS
• Otomatisasi penyebaran versi baru dimungkinkan melalui API PaaS, dengan nol downtime (memerlukan beberapa pekerjaan untuk dilakukan)
• Scaling selalu keluar, tidak pernah naik. Kami tidak perlu khawatir tentang kumpulan data besar di tingkat instance.

Tentu saja, kita akan memerlukan semacam layanan pusat yang mengelola semua ini secara otomatis (mis. Pembuatan instance ketika pengguna baru membuat akun). Ini juga akan mengatur masalah pembayaran dan perizinan, interaksi antar instansi, dll. Layanan pusat ini mungkin cukup rumit dan sulit untuk dikembangkan, tetapi hal baiknya adalah kita tidak harus mengimplementasikannya di muka (sekarang kita tidak punya banyak sumber daya) sedangkan multi-tenant perlu dimasukkan ke dalam aplikasi dari awal.

Yang membawa saya pada keuntungan akhir dari pengembangan penyewa tunggal untuk proyek awal tahap awal (pra-investasi):

• Versi aplikasi yang sama (atau hampir sama) dapat digunakan di tempat baik sebagai alat virtual atau wadah buruh pelabuhan atau bahkan pada mesin yang dikelola pelanggan (beberapa perusahaan masih enggan terhadap Cloud dan mungkin membantu startup tahap awal untuk tidak mendorong pengadopsi awal yang penting)
• Lebih cepat untuk mengeluarkan produk dengan sumber daya terbatas (lapisan aplikasi dan skema basis data agak kurang kompleks), bisa mendapatkan produk "penyewa tunggal" tunggal bisu keluar (MVP) tunggal untuk pengadopsi awal dan untuk menunjukkan nilai bisnis aplikasi untuk calon investor, dan tambahkan semua otomatisasi cloud di kemudian hari
• Dapat dilihat sebagai argumen penjualan untuk pelanggan yang khawatir tentang keamanan data: data lebih baik dienkapsulasi karena setiap pelanggan memiliki skema sendiri atau bahkan database. Risiko "tumpahan" jauh lebih kecil

NB: Saya jelas berpikir di sini tentang aplikasi bisnis di mana pelanggan akan menjadi bisnis (masing-masing dengan beberapa pengguna individu) dan bukan individu. Tidak masuk akal untuk menjalankan instance aplikasi yang terpisah untuk setiap pengguna individu (atau bukan?)

Mendukung kedua opsi juga dimungkinkan (sekelompok penyewa di beberapa contoh).

Saya menyukai penyebab multi-instance dari isolasi alami. Setiap instance pelanggan berjalan dalam prosesnya sendiri dan datanya diisolasi di dalam basis datanya sendiri. Anda dapat memutakhirkan instance ke versi baru berdasarkan per pelanggan / instance saat diinginkan.

Sistem berbasis penyewa datang dengan risiko keamanan informasi. Cukup pertimbangkan betapa mudahnya melupakan klausa "WHERE tenantId = x". Alasan utama untuk menggunakan sistem yang dapat digunakan penyewa adalah kinerja, proses sangat berat, dengan berbagi proses yang berpotensi Anda dapatkan lebih banyak dari satu mesin. Ini lebih benar saya pikir dalam dunia 32-bit maka saat ini pada mesin 64 bit yang memiliki lebih banyak RAM.

Sistem multi-instance mungkin perlu sedikit lebih banyak alat untuk membuat dan mengkonfigurasi lingkungan seperti database dan contoh aplikasi web. Seseorang dapat berargumen bahwa Anda perlu memiliki skrip ini bagaimanapun juga untuk penyebaran instance tunggal Anda. Melakukan ini memiliki fasilitas lain juga seperti kemampuan untuk mengatur pengembangan dan pengujian lingkungan

Saya akan membiarkan kemampuan penyewa keluar sampai Anda dapat membuat kasus untuk itu (biaya rekayasa vs uang disimpan pada infrastruktur (perangkat keras) melalui proses berbagi).