Багаторічна оренда або багатосторонність?

Я намагаюся створити веб-рішення SaaS, і я потрапив на дорогу, де я не впевнений, що я буду використовувати багаторічну оренду чи багатопримірник. Я спробую описати, чого я намагаюся досягти, і кожен підхід має переваги та недоліки (моя думка, відповідно до прочитаного). Будь ласка, додайте свої пропозиції, якщо я пропустив щось в одному підході над іншим.

Як я вже згадував, додаток, який я намагаюся створити, - це рішення SaaS, в якому компанії можуть створювати свої рахунки, і кожен рахунок / компанія має своїх користувачів, клієнтів, продуктів, послуг ... тощо. Кожен користувач; хто є працівником компанії; пов'язані з одним обліковим записом / компанією матимуть доступ лише до своїх клієнтів, продуктів та послуг своєї компанії. Компанії можуть мати необмежену кількість клієнтів, продуктів і послуг, тому кожна компанія повинна мати власний центр обробки даних.

Для цього я вирішив створити спільну базу даних (збереження всіх облікових даних користувачів для цілей входу) та кілька спільних схем баз даних (база даних на акаунт / компанію). В основному, Multi-оренду .

Тоді хтось запропонував замість цього використовувати Multi Instance , де кожна компанія матиме власний екземпляр програми (тобто код, бібліотеки, бази даних, фреймворки тощо), повністю відокремлені від інших компаній. Це звучить краще, оскільки мені не потрібно піклуватися про додатковий рівень, де мені потрібно переконатися, що користувачі кожного орендаря мають доступ лише до даних своєї компанії. Я думаю, що добре згадати, що я залежу від Докера, щоб досягти цього підходу (я його ніколи раніше не використовував), але я думаю, у нього відсутні функції (докладніше про ці пізніші), які мені знадобляться в майбутньому (принаймні, я не не знайду їх з невеликим пошуком).

Однак кожен підхід має плюси і мінуси, тому я не міг прийняти рішення, з яким підходом дійти. Ось список, але голий зі мною, оскільки мені не вистачає знань щодо них обох, тож може бути щось, про що я не знаю, або рішення проблеми, про яку я не знайшов в Інтернеті: [Кожен підхід має упорядкований список, за яким я послідував по одному порівнянню]

Багаторічна оренда :

1. Спільний хост / апаратне забезпечення, спільний код та багатозахисна база даних.
2. Це простіше , щоб розширити функціональні можливості коду і виправлення помилок (загальний код).
3. Це складніше розширити обладнання (можна використовувати хмарний сервіс), або перемістити базу даних індивідуального орендаря на іншу систему , не роблячи змін в коді.
4. Найголовніше, як я вже згадував раніше, мені потрібно додати додатковий шар у систему, щоб переконатися, що користувач насправді належить його компанії та не має доступу до інформації іншої компанії.

Мультиекземпляр :

1. Спільний або незаповнений хост / обладнання, код на примірник та базу даних на примірник.
2. Це важче , щоб розширити функціональні можливості або виправлення помилок (я не впевнений , якщо є спосіб зробити це в Докер , де ви можете додати функціональність / функцію одного примірника або Докер контейнер, і розгорнути його на інші).
3. Це простіше , щоб перемістити весь екземпляр на інший хост / апаратне забезпечення.
4. Як приклад, мені не потрібно піклуватися про цей шар, оскільки кожен екземпляр матиме власну базу даних.

Усі переваги та недоліки є зайвими, якщо я хочу зробити що-небудь вручну (як створення екземпляра для кожного орендаря вручну), і тому я сумніваюся в рішенні Докера, якщо немає способу вирішити це, що, можливо, є головним причина питання. Буду вдячний, якщо ви відповісте на питання із посиланням на рішення, і чому ви вважаєте, що такий підхід кращий за інший.

У випадку, якщо це допоможе (можливо?), Ми використовуємо Laravel як основний каркас для бек-енду (все RESTfully).

Я задаю собі саме таке питання на даний момент.

Я схиляюсь до рішення багаторічного одиничного найму, але ще не прийняв остаточного рішення. Дозвольте поділитися своїми думками:

Основна історична перевага архітектури, яка має багато орендарів, - це краще використання інфраструктурних ресурсів шляхом взаємної комбінації (одна ОС, одна база даних, єдиний рівень додатків) та кращого використання цих ресурсів (коли один користувач відсутній, інший може використовувати той самий ресурс) .

