Технология APS: облачный стандарт

в 14:26, , рубрики: cloud, cloud hosting, cloud platform, ingrammicro, Odin, SaaS / S+S, анализ данных, Анализ и проектирование систем, архитектура, базы данных, биллинговые системы, Блог компании Odin (Ingram Micro), облачная инфраструктура, облачные технологии, платформы дистрибуции, Разработка под e-commerce, метки:

Привет!

Меня зовут Тимур Низаметдинов, я работаю Senior Software Architect облачной экосистемы Odin (Ingram Micro). Сегодня я хочу рассказать вам об APS (Application Packaging Standard) — ключевой технологии, используемой для интеграции в платформу по продаже и потреблению облачных сервисов (SaaS marketplace) Odin Automation.

Про платформу

Технология APS: облачный стандарт - 1

Мы строим платформу, которая свяжет всех разработчиков и потребителей облачных сервисов через инфраструктуру крупных сервис-провайдеров (поставщиков телекоммуникационных и хостинг-услуг), одновременно предоставляя точку входа для конечных пользователей: контрольную панель или портал, с помощью которого можно создать сайт, настроить почту, купить антивирус или виртуальную машину в облаке.

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: облачный стандарт - 2

APS позволяет различным компаниям интегрировать свои сервисы в платформу с помощью так называемого APS Connector. Помимо взаимодействия с платформой как таковой, сервисы могут взаимодействовать и друг с другом через стандартизованный RESTful API в рамках APS шины.
APS шина представляет из себя протокол, предоставляющий всем участникам доступ к ресурсам друг друга, в том числе и к ресурсам платформы.

Технология APS: облачный стандарт - 3

Функционирование шины обеспечивает так называемый APS Controller, берущий на себя функции:

  • разграничения доступа (система политик — у каждой категории пользователей и приложений свой набор привилегий и ограничений);
  • управления жизненным циклом ресурсов сервиса;
  • поиска и хранения необходимых данных (в каком-то смысле кеш, позволяющий не запрашивать каждый раз данные из сервиса, например, для отрисовки UI; по факту мы сделали post NoSQL БД, но об этом в следующих статьях).

Технология поддерживает систему политик — у каждой категории пользователей свой набор привилегий и ограничений. Помимо прочего, мы поддерживаем глубокую интеграцию в пользовательский интерфейс контрольной панели, позволяющую:

  • вставить экраны, которые станут частью общего навигационного дерева;
  • вставить экраны одного приложения в другое (например, в визард создания пользователя);
  • вставить части пользовательского интерфейса в виде виджетов (например, в виде тайла на главной странице).

Сами платформенные сервисы (User Management, DNS Management, Account Management) взаимодействуют друг с другом через APS шину. В этом смысле мы занимаемся dog-fooding — используем APS для изоляции собственных модулей.

И что надо сделать для интеграции?

Создать APS Connector, APS пакет и поместить APS пакет в каталог.
Технология APS: облачный стандарт - 4

APS Connector является ключевым звеном в интеграции сервиса.
Он состоит из 2 частей:
1) APS Connector Backend,
2) APS Connector Frontend.
APS Connector Backend преобразует APS API в API, специфичный для сервиса. APS Connector Frontend предоставляет интерфейс, интегрируемый в контрольную панель Odin Automation.

Технология APS: облачный стандарт - 5

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 имеет такую модель:
Технология APS: облачный стандарт - 6

Допустим, файлы будут храниться на некотором диске на компьютере в вашей комнате в папке /<accountId>/<userId>, а доступ пользователям будет предоставляться через WebDav.
Сначала выразим модель сервиса в терминах APS.
Пусть ваш сервис будет продаваться по подписке и при покупке можно ограничить суммарный объем, доступный владельцу бизнеса для всех его сотрудников. Провайдер, в свою очередь, сконфигурирует соответствующие планы для продажи с помощью нашей платформы, например, Базовый (10 ГБ) и Расширенный (100 ГБ). Размер выделенного пользователю пространства будет храниться в поле diskspace.
Технология APS: облачный стандарт - 7
Синим отмечены схемы APS ресурсов, которые будут описаны в APS Connector пакете.

Далее нужно сделать HTTP-endpoint APS Connector Backend. Выбираете любую технологию по вашему вкусу: от небольшого приложения на Python-е с flask-ом у вас дома, до Java webapp, развернутого в Google App Engine.
Для простоты допустим, что при создании аккаунта или пользователя соответствующие аккаунт и пользователь в сервисе будут удалены. В очень грубой форме диаграмма последовательности будет выглядеть так:
Технология APS: облачный стандарт - 8

Обратите внимание на поле 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)

Источник

Поделиться

* - обязательные к заполнению поля