Ранее уже писал о применении API Gateway и даже выделил преимущества и недостатки, но не ответил на вопрос: а нужен ли вам API Gateway? Для ответа на этот вопрос мы немного углубимся в топологию команд и вопросы стоимости и поддержки.
Какие задачи решает API Gateway?
Технические задачи
Подробнее о сквозной функциональности в предыдущей статье, ниже краткая выдержка того, что можно реализовать в шлюзе:
- Безопасность (аутентификация и авторизация)
- Диспетчеризация
- Балансировка
- Разрешение зависимостей
- Трансформации данных транспортного уровня
- …
Здесь же можно реализовать общую логику для проведения A/B тестов, включение/выключение Feature Flags, обработку ошибок от бэкенда, переключение языков.
Помимо сквозной функциональности API Gateway может задавать общий формат контроля версий (в URL, в query string, в заголовках). Это особенно важно, если у сервисов различаются подходы («исторически сложилось») или вы находитесь на половине пути в переходе от одного способа версионирования к другому.
Не стоит забывать и о том, что именно на 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 может предоставить такое поведение в виде 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)
- …
Это те вопросы, помимо сугубо технических, на которые мы должны найти ответы — это прямое влияние на стоимость решения в целом.
Помочь нам в этом могут:
- Текущая и целевая архитектура
- Текущая и желаемая структура организации (с точки зрения динамики взаимодействия)
- Закон Конвея
Напомню закон Конвея: архитектура решения повторяет коммуникационные связи между структурами организации. Его инверсивная версия рекомендует развивать структуру команд и организации таким образом, чтобы архитектура развивалась вслед. В итоге получаем изоморфизм между технической и бизнес-архитектурой.
Попробуем найти ответ на вопрос «Нужен ли вам API Gateway» через призму того, кто его будет развивать и поддерживать и к какой целевой архитектуре/структуре организации хочется прийти.
Варианты организационных структур
Внешний или внутренний архитектор
Либо внешний архитектор/архитектурный комитет задает всем правила разработки API, либо внутренний. В случае соблюдений этих правил командами, за шлюзом остается разве что проксирование запросов с закрытием технических аспектов.
Выделенная команда
Выделенная команда поддерживает и развивает API Gateway. Дорогое решение, с какой стороны не посмотри: дополнительные люди, дополнительные зависимости, дополнительные затраты на обсуждения и согласования. Появляется иллюзия того, что команды не отвлекаются на развитие API Gateway, но затраты на координацию могут значительно превысить стоимость отвлечения от разработки бизнес-функциональности.
Платформенная команда
Команда платформы подготавливает API Gateway. Каждая команда может развернуть его для себя самостоятельно, например из контейнера. Платформенная команда задает правила, которым обязаны следовать команды, реализует доступы к внешним системам. Все, что касается продуктовой составляющей остается в руках команд.
Совместные договоренности о развитии API
Команды или отдельные участники команд собираются раз в оговоренное время и вырабатывают общие правила разработки API. Архитектор может выступать ведущим/модератором такой встречи. Правила, выработанные и принятые командами будут соблюдаться с большей вероятностью, чем если правила диктуются извне.
Совместное владение API Gateway
Модель, схожая с Inner Sourcing. Хорошо работает в связке с контрактным тестированием и при наличии договоренностей между командами о развитии API.
Нужен ли вам API Gateway?
Помимо вопросов стоимости, стоит задать себе еще один вопрос:
Какую командную динамику вы хотите получить, учитывая текущий контекст компании?
Это очень важный вопрос с точки зрения развития компании. Подходы, в которых ограничено взаимоедйствие между командами, одновременно ограничивают взаимное обучение. Но если в текущей культуре/структуре команды не общаются, но отлично исполняют правила, то может подойти подход с архитектором, задающим правила. При этом, если цель — перейти к модели общего владения, то стоит подумать о том, чтобы пройти от правил, задаваемых архитектором к совместным договоренностям и общему владению. Или к платформенной команде, особенно если эффект от повторного использования будет существенным.
