В один ненастный момент мы осознали, что без комплексного, и главное, продуманного управления несколькими десятками API, что есть в нашем ПО, всё больше времени тратим на борьбу с хаосом. Привычный Postman спасал лишь от малой толики проблем, и мы начали выбирать себе API Management платформу.

К вопросу решили подойти масштабно, с изучением рынка, сравнением систем, выпытыванием подробностей у вендоров и реальных пользователей. Убили на это 3 месяца, систему выбрали, но хочется, чтобы труд не пропал зря, а потому делимся наработками.

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

Функции и состав платформы

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

Основные задачи. которые решает платформа API Management, это:

• Хранение знаний по всем API.

• Разработка схем API, их документирование.

• Развертывание API.

• Продвинутый контроль доступа к API.

• Биллинг трафика.

• Отслеживание работоспособности API.

• Мониторинг использования API и аналитика.

Архитектура приложения, если очень грубо нарисовать, будет выглядеть так:

Исходя из этого попробуем сформулировать требования для платформы в целом и каждого блока по отдельности.

Критерии

Если учитывать требования владельца бизнеса, то у нас получится 4 больших группы критериев оценки. Каждому из них мы присвоили свой вес, отражающий важность критерия в диапазоне 0-100%:

1. Репутационные критерии - 50%.

2. Экономические критерии - 100%.

3. Нефункциональные требования - 80%.

4. Функциональные требования - 100%.

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

Также к репутационным критериям можно отнести санкционную стойкость решения: для OpenSource и российских платформ она будет выше, для западных – ниже. 

Экономические критерии всегда важны. Здесь можно вычленить две составляющие. Это стоимость лицензии в расчете на горизонт планирования (3-5 лет) и стоимость техподдержки на нужном уровне.

К нефункциональным требованиям мы отнесли наличие документации и обучающих материалов, объем и качество техподдержки, а также используемую архитектуру платформы.

Про архитектуру, наверное, стоит пояснить. Здесь мы выделили такие требования:

1. Мультитенантность, причем желательно, чтобы была возможность реализации различных моделей мультитенантности и присутствовала единая консоль управления/мониторинга тенантами - 80%.

2. Disaster Recovery Deployment – способность платформы быстро восстановиться после сбоя - 100%.

3. Возможность автономной работы - 100%.

4. Возможность обновления компонентов платформы "на лету" (без даунтаймов) -80%.

5. Поддержка платформ контейнеризации, наличие механизмов failover и healthcheck - 100%.

6. Отсутствие влияния на производительность различных факторов: количества API, параллельных вызовов, сложности логики и политик - 80%.

 Теперь пройдемся по функциональным критериям.

Управление жизненным циклом (API Platform Lifecycle Management) - 80%

В этом блоке основные составляющие, это 

1. Поддержка Design-First - наличие инструментария для декларативного проектирования и поддержки стандартов - 100%.

2. Поддержка нужных спецификаций, в первую очередь OpenAPI Specification и WSDL - 100%.

3. Соответствие современным практикам и подходам разработки Agile API Development - 100%.

Среда исполнения API (API Platform Runtime) - 80%

В этом блоке основные составляющие, это:

1. Наличие механизмов управления траффиком, в частности throttling -100%

2. Наличие механизмов контроля открытых соединений, в частности rate limit, причем самой важной возможностью является ограничение количества активных/открытых соединений от API слоя к back-end системам - 100%.

3. Наличие механизмов квотирования. Возможность выставлять квоты на доступы, вызовы в зависимости от потребителя (тип партнера, приложения, продукта и т.д.) - 80%.

4. Наличие механизмов кэширования - 80%

5. Наличие хранилища конфигураций (config store). Возможность извлекать и использовать конфигурационные параметры во время обработки вызовов API - 80%

6. Наличие механизмов reverse-proxy, в первую очередь: балансировка нагрузки, ускорение трафика (кэш, компрессия, дополнительные функции, такие как SSL для снятия нагрузки с web-сервера), безопасность и анонимность - 100%.

7. Возможности интеграции с системами класса Service Discovery - 80%.

8. Наличие большого кол-ва базовых политик, а также возможность создавать собственные политики - 100%.

9. Возможность создания кастомной логики - 100%.

10. Наличие открытого SDK для создания собственных плагинов - 100%.

11. Наличие механизмов логирования, обработки ошибок и маскирования чувствительных данных, в первую очередь возможность расширять атрибутный состав сообщений и маскировать чувствительные данные как при запросе, так и при ответе - 80%.

12. Наличие механизмов мониторинга и отладки API - 80%

13. Возможность публикации API как через gateway, так и напрямую к бэку сервиса - 80%.

14. Наличие механизмов настройки CORS - 80%.

Бэкэнд (API Platform Back-end) - 80%

В целом, тут у разных платформ все примерно одинаковое, но все же выделим такие требования:

1. Наличие масштабируемого хранилища данных с поддержкой различных технологий баз данных как реляционных, так и не реляционных для задач управления платформой, поддержки состояний, аналитики - 80%.

2. Программное управление платформой через REST API - 80%.

Аналитика (API Platform Analytics) - 60%

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

API Портал (API Platform Portal) - 100%

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

1. Наличие API Портала с такими возможностями, как авторизация пользователей, управление аккаунтом, регистрация приложений, поиск и фильтрация API по атрибутам и тегам, а также возможность указания стадии жизненного цикла для API (черновик, эксплуатация, вывод из эксплуатации и т.п.) - 80%.

2. Наличие API Designer – инструмента для разработчиков API, включающего декларативный (low-code) подход проектирования API и автогенерацию документации - 100%.

Безопасность (API Platform Security) - 100%

Можно выделить несколько десятков важных подпунктов, поэтому ограничимся только ключевыми.

1. Поддержка аутентификационных/ авторизационных механизмов - 100%.

2. Поддержка конфигурации/кастомизации flow - наличие механизмов, позволяющих добавлять логику в процесс аутентификации/авторизации - 100%.

3. Наличие keystore для хранения приватных ключей и сертификатов безопасности - 100%.

4. Наличие механизма управления пользователями, группами и ролями - 100%.

5. Наличие Password Policy - 100%.

6. Наличие RBAC, позволяющего использовать и комбинировать разные модели управления доступом - 100%.

Монетизация (API Billing) - 80%

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

1. Наличие API Маркетплейса – поддержка удобного и настраиваемого маркетплейса для пользователей -100%.

2. Возможность интеграции с внешними биллинговыми системами - 100%.

Вышло приличное полотно, для удобства использования прикладываем бланк с этими критериями, чтобы вы сами могли подогнать вес критериев под свои нужды и сразу получить инструмент для бенчмаркинга API Management систем.

Вот ссылка

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