Прошлое, настоящее и будущее мультиарендности

Сегодня мы можем добиться более надежной изоляции данных без недостатков более ранних форм выделенной инфраструктуры, пишет на портале The New Stack Стив Фентон, октонавт (специалист по работе с сообществом) компании Octopus Deploy, поставщика инструмента автоматизированного развертывания приложений.

Многопользовательское ПО появилось вместе с гибкой разработкой, моделью «ПО как сервис» (SaaS) и облачными вычислениями. Чтобы понять современную мультиарендность (multitenancy), мы должны рассмотреть, как ныне существующие практики изменили раннюю мультиарендность, и вникнуть в технологические достижения, которые заставляют пересмотреть подход к ней.

Давайте посмотрим, как создавалось ПО на рубеже веков. Скорее всего, один или два раза в год вы создавали «золотую» копию своего приложения. Она записывалась на CD-ROM, который использовался системными администраторами и конечными пользователями для установки ПО. Для корпоративных приложений вместо диска использовалось сетевое расположение, а вместо мастера установки — контрольный список.

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

SaaS и мультиарендность

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

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

Ниже приведены три модели хостинга, а также нераспределенные затраты, которые могут быть отнесены на одного арендатора.

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

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

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

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

Технические достижения

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

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

Сочетание этих разработок с опытом, накопленным за два десятилетия существования архитектуры мультиарендности, требует нового подхода. Экономические условия кардинально изменились.

Будущее мультиарендности

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

В этом новом подходе необходимо учитывать два аспекта: уровни совместного использования и детализацию решений на уровне компонентов. Если раньше мы рассматривали вопрос о том, является ли экземпляр приложения мультиарендным, то теперь мы рассматриваем каждый уровень, чтобы решить, должен ли он быть разделяемым. Мы можем объединить базу данных для конкретного арендатора с одним экземпляром приложения или обеспечить разделение только кодовой базы и конвейера CI/CD с автоматическим предоставлением инфраструктуры для конкретного арендатора.

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

Если расширить представление о мультиарендности и распространить его на ПО, инфраструктуру и конвейеры CI/CD, то можно создавать системы, использующие преимущества легких приложений для конкретных арендаторов, изолированных с помощью современной виртуализации и обращающихся к масштабируемым общим сервисам. Можно более продуманно подходить к вопросу о данных, которые должны быть доступны только для конкретного арендатора, и данных, которые не принадлежат только ему.

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

Подводя итог

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

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

Помимо изменений в технологиях, предприятия стали уделять больше внимания вопросам безопасности, о чем свидетельствует рост числа сертификаций по стандарту ISO 27001 с 2005 г.

Современную мультиарендность определяют решения об уровнях совместного использования с покомпонентной детализацией.