Комментарии 6
1. Единый пул ресурсов, единое хранилище данных, одна инсталляция, разделение на уровне софта.
…
Именно по такому пути стоит следовать, если вы создаёте мультитенантное приложение с нуля.
Спорное утверждение. Очень. Этот путь самый дешевый с точки зрения затрат на железо, но чревато тем, что это путь в вечные баги.
Т.к. изоляция данных на уровне бизнес-логики, то нужно везде-везде учитывать идентификатор тенанта чтобы ни дай боже не подтянуть или не засветить (а тем более не потереть) данные другого тенанта. И такие баги не очень то легко уловимы, а бед от них много, включая ухудшение имиджа компании, судебные издержки и возможные штрафные санкции.
А как делать backup данных для каждого тенанта? Стандартные средства уже не помогут — добро пожаловать писать велосипед (тратить деньги).
А как обеспечивать отказоустойчивость (падает всё для всех сразу)?
Странно, но не рассмотрен сценарий:
Динамический пул ресурсов — у тенантов часть ресурсов может быть общая, а часть — разной.
раздельное хранилище данных — отдельные БД. Полная изоляция данных, стандартные схемы backup'а.
одна инсталляция — разделение на уровне софта.
При этом инсталляция может быть тоже динамической. Когда для части тенантов делается отдельная инсталляция (либо полностью, либо части решения).
раздельное хранилище данных — отдельные БД. Полная изоляция данных, стандартные схемы backup'а.
именно так и должно быть, в частности, если у тенантов разные требования к ПДн и, например, разное отношение к GDPR.
согласны, мы неточно выразились в тексте — такой вариант отчасти подразумевается в п.2: "разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу".
что касается проблем с бизнес-логикой, то они сильно сокращаются, если мультитенантность приложения закладывается изначально, на уровне архитектуры. если на эти рельсы переводить уже работающий продукт, то, да, код придётся изрядно перерыть
то они сильно сокращаются, если мультитенантность приложения закладывается изначально,
Они могут сокращаться только если используемый ORM позволяет сам автоматически править запрос так, чтобы вводить нужные ограничения по тенанту. Если же такой возможности нет и каждый разработчик должен помнить и руками выставлять такие ограничения — жди беды.
Поэтому мультитенантность на _общей_ базе данных — это заведомо ошибочный и дорогой путь.
Мультитенантность — она бывает разная. В частности в статье не озвучен вопрос кросс-мультитенантного взаимодействия. А такое бывает.
Или как сделать кастомизацию конкретного функционала под конкретного тенанта не дублируя при этом инстансы приложения (система плагинов с поддержкой мультитенантности). Это же касается и статических ресурсов (CSS, изображения, логотипы и т.д.).
А еще бывает так, что у каждого тенанта своя языковая локаль… В общем тема интересная, но раскрыта не полностью.
Разработка мультитенантных продуктов строится по принципу Feature-driven Development (Trunk-based Development). Разработчики создают новые функции, которые можно включать и выключать для разных групп пользователей.
Именно с перехода на Trunk-based Development мы рекомендуем начинать путь к мультитенантности. Это позволит разработчикам взглянуть на продукт как на набор функций, из которых можно составлять параллельные версии.
с чего это вдруг Git Flow (НЕ TBD) мешает Feature Driven Development? Можно увидеть развернутое обоснование? Используем Git Flow и фиче тогглы — брат жив.
Мультитенантность: как вырастить из одного приложения линейку независимых продуктов