Привет, Хабр! Мы – Ярослав Насонов и Надежда Колезнева – развиваем витрину для внешних API в МТС.  Сегодня обсудим тему управления API в корпорации. Поделимся опытом внедрения API-менеджмента в МТС, расскажем, что уже сделали, сколько потратили времени, с какими ошибками столкнулись, и зачем все это вообще нужно.

Эта статья будет интересна всем, кто задумывается о централизации IT-сервисов в своей компании, не знает с чего начать внедрение API-менеджмента в компанию, и поможет ответить на вопрос – а нужно ли вообще это внедрение у себя?

Чтобы сделать статью полезной, мы побеседовали с главным по API-менеджменту в МТС – руководителем платформы ЦФК Алексеем Неботовым.

Алексей: ЦФК расшифровывается как цифровой контейнер. Хотя обычно, когда в IT  говорят “контейнер” – подразумевают Docker, Kubernetes, что-то из этой области. В нашем случае это изолирование в некий кокон API, отсутствие чужих доступов. Сейчас название трансформируется и будет больше соответствовать тому, что мы делаем, но исторически платформа называется “цифровой контейнер”, сокращенно — ЦФК. 

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

Аналогичным образом, руководство компаний хочет централизовать реестры API и унифицировать правила работы для них, в  рамках этого строится современная архитектура. Это централизация данных каталогов и всех подходов к интерфейсам, которые предоставляют данные. Продукт ЦФК в МТС – как раз про централизацию правил работы с API, выставляющих ценные данные.

Управление API

Есть два больших блока при работе с API – API Gateway и API Managment. 

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

Функции Gateway:

• TLS termination – перевод HTTPS трафика к HTTP

• Request routing – перенаправление запросов внутри приложения. Потребителю API не нужно знать все внутренние пути и то, как обратиться к определенному сервису. Поэтому он получает красивую короткую ссылку api.mts.ru/fooBar, а роутинг уже перенаправляет на конкретный сервис внутри сети

• Аутентификация – способ узнать, кто обращается к API. Иногда в gateway выносят и авторизацию, чтобы узнать, имеет ли доступ конкретный клиент к определенной функции

• Rate limiting – ограничение пропускной полосы чтобы избежать перегрузок. 

• Load balancing – балансировка между серверами. За gateway есть много серверов с API. Первый запрос нужно отправить на первый сервер, второй – на второй и так далее

• Service discovering – определение расположения сервера с нужной API в конкретный момент

• Манипуляции с requests и responses – обогащение запросов данными. К примеру, при авторизации клиента вместо его ключа Gateway подставляет внутренний идентификатор пользователя. Таким образом конечное API избавляется от работы с ключами, но знает какой пользователь к нему пришел

• Exception handling – фиксирование исключений. Обычно такое не нужно показывать конечному потребителю. Достаточно ему сказать, что на стороне API проблема, а само исключение надо обработать – залогировать, сообщить о нем группе поддержки API

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

• Монетизация — возможность владельцу API легко настроить тарификацию сервиса на стороне gateway

• Трансформация и mediation – для обогащения или персонализации взаимодействия между распределенными компонентами приложений и служб 

API Managment – правили и политики, которые накладываются на API. Требуется единое место управления политиками, чтобы они распространялись на все API

Основные функции API Менеджера:

• Аналитика и мониторинг — один источник правды о том, как  работает система 

• Витрина со списком API, с документацией по API, с возможностью тестовых вызовов, с форумом поддержки

• Публикация и подписка на API

Что из этого умеют в ЦФК?

• TLS termination

• Request routing

• Аутентификация/Авторизация

• Rate limiting

• Load balancing

• Request-response манипуляции 

• Exception handling

• Монетизация

• Трансформация и mediation

Алексей: Часть из этих функций вынесена на внутреннюю витрину и доступна в режиме самообслуживания. Что-то нужно у нас заказывать по email, мы это можем сделать, но там ручные настройки. 

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

Для удобного управления API и подключения к ним, команда ЦФК сделала внутренний портал, работающий в формате самообслуживания. Для внешних потребителей мы сделали другую красивую брендированную витрину МТС Developers с экосистемной авторизацией и поддержкой.

Какую проблему решает ЦФК?

