Как мы делали SaaS: практика построения облачного продукта на примере EZ-Login. Часть 1. Об аналитике


    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-токенов

    Приведённое выше — это только небольшая часть из анализа предметной области.

    Разобравшись с аналитикой, в следующей статье перейдём к схемам и архитектуре.
    Softline
    Company

    Comments 0

    Only users with full accounts can post comments. Log in, please.