Disclaimer
Данной статьёй мы продолжаем цикл материалов, рассказывающий о нашем опыте создания облачного продукта. Этот цикл не претендует на всеобъемлемость и универсальность, а призван продемонстрировать один из подходов (как мы надеемся, эффективный) к построению продукта с нуля. Статьи могут быть интересны как отдельным разработчикам, архитекторам, менеджерам проектов, так и целым командам, занимающимся созданием коммерческих продуктов. С предысторией вопроса можно ознакомиться тут.
Идея
Задача:
Любой IT-продукт призван либо развлекать, либо решать какие-либо бизнес-проблемы (или технические проблемы) своей целевой аудитории. Развлечения оставим в стороне и перейдём в мир «Enterprise». Задача организаторов — определить круг проблем, которые вы можете охватить и их точно сформулировать.
Пример реализации в EZ-Login:
У вдохновителя компании Антона Марченко было желание создать SAAS-продукт, дающий возможность в компаниях организовать управление учётными записями во внешних сервисах. Так как крупные компании имеют собственные датацентры и предпочитают не выводить информацинные потоки за пределы своей инфраструктуры, то продукт должен быть, как публичным, так и иметь возможность закрытого использования в виде отдельной копии внутри конкретной компании.
Более полно проблемы, на решение которых нацелен EZ-Login описаны в этой статье
Далее, используя сильно упрощённую методику EAP, необходимо определиться в терминологии и модели предметной области, что позволит нам получить представление об общих схемах архитектуры приложения, архитектуры данных и технологической архитектуре.
Терминология.
Задача:
Требуется собрать воедино и определиться со всеми терминами, которые используются. Это поможет и в формулировке требований к разрабатываемой системе, и поможет избегать недопонимания. Терминологический словарь (глоссарий) пополняется и уточняется по мере развития продукта.
Пример реализации в EZ-Login:
В качестве примера несколько терминов из словаря.
Исходная точка — мы строим SAAS-продукт. Что же это такое?
В октябре 2011 года американский Национальный институт стандартов и технологий опубликовал собственные определения ряда «облачных» терминов.
Однако, до сих пор во множестве статей рунета трактуют понятия «облачный» и «SAAS» самыми разными способами. Идут постоянные споры с журналистами и практиками.
Принципиально эти споры проходят по границе: «принимать аксиоматику NIST или нет».
По формулировке NIST, программный продукт классифицируется, как SAAS, если удовлетворяет следующим признакам:
• является «облачным»
• продукт имеет явно выраженную клиент-серверную архитектуру и потребитель использует продукт через некую отдельную универсальную (типичный пример Web-браузер) или сугубо специальную (пример — клиентские части файловых сервисов 4sync, Dropbox, Яндекс.Диск) программу — клиента
• все операции по контролю за работоспособностью, применение обновлений, настройка осуществляются провайдером сервиса
Со вторым и третьим вроде бы понятно. Но что такое «облачный»?
Согласно спецификации NIST, сервис (продукт) признаётся «облачным», если он обладает следующими пятью признаками:
• потребитель взаимодействует с сервисом по принципу самообслуживания, без участия в общем случае сотрудников провайдера сервиса (self service on demand)
• потребитель пользуется сервисом по сети с любого терминального устройства (broad network access)
• сервис предоставляет своим потребителям ресурсы, организованы в виде пулов (кучи, групп) для обслуживания различных потребителей в модели множественной аренды (Multitenancy), с возможностью динамического назначения и переназначения этих ресурсов в соответствии с потребностями потребителей (resource pooling)
• потребитель имеет возможность приобретать и возвращать не нужные ему более ресурсы в любое время (rapid elasticity)
• в сервисе имеется автоматический механизм учёта предоставленных и использованных ресурсов потребителем, сопровождаемый отчетностью (measured service)
В определении «облачности» нам встретился термин multi-tenant.
Занесём и его в словарь:
Multitenancy — множественная аренда, такое свойство информационной системы, которое позволяет одной копии продукта (инсталляции) обслуживает множество различных потребителей(арендаторов), которые имеют собственное отдельное множество пользователей.
Предметная область.
Задача:
Требуется определить все сущности и их свойства, с которыми будет оперировать наш продукт, классифицировать категории пользователей, отношения между сущностями, пользователями и друг-с-другом. На основании описания предметной области будет пополняться наша терминология (глоссарий).
Пример реализации в EZ-Login:
Определим круг пользователей и их возможные роли.
Изначально сервис устанавливается и настраивается владельцем — провайдером.
Для работы на разных территориальных рынках (разные валюты, разные документы финансовой отчётности, разные домены, разные сторонние сервисы) нам потребуются отдельные представители — реселлеры.
Данным сервисом могут пользоваться, как бизнес-структуры (компании), так и обычные люди (возможно имеющие иных связанных с ними людей — членов семьи и/или друзей).
В случае публичного использования сервиса — и компании и люди являются — арендаторами сервиса.
Провайдер — обеспечивает работоспособность сервиса. Арендатор взаимодействует с реселлером данной страны.
Однако, для крупных корпораций, имеющих филиалы (или например, министерства, имеющего распределённые департаменты), в случае использования сервиса в закрытой корпоративной копии появляются иные градации:
• сама корпорация становится провайдером сервиса
• отдельный филиал/департамент превращается в реселлера
• а отделы/службы становятся арендаторами.
По функциональным возможностям всех пользователей условно разделим на классы:
• сотрудник провайдера — Клерк
• сотрудник реселлера — Менеджер
• привилегированный сотрудник арендатора — Администратор
• рядовой сотрудник арендатора — Потребитель
Основная задача сервиса — организовать управлением доступами сотрудников арендаторов в сторонние сервисы. Поэтому в наш глоссарий нам необходимо поместить новое описание сущности, которую мы используем:
Доступ — возможность любого сотрудника арендатора попасть во внешний сервис без необходимости ввода своего логина и пароля.
Исходя из свойств «облачности» нам необходимо определить ресурсы, которыми могут пользоваться арендаторы сервиса.
Таковыми для EZ-Login, например, могут быть:
• максимальное число сотрудников арендаторов
• максимальное число доступов для всего арендатора
• максимальное число сервисов, к которым арендатор может иметь доступы
• доступность синхронизации списка сотрудников с корпоративным каталогом Active Directorty
• доступность одноразовых паролей
• доступность использования USB-токенов
Приведённое выше — это только небольшая часть из анализа предметной области.
Разобравшись с аналитикой, в следующей статье перейдём к схемам и архитектуре.
Автор: Softliner