Алексей: Миссия – сделать API МТС легко используемым, понятным, чтобы клиенты знали о нем, понимали, как с ним работать, и могли легко к нему подключитсья и легко вызывать. Это глобальная цель, к которой мы и сейчас стремимся. Внутри МТС заказчиком стал Департамент Информационной Безопасности (ДИБ).

Одна из функций ЦФК – валидация всех запросов и ответов на соответствие той спецификации, которую команды согласуют в ДИБ. С одной стороны это позволяет сотрудникам ДИБ контролировать поток данных, с другой стороны удостоверяет, что разработанное API соответствует документации и спецификации. 

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

Алексей: Сейчас большинство API без проблем публикуются, текущий уровень требований достаточен. Нет уже такого, что API есть, а документации к ней нет или это какой-нибудь документ, который сложно понять. Сейчас документация к API хранится в swagger и все понимают, что к чему.

Есть проекты, например, МТС Бизнес API, которые не разрабатывают информационную систему, а монетизирует API сразу из нескольких систем МТС, объединяя их в единый интерфейс. С точки зрения gateway – это абсолютно платформенное решение, так как для МТС Бизнес API ничего специально не разрабатывалось, включены только определенные функции на стороне gateway.

Благодаря ЦФК появилась истинная точка для API: единое место для любого вызова к API МТС – домен api.mts.ru.

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

Если бы не было ЦФК, не было бы ни внутреннего, ни внешнего API, то что тогда?

Компании активно зарабатывает на API. По данным KBV Research ожидается, что к 2024 году объем мирового рынка управления API достигнет 6,2 млрд. долларов, увеличившись при среднегодовом росте рынка на 28,4% в течение прогнозируемого периода.

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

• трудоемкость разработки и ее стоимость

• time to market

Можно сразу не догадаться, что нужен rate limit, но когда придут одновременно все клиенты и запросят много данных – сервер упадет. Это может повлиять как на доходы, так и на имидж компании.

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

Алексей: Одна центральная точка отказа – очень нехорошая история. Если мы сломаемся – то сразу все API станут недоступны. С этим можно бороться, делать географически распределенную систему. Но практика показывает, что пока у нас достаточно хороший uptime, когда все эти правила централизованны, ими гораздо легче управлять. 

Если мы говорим о компаниях, которые хотят обзавестись своей платформой API Менеджмента – кому это нужно, а кому нет?

В свете цифровых трансформаций и того, что API повсюду, такой класс систем (gateway) есть везде с разной функциональностью. Если компания выводит одну API раз в пять лет, то бессмысленно делать витрину и автоматизировать процессы согласования. Можно утвердить все через email, прикрутить готовый nginx – все будет отлично работать. Также не нужны трудозатраты на поддержку самого gateway. 

Если поток публикаций и потребителей большой – стоит разрабатывать какое-то решение, чтобы всем этим управлять, удобно просматривать и не тратить время. Тогда возникают вопросы:

• Насколько большой поток публикаций/потребителей и какое нужно удобство в обслуживание? 

• Как сильно нужно кастомизировать готовые решения под себя? 

Готова компания один раз понести затраты CAPEX и потом снизить OPEX, либо понимает, что лучше меньший OPEX сейчас, в течение пяти лет, но не тратится на CAPEX?

Что внутри ЦФК?

Пару лет назад главным компонентом был WSO2, за последний год команда ЦФК очень многое перенесла непосредственно из WSO2 в наш бэкенд, чтобы уйти от ограничений WSO2. Сейчас WSO2 выступает системой авторизации к API, также есть серия обработчиков, медиаторов, которые внутри WSO – валидация, обогащение запроса. Но API Managment у нас сейчас почти на 100% находится на стороне бэкенда, мы готовимся к тому, что кроме WSO начнем использовать и другие gateway тоже. 

А внутри стандартный набор – базы Postgres, Kubernetes, микросервисы, Java-фреймворк Spring. Использовались также opensource-решения, например, заглушки для тестовых API у ЦФК на Node.js.

Какая понадобилась команда?

Размер команды колеблется от 5 до 10 человек. Большая часть – это разработчики, devops, аналитик, тестировщик. Также есть Product Owner, тимлид.