Це також значно спрощує життєвий цикл програмного забезпечення : ви розгортаєте нові версії для вас одним екземпляром, усі клієнти оновлюються одночасно.

Однак здається, що недавні досягнення в галузі хмарних технологій роблять перший клас переваг значною мірою доступними в архітектурі з декількома екземплярами (екземпляр на замовника) (я тут думаю саме про платформу на зразок Jelastic, але я впевнений, що є й інші, надайте ті самі функції):

• PaaS на основі контейнерів
• Надання та автоматичне масштабування контейнерів (еластичних контейнерів)

Тож управління апаратом та платформою вже не є проблемою постачальника програмного забезпечення. Ресурси об'єднуються набагато ефективніше, ніж раніше, на інфраструктурному та платформенному рівнях .

Ще буде накладні витрати на багатопримірники (деякі програми та проміжне програмне забезпечення буде запущено N разів замість лише одного), але набагато нижче, ніж при використанні окремої (віртуальної) машини на примірник. База даних може бути загальнодоступною (одна схема на примірник, кілька схем на сервері БД)

Також:

• Автоматизація створення нових примірників можлива через PaaS API
• Автоматизація розгортання нових версій можлива через PaaS API, з нульовим простоєм (потрібно виконати певну роботу)
• Масштабування завжди поза, ніколи не піднімається. Нам не потрібно турбуватися про величезні набори даних на рівні екземпляра.

Звичайно, нам знадобиться якась центральна служба, яка керує всім цим автоматично (наприклад, створення примірника, коли новий користувач створює обліковий запис). Це також керувало б питаннями оплати та ліцензування, взаємодією між інстанціями тощо. Ця центральна служба може бути досить складною і складною для розвитку, але добре те, що нам не доведеться її впроваджувати заздалегідь (тепер у нас не так багато ресурс), тоді як мульти-орендарів потрібно буде запускати в додаток з самого початку.

Що підводить мене до кінцевих переваг розробки одиночного орендаря на дуже ранній стадії (до інвестування) стартового проекту:

• Таку ж (або майже однакову) версію програми можна розмістити в локальних приміщеннях як віртуальний пристрій або контейнер докера або навіть на машині, керованій клієнтом (деякі компанії все ще неохоче ставляться до Хмари, і це може допомогти запуску на ранній стадії не витіснити важливих ранніх усиновителів)
• Швидше отримати продукт з обмеженими ресурсами (прикладний рівень та схема бази даних є досить менш складною), ви можете отримати "тупу" єдиний екземпляр одного продукту-орендаря першим (MVP) для ранніх користувачів і показати ділову цінність програми потенційним інвесторам, а потім додайте всю хмарну автоматизацію
• Можна розглядати як аргумент продажу для клієнтів, які переживають за безпеку даних: дані краще інкапсульовані, оскільки кожен клієнт має власну схему чи навіть базу даних. Набагато менший ризик "розливу"

NB: Я, очевидно, маю на увазі бізнес-додаток, де клієнтами будуть бізнес (кожен з кількома окремими користувачами), а не фізичні особи. Не було б сенсу запускати окремий примірник програми для кожного окремого користувача (чи так?)

Можлива також підтримка обох варіантів (пул орендарів у кількох випадках).

Я прихильник багатоаспектної природної ізоляції. Кожен екземпляр замовника працює у власних процесах, і його дані виділяють у власній базі даних. Ви можете оновити екземпляри до нових версій на основі клієнта / екземпляра за бажанням.

Системи, що базуються на орендарях, мають ризик інформаційної безпеки. Поміркуйте, як легко забути пункт "WHERE tenantId = x". Основною причиною використання системи, яка працює з орендарем, буде продуктивність, процеси мають велику вагу, поділяючи процес, ви потенційно можете отримати більше з однієї машини. Це було більш правдиво, я думаю, що в 32-бітовому світі, то зараз це на 64-бітних машинах, які мають набагато більше оперативної пам'яті.

Багатомобільній системі, можливо, знадобиться трохи більше інструментів для створення та налаштування середовища, наприклад, баз даних та екземплярів веб-додатків. Можна стверджувати, що вам потрібно мати сценарій так само для ваших розгортань. Для цього є інші переваги, як і можливість налаштування середовищ для розробки та тестування

Я б не залишав можливості орендаря виходити, поки ви не зможете скласти справу про це (вартість інжинірингу та гроші, заощаджені на (апаратній) інфраструктурі за допомогою обміну процесами).