Имя тенанта что это
igorsmolin
Знакомимся с Office/Microsoft 365. Часть 1. Создаем тенант.
Что и зачем это?
Цикл статей представляет из себя перевод официальной документации, посвященной изучению и тестированию облачной площадки Microsoft, а также различные дополнения от автора. Сама документация в оригинале доступна здесь.
Структура статьи
Ниже приведена общая архитектура статей для демонстрации базовых функций от Microsoft. Модель состоит из четырех больших блоков:
Структура наших статей построена на документации Microsoft, однако будет отличаться. Ее можно поделить на несколько ключевых разделов:
В этой части мы сфокусируемся на первых трех пунктах.
В чем разница между Office 365 и Microsoft 365?
В определении этих двух понятий может возникать путаница. Особенно, учитывая тот факт, что Office 365 входит в состав Microsoft 365. Однако на деле все гораздо проще, чем кажется на первый взгляд.
Office 365 — набор классического и облачного ПО для повышения продуктивности пользователей распространяющийся по подписке. В состав Office 365 входит немалое количество ПО, которое, наверное, часто забывают сами ребята из Microsoft. 🙂
Вот неполный список поставляемого ПО:
Microsoft 365 — расширенный набор сервисов, включающий в себя Office 365. Помимо уже названного ПО, в состав Microsoft 365 входит: Windows 10 Enterprise, Enterprise Mobility + Security. Как и в случае с Office 365, распространяется по подписке.
Создаем новый тенант
Под понятием tenant подразумевается учетная запись организации в рамках которой предоставляются облачные услуги.
Процедура создания и настройки займет три этапа, которые тоже могут разбиваться на дополнительные этапы. Начнем.
Получаем триальную подписку E5
Предварительно нам понадобится создать учетную запись Microsoft. Переходим по ссылке — https://outlook.com/ и регистрируем новую учетную запись.
Далее переходим по ссылке — https://aka.ms/e5trial и регистрируем учетную запись для получения триальной подписки E5. Процедура состоит из четырех этапов.
1 — Указываем почтовый контакт, который мы регистрировали ранее.
Указываем недавно созданную электронную почту
2 — Заполним информацию о себе.
Также на этом этапе нам потребуется привязать номер телефона и пройти проверку.
3 — Создаем доменное имя для работы в Office 365.
Также нам необходимо создать учетную запись администратора.
4 — Краткое резюме о выполненной работе.
Office 365 предложит нам перейти к дальнейшей настройке. Вернемся к ней чуть позже. А пока — нажмем Перейти к программе установки, укажем пункт Продолжить использование домена для электронной почты и входа и выберем пункт Выйти и продолжить позже.
Конфигурируем Office 365
На этом этапе мы займемся добавлением пользователей и назначением им лицензии Office 365 E5.
Переходим по ссылке — https://portal.office365.com. Вводим ранее созданную учетную запись администратора и попадаем в центр администрирования Office 365.
Переходим в раздел Пользователи > Активные пользователи. Перед нами единственная учетная запись в нашем тенанте.
Кликнем Добавить пользователя. Введем необходимую информацию.
Назначим пользователю триальные лицензии.
После этого, мы увидим в списке вновь созданного облачного пользователя.
Добавляем домен в Office 365
Переходим во вкладку Параметры > Домены. Здесь мы увидим подключенные домены в нашем тенанте.
Выберем кнопку Добавить домен и укажем свое доменное имя.
Мастер настройки сообщит нам о необходимости проверки прав на этот домен. От нас потребуется добавить TXT запись.
После проверки существования записи со стороны Microsoft, нам будет предложено создать дополнительные, необходимые для корректной работы сервисов Microsoft, DNS записи. Пока что нам достаточно просто привязать домен, поэтому мы проигнорируем предложение и завершим процедуру.
Нашей конфигурацией Office 365 уже можно пользоваться. Как минимум мы можем использовать классические и облачные версии приложений Office 365. Однако, скорее всего, пользователей у вас больше, чем один. Также, вероятно, что у вас есть свой приземленный домен Active Directory, где хранится информация о пользователях.
Далее мы узнаем, как можно автоматически синхронизировать пользователей из локального AD в облако, но перед этим нам понадобится смоделировать необходимую инфраструктуру.
Разворачиваем дополнительную инфраструктуру
Для решения задачи синхронизации учетных записей, которая возникла в прошлом разделе, а также для изучения части функций Office 365 нам потребуется дополнительная приземленная инфраструктура. В этой статье мы развернем тестовое окружение в виде нескольких виртуальных машин.
Для этого предлагаю воспользоваться готовыми сценариями автоматизации развертывания Active Directory под названием AD_1.0 или AD_1.1 — https://github.com/mdcowse/vagrant-sandboxie. Именно такой вариант был использован при подготовке к статье. Если нужны подробности или просто интересно понять как оно работает — рекомендую почитать эту статью.
После развертывания этого сценария в нашем распоряжении будут две виртуальных машины: контроллер домена и клиентский компьютер.
Конечно, никто не мешает развернуть необходимую инфраструктуру самостоятельно любым другим способом.
Устанавливаем Azure AD Connect
Возвращаемся к задаче синхронизации учетных записей между локальным AD и Office 365 и познакомимся с инструментом Azure AD Connect.
Azure AD Connect — дополнительное ПО, позволяющее решать задачи которые возникают при интеграции приземленного экземпляра Active Direcroty и облачного Azure Active Directory. В этой статье мы обсудим установку инструмента и одну из его функций — Password Hash Synchronization.
Учитывая, что в нашем тестовом окружении не такой большой выбор, куда можно установить программу, развернем его на контроллере домена.
Перейдем по ссылке — https://aka.ms/aadconnect и скачаем ПО. Немного пройдемся по мастеру установки для более подробного описания и понимания что происходит под капотом в процессе инсталляции, поэтому нажимаем кнопку Customize.
На первом этапе мы выбираем метод аутентификации пользователей. Указываем первый вариант — Password Hash Synchronization. Использование этой опции позволит нам решить задачу синхронизации учетных записей пользователей в облако.
На следующем этапе нам потребуется ввести учетные данные администратора тенанта Office 365 для подключения к Azure AD.
Переходим к настройкам синхронизации. Укажем локальный домен и выбираем Add Directory.
Создаем новый аккаунт для задачи синхронизации в Azure AD. Указываем для этого учетные данные администратора.
В случае успеха установщик сообщит нам об этом и мы сможем перейти к следующему этапу.
Переходим к настройке входа в Azure AD. Установщик предлагает нам выбрать домен, который будет синхронизирован из локальной AD и использован для входа нашими пользователями при входе в облачные сервисы Office 365.
Обратите внимание, что название домена party.hard мы не сможем выбрать, т.к в интернете нет информации о нем по причине отсутствия зоны hard. В таком случае мы можем создать в AD UPN-суффикс igorsmolin.ru для нашего домена party.hard и использовать его для входа в Office 365. Процедуру проверки домена мы уже проходили ранее, поэтому статус — Verified.
Также мы можем выбрать ключевой атрибут пользователя, на основе которого, будет генерироваться учетная запись в облаке.
Далее идут настройки фильтрации Organizational Unit локальной Active Directory. Чтобы не синхронизировать все подряд, мы можем явно указать OU для синхронизации объектов.
Остальные настройки пока можно пропустить.
Мы готовы к установке Azure AD Connect. После установки ПО будет выполнена начальная синхронизация учетных записей.
Как итог — мы увидим подобное сообщение.
Предлагаю проверить результаты синхронизации. Перед ее выполнением в локальном Active Direcotry существовала учетная запись — user1. В качестве имени домена в учетной записи указан UPN-суффикс igorsmolin.ru.
Зайдем в портал администрирования Office 365 во вкладку Пользователи > Активные пользователи.
Теперь попробуем зайти в Office 365 используя синхронизированные учетные данные.
Вход был выполнен успешно. Похоже, что нам удалось установить Azure AD Connect и синхронизировать учетные данные между локальными и облачными экземплярами Active Directory.
Это была первая часть цикла статей по облачным сервисам Microsoft. Сегодня нам удалось разобраться в базовых понятиях, развернуть свой тенант, а также необходимую инфраструктуру и выполнить синхронизацию учетных данных. Все это послужит базой для изучения функций в следующих частях, где мы сфокусируемся на изучении функций Office и Microsoft 365.
Multi-tenant Архитектура Данных
Привет Хабр! 
Давным-давно, были компьютеры размером в несколько этажей, и несколько операторов работали с одни мощным ЭВМ. Затем это чудо техники смогли уменьшить до настольного размера и поставить его в каждый дом. Теперь опять, новшеством считаются «облачные вычисления», хм… всё ведь сводится к нескольким терминалам и одной мощной ЭВМ датацентру. Что ж, подождём, пока датацентр гугла уменьшат до размера ноутбука…
Введение
После 2000-го года в жизнь разработчиков и архитекторов, заказчиков и многих других, имеющих отношение к ИТ, вошёл термин-акроним SaaS (software as a service). Суть SaaS сводится к тому, что Исполнитель разрабатывает ПО, размещает его на серверах, поддерживает его работоспособность, безопасность, доступность для заказчиков (обычно во множественном числе) и естественно сам платит за сервера и иные расходы.
Клиент платит за использование сервисов и не думает о покупке серверов и их обслуживании. Такой подход дешевле для Клиента и окупается для Исполнителя (т.к. решает проблемы с лицензированием и пиратством, и самое главное один сервис может предоставляться нескольким клиентам). Однако Клиент должен доверять Исполнителю, т.к. все его данные располагаются далеко-далеко.
Естественно, что такое решение заставило искать компромиссы в области размещения и разделения данных.
Так как рассказывать что-либо без примера достаточно проблематично, рассмотрим абстрактную задачу.
Задача
Для Клиента удобство такой системы очевидно – сотрудники компании заходят в систему и видят все необходимые данные для более выгодной и удобной работы. Исполнитель же может не беспокоиться за несанкционированное использование разработанной системы, а самое главное, эту систему можно одновременно использовать для нескольких Клиентов, так как задача одна и та же, то и структура базы данных так же будет идентична. И вот тут дерево решений разветвляется, но об этом позже.
Итого: есть несколько заказчиков, которые пишут и читают в базу данных и ничего не знают друг о друге. Необходимо обеспечить их изоляцию друг от друга и эффективное использование аппаратуры и ПО.
Решение: MULTI-TENANT
Первое решение, которое приходит в голову, чтобы разделить данные разных заказчиков будем хранить их в разных базах данных (изолированный подход). Как альтернатива, можно хранить все данные в одной базе данных, введя дополнительное поле TenantID, по которому их различать (общий подход). Не смотря на всю двоичность логики, решений оказалось не два, а больше. Данный факт весьма убедительно представлен на картинке, позаимствованной из msdn’а:
Разные Базы Данных
Данное решение – первое, что приходит в голову, является простейшей реализацией разделения данных.
При таком подходе код разделяется между клиентами (используется общие файлы UI и бизнес логики), а данные логически (а возможно и физически) разделяются между собой.
Преимущества:
Недостатки:
В итоге, несмотря на высокую цену, это наиболее правильное решение для клиентов, главной целью которых является безопасность, и которые готовы заплатить (например, банки).
Общая база данных, разные схемы
Итак, мы решили хранить всё в одной базе данных, как это сделать без введения дополнительного поля TenantID? Хранить информацию от разных клиентов в разных таблицах. Для реализации этого способа нам помогут схемы(schema). По сути, схемы это “пространства имён”, которые содержат определённые ресурсы (таблицы например), и на которые можно давать определённые разрешения.
Преимущества:
Недостатки:
Общая база данных, общая схема
Самый третий вариант – хранить всё в одной базе данных и в общих таблицах. Для реализации такого варианта необходимым условием будет введение дополнительного поля TenantID (либо CustomerID как кому нравится) для разделения информации между заказчиками.
Преимущества:
Недостатки:
Суровая реальность
Так как первый вариант (разные базы данных) могут себе позволить не все, то наиболее целесообразным будет использовать вариант с общей базой данных. Но на этом пути нас ждёт несколько неожиданных внезапностей. 
Итак, выберем самый дешёвый вариант как рабочий. Представим, что базы у нас не падают, а жёсткие диски вечны. И вот наша система целый год работает успешно и все довольны, накопились гигабайты данных, и внезапно всё начинает работать медленнее и медленнее. СУБД это не чёрный ящик, её тоже надо настраивать. Проблема банальна – данные пишутся в одну таблицу, в один файл, а значит, и на винчестер попадают друг за другом. А теперь представим, как происходит выборка данных для одного клиента: головка винчестера (да простят меня поклонники SSD винчестеров) медленно читает в буфер всё подряд, а записи с нужным TenantID могут появиться ещё не скоро. А теперь представьте, что нам надо перенести в архив данные одного клиента (удалив их в нашей базе).
Индексы скажете вы? – Дорого скажу я. Кроме того, даже при наличии индексов, данные всё равно будут лежать в разных частях диска.
Есть весьма элегантное решение, доступное в enterprise версиях СУБД называемое Partitioning (Секционирование), суть его можно посмотреть на рисунке:
С partitoning, данные одного клиента располагаются последовательно, в отдельном от остальных месте. Для простоты можно считать, что данные каждого клиента лежат на отдельном логическом диске. Данная возможность поддерживается на уровне СУБД, так что писать драйверов и изобретать велосипедов не нужно.
Мультитенантная архитектура для SaaS приложений
Что такое мультитенантность (multitenancy)?
Самыми простыми словами мультитенантность — это возможность изолированно обслуживать пользователей из разных организацией (т.е. независимых подписчиков SaaS) в рамках одного сервиса (одной инсталляции или развертывания). Основным здесь является соблюдение изолированности подписчиков друг от друга. Действительно, клиенты не обрадуются, если данные, которые они хранят в вашем SaaS приложении, будут доступны при поиске для других клиентов. Это явное нарушение изолированности.
Мультитенантность бывает разной, например, ее можно представить следующей схемой:
Сейчас очень часто мультитенатность фигурирует совместно с терминов облачные вычисления, но фактически мультитенантность в некотором своем проявлении была актуальной и раньше, например, для хостинг-площадок. Например, SQL Server и IIS позволяют администрировать базы и сайты независимо: когда вы заходите в IIS Management Console удаленного сервера то, вы видите только свои сайты, аналогично для SQL Server – в Management Console вы видите и управляете только своей базой. Это так же можно назвать вариацией мультитенантности – все клиенты хостинга живут на одном веб-сервере или сервере базы данных, но работают только со своими узлами\элементами\данными. Мультитенантность так же является неотъемлемой частью многих ERP и CRM систем (Multi-tenant versus Single-tenant ERP – a comparison).
Для своего SaaS приложения позаботиться о мультитенантности уже предстоит вам, хотя в этом вам могут помочь имеющиеся фичи или готовы компоненты, например, которые предоставляют PaaS-платформы. Вообще говоря, проще сразу проектировать приложение с фокусом на мультитенантность, чем потом приложение «перепроектировать» для ее поддержки.
В чем преимущества мультитенантного подхода?
Кроме мультитенантной архитектуры бывает выделенная архитектура (single-tenant), когда для каждого пользователя предоставляется собственная инфраструктура (это характерно для не SaaS приложений): логические или физические сервера. Для облачных сервисов подобный подход может быть не оправданным, т.к. для каждого подписчика выделяются фиксированные ресурсы, независимо от того, сколько их требуется (а это увеличивает конечную стоимость SaaS подписки для пользователя, в итоге может оказаться, что стоимость решения будет выше, чем у конкурентов). Подобная выделенная архитектура для облачных сервисов может быть оправдана только для premium подписок и т.д.
Мультитенантная архитектура является кардинальным способом снижения стоимости вычислительных ресурсов и хранилища для SaaS решений: за счет минимально необходимого количества используемых ресурсов (разделяемой инфраструктуры) и их максимальной загрузки. Наиболее ощутимой выгода становится при сочетании мультитенантности и «неограниченного масштабирования» (когда нет необходимости затрачивать дополнительные средства на провиженинг дополнительных ресурсов или добавления новых серверов). Неограниченное масштабирование можно попробовать реализовать своими силами или использовать облачные PaaS платформы.
Источник: Cloud Computing: Sharpen Your SAAS Smarts Before Committing to the Cloud
И все-таки что выбрать выделенную модель или мультитенантную?
Мультитенантность тоже бывает разной, например, на уровне данных, на уровне ресурсов и т.п. И все это можно комбинировать, использовать все вместе или вообще не использовать.
Источник: Multi-Tenant Data Strategies for Windows Azure – Part 1
Поэтому нет правильного или неправильного ответа на вопрос выбора того или иного подхода, но есть ряд факторов, которые могут повлиять на ваш выбор. Расскажу далее об этих факторах на примере платформы Widows Azure, хотя большинство из них применимы и для других облачных платформ.
Архитектура
1. В мультитенантном приложении вы всегда можете эмулировать выделенный режим (один подписчик), тогда как возможности расширить выделенное приложение до нескольких независимых подписок обычно отсутствует.
2. Отказоустойчивость. Мультитенатное приложение более уязвимо к сбою экземпляра, чем выделенное приложение. Сбой выделенного развертывания влияет только на клиента, который использует данное приложение, тогда как сбой мультитенатного приложения затронет всех клиентов.
Уменьшить негативные последствия при сбое можно с помощью нескольких экземпляров мультитенатного приложения или его части. Например, Windows Azure может уменьшить этот риск, позволяя выполнить развертывание нескольких идентичных копий приложения за счет использования нескольких экземпляров ролей (такое подход как раз в полной мере реализует мультитенатную модель с несколькими экземплярами). Windows Azure автоматически распределяет нагрузку по обработке запросов между данными экземплярами ролей, следовательно, приложение должно быть разработано таким образом, чтобы оно корректно функционировало при использовании нескольких экземпляров. Например, если приложение использует состояние сеанса, необходимо убедиться, что каждый экземпляр веб-роли может получить доступ к состоянию. Так же Windows Azure выполняет постоянный мониторинг всех экземпляров ролей и автоматически перезапускает экземпляры при возникновении сбоя.
Для некоторых приложений может быть не целесообразным совместное использование всеми клиентами одного мультитенантного развертывания. Например, может понадобиться сгруппировать клиентов на основе функциональности приложения, которую они используют, а затем оптимизировать каждый экземпляр для каждой из созданных групп. В этом случае вам может потребоваться две или более копии мультитенатного приложения, развернутого даже в различных подписка Windows Azure.
3. Соглашение об уровне обслуживания (SLA). Вы можете предлагать различные соглашения об уровне обслуживания (SLA) для различных уровней подписки на сервис. Если подписчики с разными соглашениями об уровне обслуживания совместно используют одно мультитенантное развертывание, следует обеспечить самый высокий SLA.
4. Правовая и нормативная среда. Для некоторых приложений необходимо учитывать конкретные нормативные или юридические вопросы. Для этого могут потребоваться различия в функциональных возможностях, отображение в пользовательском интерфейсе юридических соглашений, обеспечение отдельных баз данных или областей хранилища для каждого конкретного подписчика, расположение сервиса и хранилища в конкретном географическом регионе. При таких условиях может потребоваться реализовать отдельные мультитенантные развертывания для различных групп пользователей, либо строго выделенный режим для каждой подписки на сервис.
5. Проверка подлинности и авторизации. Для приложения в облаке может использовать своя собственная система проверки подлинности и авторизации, в этом случае подписчикам приложения потребуется создавать учетные данные для всех пользователей приложения. С другой стороны клиенты могут предпочесть использовать существующую у них систему проверки подлинности и избежать необходимости создавать новые учетные данные для приложения. Второй вариант для мультитенантного приложения означает необходимость поддержки нескольких поставщиков проверки подлинности, а так же может потребовать сопоставление схемы авторизации приложения в облаке со схемой локальной инфраструктуры авторизации. В Windows Azure для настройки проверки подлинности и авторизации используется Access Control Services, с помощью которой можно реализовать аутентификацию формами, через Active Directory, через LiveId, Google, Facebook и др. OpenID провайдерами. Если речь идет об интеграции с Active Directory и настройке федерации между AD подписчика и сервисом, то, скорее всего, это так же может потребовать выделенного развертывания.
Управление жизненным циклом приложения
1. Ведение базы кода. Для компаний-разработчиков ведение отдельных баз кода для различных клиентов сопряжено с увеличением расходов на поддержку и обслуживание, а так же с проблемами при отслеживании того, какие клиенты какую версию используют. Это может привести к появлению ошибок, которые приведут к дополнительным затратам. Мультитенатная система с одним логическим развертывание гарантирует одну базу кода для всего приложения. Вы можете по-прежнему поддерживать одну базу кода с выделенной моделью с несколькими развертываниями, но может появиться желание (с долгосрочными последствиями) разветвить код для различных клиентов. В некоторых сценариях, где существует потребность в тонкой настройке приложений, несколько баз кода могут быть приемлемым вариантом, но, прежде чем выбрать этот путь, необходимо изучить возможность применения пользовательских конфигураций или пользовательских бизнес-правил на уровне стандартной настройки системы (например, через интерфейс). Если должно быть несколько баз кода, то приложение должно быть структурировано таким образом, чтобы пользовательский код ограничивался только минимально необходимым числом пользовательских компонентов.
2. Обновления приложения. Мультитенантное приложение позволяет одновременно распространить обновления на всех клиентов. Этот подход означает, что обновляется только один логический экземпляр, что позволяет уменьшить усилия по обслуживанию. Кроме того, у вас есть уверенность, что все клиенты используют последнюю версию приложения, что упрощает поддержку.
Например, домены обновления (Update Domain) Windows Azure упрощают этот процесс, позволяя распространять обновления на несколько экземпляров роли без остановки приложения. Если у клиента есть операционные процедуры или программное обеспечение, привязанные к конкретной версии приложения, то любые обновления должны быть скоординированы с клиентом.
Для сокращения рисков, связанных с обновлением приложения, вы можете реализовать процедуру последовательного обновления: на первой фазе происходит обновления приложения для небольшой группы пользователей, на второй фазе, если с новой версией не возникло никаких сложностей, обновления распространяются на оставшихся пользователей.
3. Мониторинг приложения. Мониторинг одного развертывания приложения проще, чем мониторинг нескольких развертываний. В выделенной модели с несколькими развертываниями для любого нового экземпляра роли необходимо устанавливать настройки среды мониторинга, в результате чего увеличивается сложность всего процесса. Если будет решено использовать последовательное обновление, мониторинг будет также более сложным, поскольку необходимо одновременно отслеживать две версии приложения и использовать данные мониторинга для оценки стабильности версии приложения.
4. Использование сторонних компонентов. Если будет решено использование мультитенантную архитектуру, необходимо оценить насколько хорошо в таком режиме будут работать сторонние компоненты. Что убедиться, что сторонний компонент может работать в мультитенантной архитектуре, возможно, потребуется выполнить некоторые дополнительные действия.
5. Провиженинг тестового доступа и новых клиентов. Провиженинг области для нового клиента или инициализация бесплатного пробного использования службы в значительной степени упрощается, если данный процесс предполагает только изменение конфигурации. Для выделенной модели требуется развернуть новый экземпляр приложения для каждого клиента, включая тех, которые используют бесплатную пробную версию. Хотя этот процесс вы можете автоматизировать, это будет значительно сложнее, чем изменение или создание данных конфигурации в мультитенантном приложении.
Windows Azure позволяет сделать процесс провиженинга автоматическим (провиженинг сервисов, сертификатов, хранилища и т.п.), для этого необходимо использовать REST Service Management API. Программная реализация всех необходимых действий очень актуальна, т.к. позволяет пользователям зайти на портал, нажать кнопку «попробовать» и получить через несколько минут временную подписку (trial), созданную специально для них. Так же это актуально при размещении приложения в Marketplace’ах, когда пользователи могут сначала попробовать приложение, а потом его приобрести и продолжить использование – и никаких звонков или писем службу поддержки.
Настройка приложения
2. Настройка приложения клиентом. Разрешение клиентам загружать собственный код увеличивает риск сбоя приложения, потому что снижается уровень контроля выполняемого приложением кода. Поэтому многие SaaS поставщики накладывают ограничение на использование пользовательского кода в мультитенантных приложениях (т.к. сбой повлияет на всех пользователей). В большинстве случаев это просто запрещено, иногда код разрешен, но его функциональные возможности сильно урезаны. Разрешение клиентам загружать код или скрипты также увеличивает риски, связанные с безопасностью приложения.
Архитектура слоя данных
Windows Azure Tables и BLOB’s позволяют реализовать различные уровни изоляции данных на уровне: отдельных аккаунта, таблиц, партиций и контейнеров. SQL Azure реализует изоляцию за счет отдельных: база данных, федерации базы данных или серверов. Например, мы можем создать мобильное приложение, которое сохраняет данные в BLOB хранилище. В этом случае мы можем создать для каждого пользователя отдельный BLOB контейнер и назначить соответствующие права на этот контейнер (т.е. не публичный доступ).
3. Масштабируемость архитектуры данных. Горизонтальное партиционирование позволяет масштабировать хранилище данных. Для достижения масштабируемости SQL Azure можно перенести данные отдельных клиентов в новый экземпляр SQL Azure.
Ключевым фактором, определяющим масштабируемость табличного хранилища Windows Azure, является выбор ключа партиции. Чтобы избежать просмотра (сканирования) нескольких партиций, все запросы должны включать ключ партиции.
Подробнее о выборе архитектуры данных и компромиссах, связанных с этим, в статьях Multi-Tenant Data Strategies for Windows Azure – Part 1 и Multi-Tenant Data Strategies for Windows Azure – Part 2. В частности, поднимается интересные вопросы SLA, резервирования и восстановления реляционных данных при использовании одной разделяемой базы данных.
Финансовые вопросы
1. Выставление счетов клиентам. Одним из подходов к тарификации является использование плана оплаты по фактическому использованию. При таком подходе необходимо отслеживать ресурсы, затраченные на каждого клиента, рассчитывать стоимость этих ресурсов и добавлять маржу для получения прибыли.
Для выделенного приложения можно создать отдельную учетную запись Windows Azure и определить итоговую сумму для каждого клиента. Однако для выделенного развертывания, выполняющегося в отдельной учетной записи Windows Azure, некоторые затраты будут зафиксированы, т.е. их нельзя будет избежать. Например, оплата за использование вычислительных ресурсов 24×7 и базы SQL Azure может сделать начальную стоимость вашего сервиса слишком высокой для небольших компаний. С мультитенантной архитектурой фиксированные затраты можно разделить между клиентами, но затраты на одного пользователя рассчитать не так просто, и для определения объемов ресурсов, потребляемых каждым клиентов, потребуется в приложение добавить дополнительный код. Более того, клиенты захотят каким-то образом отслеживать свои затраты, поэтому вычисление затрат необходимо сделать максимально прозрачным, а так же реализовать механизм доступа клиентов к этим данным.
Модуль Cloud Ninja Metering Block для Windows Azure: позволяет снимать метрики использования ресурсов для каждого тенанта, имеет встроенный портал отображения отчетов для клиентов.
Трудно заранее точно определить нагрузку и ресурсы, которые потребуются для конкретного подписчика, т.к. заранее сложно спрогнозировать кривую использования ресурсов конкретным подписчиком. Если применить модель тарификации, которая предлагает SaaS приложение за фиксированную месячную плату, то прибыльность будет варьироваться между подписчиками (и даже может быть в некоторых случаях отрицательной). Сделав SaaS приложение мультитенантным, можно сгладить различия в шаблонах использования разных подписчиков, что дает возможность легче прогнозировать расходы и доходы и уменьшить риск убытков. Чем больше клиентов, тем легче на основе статистических данных определить шаблоны использования службы.
С точки зрения клиента начисление фиксированной платы за услугу означает, что клиент заранее точно знает, какие будут расходы в следующем платежном периоде. Это также означает, что система тарификации становится намного проще. Некоторые расходы, такие как расходы, связанные с хранилищем и транзакциями, будут переменными и будут завесить от количества имеющихся клиентов и от того, как они используют службу. Другие расходы, такие как расходы на вычисленные ресурсы будут четко зафиксированы.
В итоге, для того чтобы получить итоговую прибыль, необходимо продать достаточное число подписок, которые покроют фиксированные и переменные затраты.
Если ваша клиентская база включает как крупные, так и небольшие компании, то стандартная абонентская плата может быть слишком высокой для привлечения некрупных клиентов. В этом случае потребуется видоизменение второго подхода и предложение ряда пакетов для разных уровней использования. Например, предложить ограниченный пакет услуг с более низкими ежемесячными ценами, чем стандартный пакет.
От выделенной или мультитенантной архитектуры приложения стоимость на одного клиента не зависит. Независимо от модели для конкретного клиента требуется одинаковый объем хранилища и использование одинакового количества вычислительных циклов. Для управления этими затратами необходимо обеспечить максимально эффективное использование этих ресурсов приложением.