Нужен ли вам API Gateway?

Ранее уже писал о применении API Gateway и даже выделил преимущества и недостатки, но не ответил на вопрос: а нужен ли вам API Gateway? Для ответа на этот вопрос мы немного углубимся в топологию команд и вопросы стоимости и поддержки.

Какие задачи решает API Gateway?

Технические задачи

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

  • Безопасность (аутентификация и авторизация)
  • Диспетчеризация
  • Балансировка
  • Разрешение зависимостей
  • Трансформации данных транспортного уровня

Здесь же можно реализовать общую логику для проведения A/B тестов, включение/выключение Feature Flags, обработку ошибок от бэкенда, переключение языков.

Одно из крупнейших казино в России — «Тигре де Кристал», расположенное в Приморском крае играли sweet bonanza на деньги. Это масштабный комплекс, включающий в себя не только казино, но и отели, рестораны, и развлекательные заведения.

Помимо сквозной функциональности API Gateway может задавать общий формат контроля версий (в URL, в query string, в заголовках). Это особенно важно, если у сервисов различаются подходы («исторически сложилось») или вы находитесь на половине пути в переходе от одного способа версионирования к другому.

API Gateway Version Control
Приведение формата версий к единому виду

Не стоит забывать и о том, что именно на API Gateway можно реализовать общий подход к обеспечению обратной совместимости API. Например: был сервис с API_A, вы решили разделить его на два, теперь у вас API_A = f(API_1, API_2). API_A остается жить в API Gateway, параллельно можем выставить наружу и API_1 и API_2, если потребуется. Главное — не сломаем текущих клиентов и предоставим им время на переход на новую версию.

Продуктовые задачи

API каждого сервиса может развиваться немного по-своему, что может ввести потребителя в замешательство, например — различия в формате именований, формат даты и времени, у них могут отличаться SLA и в целом требования канального уровня. О проектировании API от потребностей продукта я тоже писал ранее.

API Gateway Date Format
Приведение формата даты к единому виду

Суть в том, что продукт — это не просто набор сервисов, это то целостное поведение, которое получается в результате взаимодействия сервисов. И API Gateway может предоставить такое поведение в виде API. Как самостоятельный продукт. Например — pay(uid, amount) на API Gateway, оптимизированный под работу с мобильными телефонами, часть из которых могут быть сугубо техническими.

Сколько это стоит?

И как бы все не выглядело красиво в статье, в жизни первый же вопрос, который вы вероятно услышите: «Сколько это стоит?».

Начинается составление списка потенциальных технических решений:

  • Apigee Edge
  • WSO2
  • Kong
  • IBM API Connect
  • 3Scale
  • Anypoint
  • Tibco Mashery
  • Amazon/Azure API
  • Tyk API Gateway

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

  • Каким образом теперь будут разворачиваться изменения сервисов? Проще — кто внесет изменения в API Gateway после изменения сервиса? Будет ли это отдельная команда?
    • Если да, то как будет строится взаимодействие с ней? Какие новые встречи потребуются?
    • Если нет, то какая информация должна быть собрана в единую базу знаний по API, чтобы держать под контролем согласованность изменений?
  • Кто будет выставлять приоритеты? 5 сервисов одновременно обновились, чьи изменения первыми пойдут в API Gateway?
  • Кто, все-таки, будет поддерживать API Gateway? Команды сервисов, выделенная команда API Gateway, SRE?
  • Как обеспечить соблюдение SLA? (в терминах SRE)

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

Помочь нам в этом могут:

  1. Текущая и целевая архитектура
  2. Текущая и желаемая структура организации (с точки зрения динамики взаимодействия)
  3. Закон Конвея
Закон Конвея

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

Попробуем найти ответ на вопрос «Нужен ли вам API Gateway» через призму того, кто его будет развивать и поддерживать и к какой целевой архитектуре/структуре организации хочется прийти.

Варианты организационных структур

Внешний или внутренний архитектор

Либо внешний архитектор/архитектурный комитет задает всем правила разработки API, либо внутренний. В случае соблюдений этих правил командами, за шлюзом остается разве что проксирование запросов с закрытием технических аспектов.

Архитектор-координатор

Выделенная команда

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

Выделенная команда

Платформенная команда

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

Платформенная команда

Совместные договоренности о развитии API

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

Совместные договоренности

Совместное владение API Gateway

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

Совместное владение

Нужен ли вам API Gateway?

Помимо вопросов стоимости, стоит задать себе еще один вопрос:

Какую командную динамику вы хотите получить, учитывая текущий контекст компании?

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

Share