Практики успешной монетизации API на базе Azure API Management

Всем привет!
Сегодня хотим обсудить тему управления API. Когда имеет смысл открывать свой API, кто имеет возможность монетизировать свой API и как внедрить систему API менеджмента, чтобы затраты, как на начальное внедрение, так и на его эксплуатацию были минимальны.

Мы хотим поделиться своим опытом разработки системы управления API на базе Azure API Management. Давайте начнем с самого начала.

1. ЛИКБЕЗ. КОГДА НУЖНО УПРАВЛЯТЬ API

1.1. Когда открывать API?
Если вы понимаете, что ваши данные, контент или уникальная бизнес-логика могут быть полезны другим компаниям и людям – API можно открывать.

Как только вы понимаете, что ваши API помогают развитию бизнеса ваших пользователей – можно предлагать доступ к API за плату.
Если у вас немного пользователей, вы можете предоставлять доступ и собирать плату вручную. А если много, вам скорее всего понадобится API Management система. (API Management system).

1.2. Зачем нужна API Management система?
Вкратце можно сказать, что назначение API Management системы – это превратить API в продукт, Т.е. наделить чисто техническую сущность реальным бизнес-содержанием. Большинство API Management систем, на настоящий, могут следующее:

• Организовывать доступ к API.
• Определять политики использования API (полнота запросов, их частота и лимит в единицу времени).
• Предоставлять средства документирования API.
• * Организовать платный доступ к API с учетом политик.

2. НЕ ВСЕ API MANAGEMENT СИСТЕМЫ ОДИНАКОВО ПОЛЕЗНЫ

Наш заказчик — крупная метеорологическая компания, большая доля бизнеса которой состоит в платном предоставлении данных, получаемых с метеорологических станций. Несколько лет назад она одной из первых в отрасли решила также открыть и предоставлять платно свои API. И на данный момент предлагает клиентам 14 видов API продуктов, отличающихся тем, какие наборы API включены в продукт, и какой лимит на использование сета продуктов установлен.

Для понимания масштаба проекта, на текущий момент API заказчика используют 4200 разработчиков, 2400 компаний.

Наша совместная история – это уже третья попытка заказчика реализовать API менеджмент систему для успешной монетизации своих сервисов. Первый раз было решение на основе Mashery, второй раз Apigee, а затем Azure API Management. Как водится, в русской традиции, с третьего раза, обычно, все удается. Тут получилось именно так.

В итоге мы по сути сделали кастомное решение по управлению API, в рамках которого:

• Интегрировали Azure API Management с системой управления идентификацией и подписками клиента.
• Предоставили единый вход для работы с порталом заказчика и порталами Azure API Management.
• Сделали оплату через PayPal и интеграцию с CRM системой SalesForce.

2.1. А что было не так с первыми двумя?
Нужно начать с того, что компания оба раза выбирала лидеров рынка – Mashery и Apigee. И после года использования уходили от каждого из них. Звучит как-то странно. Это же лидеры?!

По сути требования к API менеджмент-системе можно свести к двум основным пунктам:

1. стоимость пользования
2. UX, причем UX как пользователя так и администратора

И именно по этим параметрам системы-лидеры не были приняты заказчиком.

2.2. Стоимость пользования
Схема монетизации Mashery не позволяла заранее получить предсказуемую оценку затрат, и они очень быстро стали зашкаливающе высокими.

Стоимость использования Apigee со встроенной платежной системой была сразу просто космической и по сути забирала все доходы от продажи API.

Надо сказать, у Azure APIM нет встроенной платежной системы. На первый взгляд кажется, что это огромный минус, однако после негативного опыта со встроенными платежными системами, которые оказались дороги в обслуживании, заказчик оценил, это как безусловный плюс.

2.3. UX
Кроме того, заказчики признались, что посчитали UI Apigee слишком сложным и запутанным. Для сравнения приводим логические архитектуры Apigee и Azure API Mаnagement:

Как видите, архитектура Azure API Management более проста. В ней меньше объектов. Следовательно, она более проста для понимания как администраторам, так и пользователям.

3. АРХИТЕКТУРА НАШЕГО РЕШЕНИЯ

Архитектура нашего решения выглядит так:

3.1. В центре всего – система управление идентификацией и подписками (EM).
Она оперирует следующими объектами:

• Организация и ее пользователи (Authentication).
• Каталог продуктов для подписки, в том числе API продукты.
• Подписка (Authorization) — связь между пользователем и продуктом.

3.2. Пользователь взаимодействует с ней через интерфейс портала (EM Web Front). Azure API Management управляет доступом к набору наших API.
Основные объекты здесь это:

