Поделиться через

Рекомендации по жизненному циклу клиента в мультитенантном решении

  • Статья

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

Пробные клиенты

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

Пробные версии содержат следующие уникальные рекомендации.

  • Требования к службе. Должны ли пробные версии соответствовать тем же требованиям к безопасности данных, производительности и уровню обслуживания, что и для полных клиентов?
  • Инфраструктура: следует ли использовать ту же инфраструктуру для пробных клиентов, что и для полных клиентов, или следует ли использовать выделенную инфраструктуру для пробных клиентов?
  • Миграция. Если клиенты приобретут службу после пробной версии, как они переносят данные из своих пробных клиентов в платные клиенты?
  • Процесс запроса: существуют ли ограничения по вопросу о том, кто может запросить пробную версию? Как предотвратить злоупотребление решением? Разрешить автоматическое создание клиентов пробной версии или участвует ли ваша команда в каждом запросе?
  • Ограничения. Какие ограничения нужно или нужно разместить на пробных клиентах, таких как ограничения времени, ограничения функций или ограничения производительности?

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

Подключение новых клиентов

При подключении нового клиента рассмотрите следующие вопросы:

  • Процесс: будет ли подключение самообслуживанием, автоматизированным или ручным процессом?
  • Место размещения данных: имеет ли клиент какие-либо конкретные требования к месту размещения данных? Например, существуют ли правила суверенитета данных?
  • Соответствие: должен ли клиент соответствовать любым стандартам соответствия (например, PCI DSS, HIPAA и т. д.)?
  • Аварийное восстановление: имеет ли клиент какие-либо определенные требования к аварийному восстановлению, например цель времени восстановления (RTO) или цель точки восстановления (RPO)? Отличаются ли они от гарантий, предоставляемых другим клиентам?
  • Сведения: какие сведения требуются, чтобы иметь возможность полностью подключиться к клиенту? Например, вам нужно знать юридическое имя своей организации? Вам нужен логотип компании для фирменной символики приложения, и если да, какой размер файла и формат вам нужен?
  • Выставление счетов: предоставляет ли платформа различные варианты ценообразования и модели выставления счетов?
  • Среды: требует ли клиент предварительно рабочих сред? И есть ли ожидания по доступности для этой среды? Является ли она временной (по запросу) или всегда доступна?

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

Обновление инфраструктуры клиентов

Вам потребуется рассмотреть вопрос о применении обновлений к инфраструктуре клиентов. Разные клиенты могут применять обновления в разное время.

Дополнительные сведения об обновлении развертываний клиентов см. в разделе "Обновления ".

Масштабирование инфраструктуры клиентов

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

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

Перемещение клиентов между инфраструктурой

Возможно, потребуется переместить клиентов между инфраструктурой по нескольким причинам, например:

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

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

Объединение и разделение клиентов

Это заманчиво думать о клиентах или клиентах как статические, изменяющиеся сущности. Однако в действительности это часто не так. Например:

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

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

Отключение клиентов

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

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

Деактивация и повторная активация клиентов

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

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

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

Соавторы

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

Автор субъекта:

  • Джон Даунс | Главный инженер программного обеспечения

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

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