Мультитенантность: как вырастить из одного приложения линейку независимых продуктов

В первую очередь мультитенантность нужна SaaS-продуктам, но не только. Этот подход применяется везде, где компания параллельно поддерживает несколько версий одного продукта.

Например:

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

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

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

Мультиарендность обеспечивает бизнес-пользователям независимость процессов

Данные из каждого бизнес-модуля поступают в выделенную среду. Процессы внутри продукта организованы таким образом, чтобы разные арендаторы не мешали друг другу:

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

Всё это позволяет мультиарендному продукту разграничивать данные и процессы как на уровне отдельных заказчиков, так и на уровне конечных пользователей.

Возможные варианты архитектуры мультитенантных приложений

1. Единый пул ресурсов, единое хранилище данных, одна инсталляция, разделение на уровне софта.

Такое приложение само понимает, куда пустить каких пользователей и какие функции им требуются. Этот сценарий обеспечивает оптимальное использование ресурсов, простое администрирование и развитие ПО.

Это мультиарендность на уровне ядра. Именно по такому пути стоит следовать, если вы создаёте мультитенантное приложение с нуля.

2. Единое хранилище данных, одна инсталляция ПО, пул ресурсов у каждого тенанта свой.

В этом случае разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу.

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

3. У каждого арендатора есть собственная инсталляция ПО, собственный пул ресурсов, собственное хранилище.

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

Такой сценарий подходит для приложений, которые разрабатывались без расчёта на мультиарендное использование. Это не мультитенантность в полном смысле этого слова – скорее, способ добиться части её возможностей, когда переделывать продукт оказывается слишком дорого или нецелесообразно по другим причинам.

Что нужно, чтобы сделать продукт мультитенантным

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

Разработка мультитенантных продуктов строится по принципу Feature-driven Development (Trunk-based Development). Разработчики создают новые функции, которые можно включать и выключать для разных групп пользователей.

Именно с перехода на Trunk-based Development мы рекомендуем начинать путь к мультитенантности. Это позволит разработчикам взглянуть на продукт как на набор функций, из которых можно составлять параллельные версии.