Привет!
Меня зовут Тимур Низаметдинов, я работаю Senior Software Architect облачной экосистемы Odin (Ingram Micro). Сегодня я хочу рассказать вам об APS (Application Packaging Standard) — ключевой технологии, используемой для интеграции в платформу по продаже и потреблению облачных сервисов (SaaS marketplace) Odin Automation.
Про платформу
Мы строим платформу, которая свяжет всех разработчиков и потребителей облачных сервисов через инфраструктуру крупных сервис-провайдеров (поставщиков телекоммуникационных и хостинг-услуг), одновременно предоставляя точку входа для конечных пользователей: контрольную панель или портал, с помощью которого можно создать сайт, настроить почту, купить антивирус или виртуальную машину в облаке.
Odin Automation состоит из следующих компонентов:
- Онлайн-магазин, задача которого привлечь конечных пользователей, а также представителей малого и среднего бизнеса, заинтересованных в приобретении таких продуктов, как Microsoft Office 365 или Dropbox for Business. Система помогает выбрать наиболее подходящие решения, сориентироваться в их возможностях и версиях.
- Панель управления купленными сервисами (Контрольная панель / Self-management Control Panel), задача которой предоставить возможности управления, докупки (upsell) и перекрестной продажи (cross-sell) сервисов покупателю.
- Система бизнес-поддержки (BSS, Business Support System), которая управляет рабочими процессами, инициирует процессы оплаты, предоставления (provisioning), биллинга и так далее.
- Система поддержки операций (OSS, Operation Support System), которая занимается учетом, планированием и предоставлением услуг.
OSS управляет созданием сервисов и учетом их потребления. В случае облачных сервисов это становится нетривиальной задачей, ведь каждый сервис имеет собственный API. Для того чтобы решить эту задачу и нужен APS, предоставляющий системе поддержки операций единый API по управлению и учету облачных сервисов.
APS позволяет различным компаниям интегрировать свои сервисы в платформу с помощью так называемого APS Connector. Помимо взаимодействия с платформой как таковой, сервисы могут взаимодействовать и друг с другом через стандартизованный RESTful API в рамках APS шины.
APS шина представляет из себя протокол, предоставляющий всем участникам доступ к ресурсам друг друга, в том числе и к ресурсам платформы.
Функционирование шины обеспечивает так называемый APS Controller, берущий на себя функции:
- разграничения доступа (система политик — у каждой категории пользователей и приложений свой набор привилегий и ограничений);
- управления жизненным циклом ресурсов сервиса;
- поиска и хранения необходимых данных (в каком-то смысле кеш, позволяющий не запрашивать каждый раз данные из сервиса, например, для отрисовки UI; по факту мы сделали post NoSQL БД, но об этом в следующих статьях).
Технология поддерживает систему политик — у каждой категории пользователей свой набор привилегий и ограничений. Помимо прочего, мы поддерживаем глубокую интеграцию в пользовательский интерфейс контрольной панели, позволяющую:
- вставить экраны, которые станут частью общего навигационного дерева;
- вставить экраны одного приложения в другое (например, в визард создания пользователя);
- вставить части пользовательского интерфейса в виде виджетов (например, в виде тайла на главной странице).
Сами платформенные сервисы (User Management, DNS Management, Account Management) взаимодействуют друг с другом через APS шину. В этом смысле мы занимаемся dog-fooding — используем APS для изоляции собственных модулей.
И что надо сделать для интеграции?
Создать APS Connector, APS пакет и поместить APS пакет в каталог.
APS Connector является ключевым звеном в интеграции сервиса.
Он состоит из 2 частей:
1) APS Connector Backend,
2) APS Connector Frontend.
APS Connector Backend преобразует APS API в API, специфичный для сервиса. APS Connector Frontend предоставляет интерфейс, интегрируемый в контрольную панель Odin Automation.
APS Connector Backend представляет собой HTTP Endpoint, API которого подчиняется некоторым соглашениям. Например, для создания сервиса платформа отправит HTTP POST с репрезентацией ресурса в APS Connector Backend. Основываясь на данных в репрезентации (например, ссылки на пользователя — потенциального потребителя сервиса), APS Connector Backend может принять решение о создании ресурса — например, пользователя — на стороне сервиса.
Сам ресурс описан в json-схеме, помещенной в APS пакет. Схема позволяет Odin Automation понять, каким образом можно управлять и продавать ресурс.
То есть, например, при покупке подписки Microsoft Office через сервис-провайдера, лицензия на серверах Microsoft Office создается с помощью логики, имплементированной в APS Connector Backend.
Разработчик может разработать APS Connector Frontend — включить специфичную логику представления (пользовательский интерфейс) для:
- информирования пользователя о состоянии купленных сервисов (например, оставшихся лицензий Microsoft Office);
- возможности докупки услуг в рамках сервиса (например, дополнительного дискового пространства в облачном хранилище);
- облегчения доступа к ресурсам приложения (например, ссылки для скачивания клиента для доступа в Dropbox и документации).
После развёртывания APS Connector пакета в инфраструктуре сервис-провайдера, оно готово к продаже. При этом APS Connector Backend может быть размещен в облаке и быть развернутым, например, в любом PaaS-сервисе таком как Google App Engine или Microsoft Azure WebApp.
Помимо прочего, мы сертифицируем APS Connector пакеты по аналогии с Google PlayMarket и Apple AppStore. После сертификации приложение попадает в APS-каталог, откуда может быть установлено в инфраструктуру сервис провайдера.
Таким образом, в платформе Odin Automation уже упаковано более 500 приложений, в числе которых Microsoft Office 365, Dropbox, Symantec, Acronis, Autodesk, Autocad, Trend Micro и многие другие.
Создание APS Connector Backend на примере
Пока рассмотрим только создание APS Connector Backend, создание APS Connector Frontend — тема отдельной статьи, к тому же мы работаем над технологией, позволяющей очень быстро создать APS Connector и сгенерировать довольно продвинутый пользовательский интерфейс автоматически.
Предположим, у вас есть сервис, предоставляющий облачное хранилище данных пользователям и организациям. Назовем его Fallball.
В самом простом варианте Fallball имеет такую модель:
Допустим, файлы будут храниться на некотором диске на компьютере в вашей комнате в папке /<accountId>/<userId>, а доступ пользователям будет предоставляться через WebDav.
Сначала выразим модель сервиса в терминах APS.
Пусть ваш сервис будет продаваться по подписке и при покупке можно ограничить суммарный объем, доступный владельцу бизнеса для всех его сотрудников. Провайдер, в свою очередь, сконфигурирует соответствующие планы для продажи с помощью нашей платформы, например, Базовый (10 ГБ) и Расширенный (100 ГБ). Размер выделенного пользователю пространства будет храниться в поле diskspace.
Синим отмечены схемы APS ресурсов, которые будут описаны в APS Connector пакете.
Далее нужно сделать HTTP-endpoint APS Connector Backend. Выбираете любую технологию по вашему вкусу: от небольшого приложения на Python-е с flask-ом у вас дома, до Java webapp, развернутого в Google App Engine.
Для простоты допустим, что при создании аккаунта или пользователя соответствующие аккаунт и пользователь в сервисе будут удалены. В очень грубой форме диаграмма последовательности будет выглядеть так:
Обратите внимание на поле diskspace — это стандартный тип “APS Counter”, представляющий из себя структуру. В поле limit Odin Automation передает ограничения, заданные в биллинге. Сервис может использовать эту информацию для того, чтобы запретить выход потребителю за пределы этого значения. В данном случае, ограничить место на хранилище 10 ГБ.
Осталось описать типы в виде json-schema, задекларировать url-роутинг (в данном случае, указать, что при создании подписки надо делать POST на /account). И все — APS Connector Backend готов!
Зачем разработчику облачного сервиса Odin Automation и APS?
В маркетинге есть правило 4P: product, price, promotion, place. Чтобы продукт (product) «выстрелил», недостаточно сделать из него «конфетку»: нужно правильно определить его цену (price), раскрутить (promotion) и понять, где его продать (place). Всё это справедливо и для программных продуктов, многие из которых сегодня распространяются через различные платформы — магазины приложений. При этом лучшее, что может сделать платформа — избавить вас от проблем с последними тремя “P”: сделать приложение заметным для всех потенциальных потребителей при минимуме усилий со стороны разработчика.
Все вышесказанное относится и к облачным сервисам — их тоже надо продавать, раскручивать и выбирать площадки для распространения. В качестве таких площадок могут выступать сервис-провайдеры: поставщики телекоммуникационных и хостинг-услуг, которые обладают огромной пользовательской базой. Для разработчика выход на такую базу является ключевой возможностью развития сервиса. В этом заинтересованы как крупные игроки, такие как Microsoft Office 365, Symantec, Trend Micro и Dropbox, ищущие все новые и новые рынки сбыта, так и небольшие, находящиеся в начале пути — создали сервис, но пока не знают, как его продавать и не имеют собственного биллинга.
В итоге разработчику сервиса не нужно задумываться о продвижении продукта (анализе рынка, созданию и настройке планов продажи), оплате и даже о географии продаж — крупные провайдеры могут иметь так называемых реселлеров. Например, O2 (да-да, тот самый оператор в роуминге в Европе) является дочерней компанией-реселлером крупнейшего телекоммуникационного провайдера Telefónica.
А зачем потребителю покупать облачные сервисы у сервис-провайдера?
В последнее время модель потребления различных сервисов меняется, особенно в сегменте малого и среднего бизнеса. Классическая модель потребления программного и аппаратного обеспечения («коробочное» ПО, покупка серверов, а также их установка и поддержка) умирает. Меняется как модель предоставления (все чаще — сервисная, из облака), так и способ покупки (по подписке).
Например, раньше пользователь покупал у реселлера Microsoft Office на CD через стандартный канал дистрибуции Microsoft. В новой модели потребления компании, физически передающей носитель, больше не существует. Потребитель получает облачные лицензии на Microsoft Office 365 либо напрямую от разработчика — вендора, либо через сервис-провайдера, подключенного к такой платформе, как Odin Automation.
Про покупку напрямую физическим лицом все ясно, а если предприятие использует много разнообразных сервисов? Microsoft Office 365, Adobe Creative Cloud, Azure, Dropbox, Мой Склад и т.д. Нужно иметь много разрозненных контрактов, управлять подписками и раздавать их сотрудникам, следить за правами использования, по отдельности и вовремя оплачивать каждый сервис в различных валютах, заводить бухгалтерские документы с каждым разработчиком. Возникает потребность в агрегаторе, который сможет взять на себя все эти функции. В этом заключается суть платформы Odin Automation.
Помимо прочего, изменилась модель потребления: за облачные сервисы пользователь платит с определенной периодичностью в рамках подписки, в отличие от традиционных продуктов, которые приобретают один раз.
Odin создал b2b2b-платформу (business to business to business, бизнес-бизнес-бизнес) по продаже и потреблению облачных сервисов, развертываемую в инфраструктуре сервис-провайдеров. При этом покупатель (владелец бизнеса в цепочке b2b2b) может управлять своими приобретёнными сервисами из единой контрольной панели.
Например, владелец небольшого или среднего бизнеса с помощью нашей платформы может предоставить почту и антивирус сразу нескольким своим сотрудникам, просматривать свой баланс по всем сервисам в личном кабинете, оплачивать все подписки единым счетом в местной валюте, а также получать расширенную техническую поддержку. От того, сколько разнообразных сервисов предоставляет провайдер, зависит его успех у клиентов: этот тренд уже в течение нескольких лет широко развит в Америке и Европе.
Напоследок
Данная статья является очень кратким введением в технологию APS. Мы совсем не охватили те технологии, которые стоят за стандартом, а ведь, в сущности, мы сделали платформу для бесшовной интеграции различных облачных сервисов, созданных сторонними разработчиками, с целью продажи провайдером и потребления пользователями в единой контрольной панели.
Самое интересное из используемых нами технологий вкратце:
- Собственная post NoSQL БД (часто используется термин “база онтологий”) для хранения данных (ресурсов) гетерогенных сервисов и поддержки связей между ними.
- Типы с поддержкой наследования; json-схема в качестве формата описания;
- Ресурсы как экземпляры типа с возможностью хранения как структурированных, так и неструктурированных данных и поддержкой связей;
- Связи (как явные, так и неявные);
- Методы ресурсов с поддержкой http-роутинга;
- Способы доступа к сущностям, коллекциям, связям с помощью специального языка доступа к REST объектам – RQL;
- Разграничение доступа к ресурсам, в котором любой ресурс может выступать секьюрити-принципалом (не только пользователь, но и, например, приложение);
- Версионирование;
- Механизмы аутентификации (SSL client certificate, OAuth);
- Создание и управление жизненным циклом ресурса;
- Собственная технология по объединению экранов и данных сервисов в единую контрольную панель пользователя;
- Только RESTful-интерфейсы в качестве межкомпонентного API;
- Стандартизация на уровне API;
- Активное использование PaaS (Google, App Engine standard, Compute Engine, Cloud SQL, Amazon DynamoDB, Azure, Azure App Service, SQL Azure Database);
- Публичный API со всеми вытекающими:
- Версионирование;
- 100% покрытие тестами;
- Постоянное отслеживание логической целостности, выразительности, соответствия уровня абстракции предметной области;
- Самодокументация.
Если будет интересно, в следующих постах мы более детально расскажем, как все это работает.
И да, вот ссылка на официальную документацию Odin Automation SDK, основной частью которого является APS стандарт: doc.apsstandard.org/7.1.
Спасибо!
Автор: Odin (Ingram Micro)
