На Хабре уже немало писали и о разработке, и о бизнес-моделях для SaaS. Например, вот в этой статье затрагивается вопрос о продаже сервиса через партнеров. Если «товар штучный» и сервис достаточно дорогой, то партнер еще может регистрировать клиентов и настраивать сервис вручную. Но очевидно, что такой подход не работает для массовых сервисов. И тогда возникает необходимость в интреграции SaaS с OSS/BSS платформой облачного провайдера для автоматизации процесса предоставления сервиса, биллинга, и т. д.
В этой статье я расскажу о том, что требуется для интеграции с OSS/BSS платформами, и как мы интегрировали наш Backup-as-a-Service с платформой Parallels Automation с помощью открытого стандарта APS 2.0. В общем-то, эти советы пригодятся разработчику любого облачного сервиса, если есть планы продавать его не только со своего сайта, но и позволять это делать любому сервис-провайдеру.
Кто есть кто?
Начну с описания того, что представляют из себя наш Backup-as-a-Service, платформа Parallels Automation и стандарт Application Packaging Standard (APS).
Backup-as-a-Service — про BaaS уже писали на хабре ранее. Если вкратце, то это один из типов SaaS-сервиса. В нем объединены и облачное, и резервное копирование: все данные копируются по Сети и хранятся в центре обработки данных провайдера, а на компьютере пользователя стоит программа-клиент резервного копирования. Это позволяет передать на сторону провайдера услуги всю инфраструктурную часть от систем хранения до системного ПО (необходимость в которых пропадает) и все ее обслуживание.
Application Packaging Standard – открытый технологический стандарт, разработанный компанией Parallels в 2007 году. Позволяет независимым разработчикам (ISV) продавать свои облачные приложения через любого сервис-провайдера, а самим сервис-провайдерам – быстро разворачивать и запускать в продажу новые облачные услуги. Сейчас в мире уже больше 500 приложений в стандарте APS.
APS 2 – это новая версия стандарта, выпущенная в 2013 году. По сравнению с предыдущей обладает большей гибкостью, производительностью, а также сервисной шиной, которая дает возможность разным сервисам взаимодействовать между собой (взаимная интеграция для обмена данными и возможности одновременного использования). Это могут быть и новые, и уже давно существующие облачные приложения. А потребители сервиса могут добавлять их в свою корпоративную подписку, управлять всеми своими подписками из единой контрольной панели и получают единую аутентификацию для доступа ко всем своим сервисам.
Parallels Automation – OSS/BSS платформа, которая ставится у сервис-провайдера или телекоммуникационной компании и позволяет им запускать в эксплуатацию и продажу любые упакованные в APS облачные сервисы, и вести по ним все необходимые операции – от service provisioning до биллинга, интеграции в единый счет клиента и функций перепродажи.
При этом облачные сервисы могут быть любого типа – и SaaS, и IaaS, и другие: в рамках экосистемы Parallels Automation принцип «вилка-розетка» работает максимально идеально (подключение упакованного сервиса можно сделать всего лишь за несколько минут). Так что если разработчик хочет продавать свой сервис в сети партнеров Parallels (а это более 9 тысяч его возможных продавцов), то приходит к логичному варианту – интеграции через APS.
Просто для примера, Топ-10 наиболее продаваемых через Parallels Automation облачных приложений: Microsoft Office 365 (на данный момент таким образом продано более 800 тыс подписок), Microsoft Hosted Exchange (больше 700 тыс подписок), Open-Xchange, SpamExperts Integration, Hostopia, Mail2World, Microsoft Lync 2010, MozyPro, IDSync, BackupAgent (как видите, BaaS – в десятке).
Подписка на сервис через платформу облачного провайдера
Рассмотрим вкратце основные сценарии того, каким образом клиент получает сервис, и поймем, где нам необходима интеграция между платформой и сервисом.
Описанное ниже справедливо для большинства SaaS-сервисов и облачных платформ.
Основные этапы:
- Первый этап — настройка плана для продажи сервиса облачным провайдером:
- Для начала создается набор ресурсов, которые можно продавать.
В нашем случае это может быть, например, размер дискового пространства, доступного для хранения резервных копий или количество защищенных виртуальных машин. - Затем эти ресурсы группируются в план, в котором провайдер настраивает лимиты для ресурсов, цены, типы и способы оплаты и многое другое.
- После этого готовый план публикуется в онлайн-магазине и становится доступным для клиентов.
Очевидно, что план может включать в себя несколько сервисов. И их ценность (в буквальном, денежном смысле) значительно увеличивается в случае, если сервисы интегрированы между собой.
Например, E-mail hosting + Anti-spam + Antivirus + Archiving — очень популярный пакет сервисов, и его можно продать значительно дороже, чем просто E-mail hosting.
Настройка производится из панели администратора.
Настройка ресурсов, включенных в план:
Настройка периода и цены на подписку:
- Для начала создается набор ресурсов, которые можно продавать.
- Второй шаг — заказ сервиса клиентом.
После того, как план появится в онлайн-магазине, клиент может:- Выбрать нужные сервисы, дополнительные опции
- Зарегистрироваться и сделать заказ
- Оплатить его
Онлайн-магазин:
Регистрация пользователя и размещение заказа:
- Шаг третий — предоставление сервиса клиенту.
После того, как клиент разместил и оплатил заказ, система:- Создает для него подписку
- Настраивает для него сервис
- Дает клиенту доступ к этому сервису из клиентской панели
- Шаг четвертый — управление сервисом самим клиентом:
После предоставления сервиса, клиент получает доступ в клиентскую панель, откуда он может управлять этим сервисом. Например, настраивать бэкапы для своих виртуальных машин.Клиентская панель. Список пользователей, которым разрешено пользоваться сервисом
Панель пользователя. Список защищенных машин
При нажатии на кнопку “Manage Backups” в панели пользователя он перенаправляется в BaaS-панель.
- Шаг пятый, продление подписки:
Клиенту периодически выставляется счет и снимаются деньги за продление подписки. Также может взыматься плата за использованные ресурсы, если клиент платит по факту потребления ресурсов (по pay-as-you-go). - Шаг шестой, финальный — удаление сервиса:
В случае, если клиент отменяет подписку, т.е. отказывается от сервиса, система сначала запрещает доступ к сервису, а потом, спустя заданное время, удаляет данные клиента.
Интеграция SaaS-сервиса с OSS/BSS платформой
Итак, мы рассмотрели жизненный цикл подписки: от создания до удаления. Теперь разберемся, какую часть задач берет на себя платформа, а какие изменения необходимо внести при подключении нового сервиса.
- Для нового сервиса необходимо определить набор ресурсов, доступных для продажи. Настройку и публикацию плана берет на себя платформа.
- Заказ сервиса клиентом и оплата обычно целиком лежит на платформе.
- Необходимо автоматизировать предоставление и первоначальную настройку сервиса.
В нашем случае, для этого необходимо реализовать вызовы API методов для:- Создания организации на стороне BaaS
- Выставления лимитов для организации
- Необходимо дать клиенту возможность самостоятельного управления сервисом.
Есть 3 основных варианта для интеграции веб-интерфейсов для клиентской панели:- Можно встроить интерфейс своего сервиса в клиентскую панель провайдера.
Это, с моей точки зрения, наиболее предпочтительный вариант, так как пользователю удобнее управлять всеми сервисами из одной панели. - Можно перенаправлять клиента из клиентской панели в отдельную панель сервиса. В этом случае рекомендуется реализовать технологию единого входа (single sign on), чтобы клиенту не пришлось запоминать, хранить и лишний раз вводить кучу разных логинов и паролей.
- Третий вариант — это комбинация первых двух. Когда наиболее часто используемые сценарии доступны из клиентской панели, и клиент перенаправляется в панель сервиса для выполнения остальных задач.
Для нашего сервиса мы пошли третьим путем.
- Можно встроить интерфейс своего сервиса в клиентскую панель провайдера.
- Продление сервиса обычно лежит на стороне платформы, однако если клиент платит за использованные ресурсы, то необходимо собирать статистику по их использованию.
В нашем случае мы периодически вызываем API метод для сбора информации по ресурсам. - Необходимо автоматизировать приостановление, удаление сервиса
В нашем случае, это вызов API методов для:- Активации/деактивации организации
- Удаления организации
Как мы видим, для простого варианта подключения нового сервиса к платформе требуется внести не так уж много изменений. Конечно бывают и сложные варианты, особенно в случае, когда несколько сервисов взаимодействуют друг с другом.
Описанное выше характерно для любой платформы, поддерживающей предоставление и продажу облачных сервисов (как известно, в мире у многих телекомов и провайдеров могут стоять OSS/BSS платформы разных вендоров, а то и самописные). Но нам необходима интеграция именно с Parallels Automation: именно ее использует ряд наших партнеров, кроме того, она уже стоит у половины самых больших европейских телекомов. А для этого нам необходимо создать для своего сервиса APS-пакет.
Написание APS-пакета для Backup-as-a-Service
Чтобы начать разработку APS-пакета, надо:
- зарегистрироваться на сайте
- запросить тестовую среду
- изучить документацию
- подготовить среду для разработки.
Мы вели разработку в eclipse, так как для него есть специальный APS ECLIPSE IDE плагин.
Eclipse с установленным APS-плагином.
После настройки eclipse можно создать новый APS-проект.
Рассмотрим структуру APS-пакета. Готовый пакет представляет из себя .zip архив, в котором содержится:
- APP-META.xml — файл описания пакета. Содержит общую информацию о сервисе и APS пакете.
- /schemas – содержит JSON схемы APS ресурсов. Обычно создается автоматически командой “aps build” на основе описания ресурсов из /scripts
- /scripts – содержит скрипты с описанием сервиса, ресурсов и логику по предоставлению сервиса.
Скрипты можно писать на разных языках. Для своего пакета мы выбрали php, потому что:- для php есть библиотека APS PHP Runtime, которая упрощает разработку пакета
- доступные примеры также написаны на php
- /ui – содержит HTML и JavaScript для встроенных веб интерфейсов.
Для написания встроенного веб-интерфейса использовалась JS библиотека APS JS SDK, так как при ее использовании наследуются стили из контрольной панели. - /i18n – содержит файлы локализации
Итак, мы:
- Создали проект
- Добавили описание пакета в APP-META.xml
- Определи и описали ресурсную модель
- Определи пользовательские сценарии: то, как пользователь будет управлять сервисом. Нарисовали макеты для веб-интерфейсов.
- Сделали веб-интерфейс
- Реализовали вызовы API методов к нашему Backup-as-a-Service в /scripts
- Добавили локализацию на нужные языки в /i18n
Совет: Разработчикам, которые будут писать свой APS-пакет, я бы рекомендовал связаться с APS-командой на этапе, когда описана ресурсная модель, готовы макеты и до начала разработки для получения отзывов. Моя практика показывает, что это может сэкономить много времени.
Я не стал приводить здесь куски кода из нашего пакета. Статья и так получилась большая. Все, кто хочет посмотреть на готовый APS пакет, могут скачать примеры с сайта.
Спустя несколько недель пакет был готов, и мы отдали его на сертификацию.
Сертификация APS-пакета
Совет: Рекомендуем после создания пакета пройти его сертификацию. Эта процедура позволит выявить и устранить ошибки в работе пакета.
В процессе сертификации команда APS со стороны Parallels помогает удостовериться в корректной работе приложения и убедиться, что оно будет работать на платформе в целом, либо у конкретного партнера. В случае необходимости даются рекомендации. Сертификация полностью бесплатна.
Процесс сертификации:
- Перед тем, как отдать пакет на сертификацию, необходимо убедиться, что он соответствует спецификации и требованиям.
- После этого нужно загрузить пакет в APS development portal для автоматического тестирования пакета. После этого в системе автоматически создается тикет, через который общаются разработчики обеих сторон.
- В случае успешного прохождения тестов нужно запросить ручную проверку. По результатам проверки, APS команда пришлет рекомендации по улучшению пакета. На этом процесс сертификации, по сути, заканчивается.
- После того, как пакет успешно прошел сертификацию, он публикуется в APS каталоге.
Сертификация нашего пакета заняла всего несколько дней, а в среднем она занимает от 3 дней до 2-х недель, в зависимости от того, что нужно будет скорректировать в пакете.
Итоги
После сертификации пакета мы отдали его первому партнеру, использующему Parallels Automation. У него ушло меньше часа на то, чтобы подключить BaaS-сервис, настроить план и создать первую тестовую подписку. Сейчас наш APS пакет активно тестируется провайдерами по всему миру.
Любой другой XaaS сервис, будь то SaaS, PaaS или IaaS может быть так же легко интегрирован в Parallels Automation с помощью стандарта APS 2, что позволит продавать его через сотни провайдеров по всему миру, включая Россию, и интегрировать с другими приложениями. А это не только хороший канал продаж, но и лишняя копеечка, если твое приложение продается в пакете с чьим-то еще.
Автор: r0s
