Мульти-аренда или мультиэкземпляр?

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

Как я уже говорил, приложение, которое я пытаюсь создать, представляет собой SaaS-решение, в котором компании могут создавать свои учетные записи, и у каждой учетной записи / компании есть свои пользователи, клиенты, продукты, услуги ... и т. Д. Каждый пользователь; кто сотрудник компании; связанные с одним аккаунтом / компания будет иметь доступ только к своим клиентам, продуктам и услугам своей компании. Компании могут иметь неограниченное количество клиентов, продуктов и услуг, поэтому у каждой компании должен быть свой собственный дата-центр.

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

Тогда кто-то предложил вместо этого использовать Multi Instance , где каждая компания будет иметь свой собственный экземпляр приложения (то есть код, библиотеки, базы данных, платформы и т. Д.), Полностью отделенный от других компаний. Это звучит лучше, поскольку мне не нужно заботиться о дополнительном слое, где я должен убедиться, что пользователи каждого арендатора имеют доступ только к данным своей компании. Я думаю, что это хорошо, чтобы упомянуть, что я полагаюсь на Docker для достижения этого подхода (я никогда не использовал его раньше), но я думаю, что в нем отсутствуют функции (подробнее об этом позже), которые мне понадобятся в будущем (по крайней мере, я не сделал не могу найти их с небольшим количеством поиска).

Тем не менее, каждый подход имеет свои плюсы и минусы, поэтому я не мог принять решение, какой подход пойти. Вот список, но со мной, так как мне не хватает знаний в обоих случаях, поэтому может быть что-то, о чем я не знаю, или решение проблемы, которую я не нашел в Интернете: [Каждый подход имеет упорядоченный список, за которым я следовал одно за другим сравнение]

Мульти Арендная плата :

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

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

1. Общий или неразделенный хост / оборудование, код на экземпляр и база данных на экземпляр.
2. Это труднее , чтобы расширить функциональные возможности или исправление ошибок (я не уверен , если есть способ сделать это в Докер , где вы можете добавить функциональность / функцию одного экземпляра или Докер контейнер, и развернуть его на другие).
3. Это проще , чтобы переместить весь экземпляр на другой хост / аппаратное обеспечение.
4. Как пример, мне не нужно заботиться об этом слое, поскольку каждый экземпляр будет иметь свою собственную базу данных.

Все преимущества и недостатки избыточны в случае, если я хочу что-то сделать вручную (например, создание экземпляра для каждого арендатора вручную), и поэтому я сомневаюсь в решении Docker, если только нет способа решить это, что, возможно, является основным причина вопроса. Буду признателен, если вы ответите на вопрос со ссылками на решения, и почему вы думаете, что этот подход лучше, чем другой.

В случае, если это поможет (возможно?), Мы используем Laravel в качестве основного фреймворка для серверной части (все RESTful).

Я задаю себе точно такой же вопрос в данный момент.

Я склоняюсь к единственному решению для нескольких экземпляров, но еще не принял окончательного решения. Позвольте мне поделиться некоторыми своими мыслями:

Основным историческим преимуществом мультитенантной архитектуры является более эффективное использование ресурсов инфраструктуры путем взаимного объединения (одна ОС, одна база данных, один уровень приложений) и лучшее использование указанных ресурсов (когда один пользователь отсутствует, другой может использовать один и тот же ресурс) ,

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

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

• PaaS на основе контейнеров
• Подготовка и автоматическое масштабирование контейнеров (эластичные контейнеры)

Таким образом, управление оборудованием и платформой больше не является заботой поставщика программного обеспечения. Ресурсы взаимовыгоднее, чем раньше, на уровне инфраструктуры и платформы .

Для нескольких экземпляров все равно будут накладные расходы (некоторые приложения и промежуточное ПО будут запускаться N раз вместо одного), но намного ниже, чем при использовании отдельной (виртуальной) машины для каждого экземпляра. В любом случае база данных может быть общей (одна схема на экземпляр, несколько схем на сервер БД)

Также :

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

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

Что подводит меня к последним преимуществам разработки одного арендатора для проекта запуска на очень ранней стадии (до инвестирования):

• Одну и ту же (или почти одинаковую) версию приложения можно развернуть локально либо в виде виртуального устройства, либо в качестве контейнера-докера, либо даже на управляемой клиентом машине (некоторые компании по-прежнему неохотно обращаются к облаку, и это может помочь запуску на ранней стадии не выталкивать важных ранних последователей)
• Быстрее вывести продукт с ограниченными ресурсами (прикладной уровень и схема базы данных являются довольно менее сложными), может вывести «тупой» единый экземпляр с одним клиентом первым (MVP) для первых пользователей и показать бизнес-ценность приложения потенциальным инвесторам, и добавьте всю автоматизацию облака позже
• Может рассматриваться как аргумент продажи для клиентов, обеспокоенных безопасностью данных: данные лучше инкапсулируются, поскольку каждый клиент имеет свою собственную схему или даже базу данных. Гораздо меньше риск "разлива"

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

Возможна также поддержка обоих вариантов (пул арендаторов в нескольких экземплярах).

Я поддерживаю многоэкземплярную причину естественной изоляции. Каждый экземпляр клиента работает в своих собственных процессах, а его данные изолированы в его собственной базе данных. При желании вы можете обновить экземпляры до новых версий для каждого клиента / экземпляра.

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

Системе с несколькими экземплярами, возможно, потребуется немного больше инструментов для создания и настройки среды, такой как базы данных и экземпляры веб-приложений. Кто-то может возразить, что вам нужно в любом случае использовать этот сценарий также для развертываний с одним экземпляром. У этого есть и другие преимущества, такие как возможность настройки сред разработки и тестирования.

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