Всем привет!
Сегодня хотим обсудить тему управления API. Когда имеет смысл открывать свой API, кто имеет возможность монетизировать свой API и как внедрить систему API менеджмента, чтобы затраты, как на начальное внедрение, так и на его эксплуатацию были минимальны.
Мы хотим поделиться своим опытом разработки системы управления API на базе Azure API Management. Давайте начнем с самого начала.
1.1. Когда открывать API?
Если вы понимаете, что ваши данные, контент или уникальная бизнес-логика могут быть полезны другим компаниям и людям – API можно открывать.
Как только вы понимаете, что ваши API помогают развитию бизнеса ваших пользователей – можно предлагать доступ к API за плату.
Если у вас немного пользователей, вы можете предоставлять доступ и собирать плату вручную. А если много, вам скорее всего понадобится API Management система. (API Management system).
1.2. Зачем нужна API Management система?
Вкратце можно сказать, что назначение API Management системы – это превратить API в продукт, Т.е. наделить чисто техническую сущность реальным бизнес-содержанием. Большинство API Management систем, на настоящий, могут следующее:
Наш заказчик — крупная метеорологическая компания, большая доля бизнеса которой состоит в платном предоставлении данных, получаемых с метеорологических станций. Несколько лет назад она одной из первых в отрасли решила также открыть и предоставлять платно свои API. И на данный момент предлагает клиентам 14 видов API продуктов, отличающихся тем, какие наборы API включены в продукт, и какой лимит на использование сета продуктов установлен.
Для понимания масштаба проекта, на текущий момент API заказчика используют 4200 разработчиков, 2400 компаний.
Наша совместная история – это уже третья попытка заказчика реализовать API менеджмент систему для успешной монетизации своих сервисов. Первый раз было решение на основе Mashery, второй раз Apigee, а затем Azure API Management. Как водится, в русской традиции, с третьего раза, обычно, все удается. Тут получилось именно так.
В итоге мы по сути сделали кастомное решение по управлению API, в рамках которого:
2.1. А что было не так с первыми двумя?
Нужно начать с того, что компания оба раза выбирала лидеров рынка – Mashery и Apigee. И после года использования уходили от каждого из них. Звучит как-то странно. Это же лидеры?!
По сути требования к API менеджмент-системе можно свести к двум основным пунктам:
И именно по этим параметрам системы-лидеры не были приняты заказчиком.
2.2. Стоимость пользования
Схема монетизации Mashery не позволяла заранее получить предсказуемую оценку затрат, и они очень быстро стали зашкаливающе высокими.
Стоимость использования Apigee со встроенной платежной системой была сразу просто космической и по сути забирала все доходы от продажи API.
Надо сказать, у Azure APIM нет встроенной платежной системы. На первый взгляд кажется, что это огромный минус, однако после негативного опыта со встроенными платежными системами, которые оказались дороги в обслуживании, заказчик оценил, это как безусловный плюс.
2.3. UX
Кроме того, заказчики признались, что посчитали UI Apigee слишком сложным и запутанным. Для сравнения приводим логические архитектуры Apigee и Azure API Mаnagement:
Как видите, архитектура Azure API Management более проста. В ней меньше объектов. Следовательно, она более проста для понимания как администраторам, так и пользователям.
Архитектура нашего решения выглядит так:
3.1. В центре всего – система управление идентификацией и подписками (EM).
Она оперирует следующими объектами:
3.2. Пользователь взаимодействует с ней через интерфейс портала (EM Web Front). Azure API Management управляет доступом к набору наших 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
В итоге сейчас на портале пользователь единовременно:
Система управления подписками в режиме реального времени получает данные об оплатах и активирует доступ.
Пользователь и разработчики из его организации получают доступ на Developers Portal, на котором есть документации и примеры использования API.
Давайте скажем честно – любая “готовая” платформа при встрече с реальным бизнесом обычно требует доработки. Хотя функциональность “из коробки” предоставляет все необходимые базовые инструменты, которые можно и нужно использовать для проверки своих бизнес-идей.
Пока пользователей мало, управлять доступом к API можно вручную взяв продукт из коробки без костюмных доработок.
В принципе, все шаги достаточно понятны:
Подписочная схема предоставления Azure API Management в данном случае очень удобна – она позволяет проверить концепцию без значительных финансовых вложений в API Management систему и интеграцию.
А предположим, что пользователей становится больше. У нашего клиента свыше 4000 активных подписчиков. Как понимаете, количество ручного труда на синхронизацию и предоставление/отключение доступа становится откровенно высоким. Однако и средств от продажи доступа к API нам поступает также больше, и теперь можно вложиться в то, чтобы можно автоматизировать эти шаги:
Если вы только задумываетесь о том, стоит ли предоставлять платный доступ к вашим API сервисам, подписочная схема Azure API Management позволяет быстро и без капитальных вложений проверить вашу бизнес-концепцию.
Когда есть понимание, что на ваш 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 менеджмент-системе можно свести к двум основным пунктам:
- стоимость пользования
- 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 можно вручную взяв продукт из коробки без костюмных доработок.
В принципе, все шаги достаточно понятны:
- Синхронизируем списки пользователей в Azure API Management и EM системах.
- Синхронизируем продукты в EM и соответствующие продукты в Azure Management API.
- На портале EM делаем ссылку на PayPal для приобретения подписки.
- При получении сообщения от PayPal – заводим подписку в EM – системе, а также соответствующую подписку в Azure Management API.
- При истечении срока действия подписки, удаляем пользователя из подписки в 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 раз! Да, были разовые затраты на разработку проекта. И клиент отчисляет платежной системе комиссию с каждой операции. Но это уже издержки с прибыли. Которая, наконец, появилась.