• API — логическая сущность представляющая ваш API.
• Политика — ограничение на использование API. Например количество запросов в месяц или объем передаваемых данных.
• Пользователь — в наиболее частом случае это разработчик который будет использовать ваш API в своем приложении.
• Подписка – связка пользователя с продуктом.

Azure Management API – с технической стороны представляет с собой WEB-proxy, которая представляется пользователю и перенаправляет вызовы соответствующему API на стороне Backend, c учетом применения.

3.3. Блок APIM позволяет безболезненно мапить пользователей из EM c пользователями в Azure.

3.4. Отдельно выделен универсальный блок обработки платежей – Payments, который пока поддерживает в том числе и повторяющиеся платежи (Recurring Payments). Пока он интегрирован только с PayPal. В будущем, планируется сюда же подключить Apple Pay и Google Pay

В итоге сейчас на портале пользователь единовременно:

• делает выбор одного из трех наборов, охватывающих все 14 возможных API продуктов,
• выбирает тариф, который определяет допустимую частоту запросов и общий лимит запросов в месяц,
• переходит к оплате.

Система управления подписками в режиме реального времени получает данные об оплатах и активирует доступ.

Пользователь и разработчики из его организации получают доступ на Developers Portal, на котором есть документации и примеры использования API.

4. КОГДА НУЖНА КАСТОМНАЯ АВТОМАТИЗАЦИЯ?

Давайте скажем честно – любая “готовая” платформа при встрече с реальным бизнесом обычно требует доработки. Хотя функциональность “из коробки” предоставляет все необходимые базовые инструменты, которые можно и нужно использовать для проверки своих бизнес-идей.

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

1. Синхронизируем списки пользователей в Azure API Management и EM системах.
2. Синхронизируем продукты в EM и соответствующие продукты в Azure Management API.
3. На портале EM делаем ссылку на PayPal для приобретения подписки.
4. При получении сообщения от PayPal – заводим подписку в EM – системе, а также соответствующую подписку в Azure Management API.
5. При истечении срока действия подписки, удаляем пользователя из подписки в Azure API и EM системах, если оплата не была проведена.

Подписочная схема предоставления Azure API Management в данном случае очень удобна – она позволяет проверить концепцию без значительных финансовых вложений в API Management систему и интеграцию.

А предположим, что пользователей становится больше. У нашего клиента свыше 4000 активных подписчиков. Как понимаете, количество ручного труда на синхронизацию и предоставление/отключение доступа становится откровенно высоким. Однако и средств от продажи доступа к API нам поступает также больше, и теперь можно вложиться в то, чтобы можно автоматизировать эти шаги:

• Чтобы синхронизировать списки пользователей в Azure API Management есть механизм делегации. При входе на developers portal он позволяет перенаправить пользователя, на наш портал, откуда он возвращается уже авторизованным. Подробнее описано azure.microsoft.com/en-en/documentation/articles/api-management-howto-setup-delegation
• Далее пишем специальный сервис, который позволяет сопоставлять продукты в Azure API Management с продуктами в каталоге EM системы.
• Также как и в ручном режиме, на портале EM делаем редирект на сайт PayPal для приобретения подписки. Здесь же настраиваем возможность повторяющихся (recurring) платежей.
• Следующая задача – завести подписку при прохождении платежа. PayPal – умеет посылать уведомление о подтверждении платежа в виде вызова нашего сервиса, в EM-системе. Этот сервис, заводит, подписку в EM, и транслирует изменения в Azure API Management. Обработчик соответствующего сообщения заводит подписку используя Azure API Management Rest API: msdn.microsoft.com/en-us/library/azure/dn776325.aspx
• И, наконец, по истечении срока действия подписки пользователя нужно удалить. Для этого в EM системе мы добавляли к подписке аттрибут ”дата истечения”. И все, что нам нужно сделать, это написать JOB, который периодически проверяет срок действия подписки в EM, и блокирует доступ в Azure API Management.

5. ИТОГО

Если вы только задумываетесь о том, стоит ли предоставлять платный доступ к вашим API сервисам, подписочная схема Azure API Management позволяет быстро и без капитальных вложений проверить вашу бизнес-концепцию.

Когда есть понимание, что на ваш API есть достаточный спрос, кастомное решение на базе Azure API Management позволит вам обеспечить:

• Легкость управления. Архитектура платформы Azure APIM позволяет максимально легко осуществлять управление API.
• Глубокую интеграцию серверной части с порталом.
• Гибкую интеграцию с внешними платежными системами, удобными для заказчика.
• И, конечно, экономическую эффективность платного предоставления API. В нашем кейсе по сравнению с Mashery постоянные косты снизились в 10 раз! Да, были разовые затраты на разработку проекта. И клиент отчисляет платежной системе комиссию с каждой операции. Но это уже издержки с прибыли. Которая, наконец, появилась.

Автор: EastBanc Technologies

Источник