Алексей: Если у нас вопросы по безопасности — мы идем к департаменту информационной безопасности. Сейчас у нас даже своего devops-специалиста нет, мы его ищем. Понимаем, что нужен свой, но до сих пор, если были вопросы по devops, обращались к специалистам техподдержки или в центр DevOps МТС.

Сколько времени нужно на разработку?

Часто когда видишь готовый продукт, кажется, что его можно было сделать за месяц. Но в реальности на такой продукт потребуется год – проходит несколько итераций разработки, тестируется много идей.

Чтобы начать заниматься API-менеджментом, достаточно Apigee или WSO, а дальше захочется сделать валидацию или интеграцию какую-то, это затянет. Вопрос, когда удастся остановиться?

Алексей: Сейчас я думаю, что тоже самое получилось с ЦФК, когда костяк системы был создан за год, а потом началось: нужно было обновить версию WSO, переделать авторизацию на SSO и таких задач возникало множество. Также появилось понимание, какие есть плюсы у других gateway, не WSO. 

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

Такой переход необходим, чтобы избежать единой точки отказа и удовлетворять разным требованиям команд. Также часто приходят заказчики с мелкими отличиями управления. Мы понимаем, что каждому просто нужен свой instance gateway, который им самостоятельно разрешат настраивать.

Какие были проблемы и как с ними удалось справиться?

Сейчас, оглядываясь назад, понимаем, что валидация API – это вопрос болезненный, очень много есть нюансов в процессе. В системах application firewall (waf’ах) всегда есть ложноположительные срабатывания – это какой-то вызов, который завершился неуспешно. Не по вине вендора API, а потому что система посчитала этот вызов некорректным. Это боль, с которой мы столкнулись уже в процессе, сейчас там пришлось делать внушительный пласт работы над валидатором, и разделению уровней валидации.

ЦФК – платформенное решение, и каждую функцию, которую берут в разработку, обдумывают с точки зрения переиспользования. Ее создают не для одного конкретного продукта в МТС, что помогает уже сейчас вывести API в интернет с меньшим количеством усилий.

Алексей: Нам еще очень много нужно дорабатывать. Хочется, чтобы публикация API занимала часы. Сейчас она занимает дни, это все еще сложно. Но мы видим точки, где нам можно ускорить процесс и приносить еще больше пользы.

Затратна ли поддержка ЦФК?

ЦФК поддерживает такая команда:

• 1 человек – тестовый стенд

• 1 человек – промышленный стенд

• 1 человек отвечает за эксплуатацию, реквесты

Поддержка работает как внутренний аутсорс – это не участники команды ЦФК, а отдельные разработчики внутри МТС, которые таким же образом поддерживают еще и остальные команды.

Самые распространенные ошибки и как их избежать

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

• Какие протоколы?

• Сколько потребителей?

• Какие будут нагрузки?

Ответы на них помогут выстроить  архитектуру. Можно пойти путем использования готового API-менеджера и заставить производителей и потребителей подстраиваться под него. А потом выяснится, что этот менеджер, не поддерживает GRPC или GraphQL, например, и не может использоваться с продуктами компании. 

У всех API Gateway схожая функциональность. Но есть нюансы, которые могут всплыть позже:

• Как настраивается?

• Какие поддерживает протоколы?

• Умеет ли авторизовываться через то, что поддерживает продукт?

• Под что заточен – под федеративный graphQL, или под REST API?  И то и то http, но требования к системе будут отличаться.

Какие подобные ЦФК решения предлагает рынок?

В России похожее решение есть у platformeco. А вообще WSO2, Apigee, Envoy, Kong – компоненты, которых обычно хватает, всё зависит от того, чего вы хотите от своего API-менеджмента. По масштабу все системы разные — есть маленькие CRM, есть гиганты вроде Siebel, и с API Gateway всё то же самое.

Алексей: Вполне возможно, что вам будет хватать и config-файла, который лежит в Git и синхронизируется с одним сервером – это тоже решение. В Git можно достроить согласование MergeRequest на обновление этого файла, и вот, пожалуйста: у вас другие команды формируют MergeRequest, обновляется YAML, Envoy этот YAML подтягивает.

Если у вас есть вопросы или опыт работы с API-менеджментом — ждем вас в комментариях к этой статье!