Введение

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

Многоарендность (multitenancy) – это архитектура программного обеспечения, в которой единый экземпляр программного обеспечения работает на сервере и обслуживает несколько арендаторов. Системы, разработанные таким образом, являются "общими" (а не "выделенными" или "изолированными"). Арендатор – это группа пользователей, совместно использующих доступ к экземпляру программного обеспечения с определенными правами доступа. При многоарендной архитектуре программное приложение разрабатывается таким образом, чтобы предоставлять каждому арендатору выделенную часть экземпляра, включая его данные, конфигурацию, управление пользователями, индивидуальную функциональность и нефункциональные характеристики. Многоарендность противопоставляется многоинстанционной архитектуре, где отдельные экземпляры программного обеспечения работают от имени разных арендаторов. Некоторые эксперты считают многоарендность важной особенностью облачных вычислений.

Дифференциация от виртуализации

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

Дифференциация конкуренции

Некоторые компании активно продвигают принцип многопользовательской архитектуры и используют его как источник конкурентного преимущества. Использование многопользовательской архитектуры растет с каждым днем.

Экономия затрат

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

Агрегация данных/добыча данных

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

Сложность

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

Управление выбросами

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

Настройка

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

Брендинг: предоставление каждой организации возможности настраивать внешний вид приложения в соответствии со своим корпоративным стилем (часто называемым уникальным "оформлением"). Рабочие процессы: адаптация к различным рабочим процессам, используемым широким кругом потенциальных клиентов. Расширения модели данных: поддержка расширяемой модели данных, позволяющая клиентам настраивать элементы данных, управляемые приложением, для удовлетворения их специфических потребностей. Контроль доступа: предоставление каждой клиентской организации возможности самостоятельно настраивать права доступа и ограничения для каждого пользователя.

Качество обслуживания

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

Виртуализация

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