APIOps: сочетание DevOps и GitOps для улучшения разработки API

Работая над постановкой краткосрочных и долгосрочных целей с клиентом, я сосредоточился на определении целей второго и третьего горизонтов в [Модели трех горизонтов McKinsey](https://www.mckinsey.com/business-functions/strategy-and (корпоративные финансы/наши идеи/долгосрочные идеи-три-горизонта-роста).

Для тех, кто не знаком с этой структурой, горизонты два и три сосредоточены на новых функциях и функциях следующего поколения. Главным в моем списке приоритетов для этого проекта было внедрение API-шлюза.

Основываясь на имеющихся у меня знаниях о Kong Gateway, «APIOps: сквозная автоматизация на протяжении жизненного цикла API» привлек мое внимание. Я впервые увидел термин «APIOps», и мне нужно было больше понять, особенно для моей роли технического архитектора сложного уровня обслуживания.

Мой вывод заключается в том, что APIOps можно обобщить следующим образом:

1. APIOps = DevOps + GitOps применяется к уровню микросервисов.

1. Активно использует спецификацию, например OpenAPI, для определения API на ранних этапах процесса.

1. Сокращает время выполнения работ от начала до конца.

1. Обещает улучшение качества производимых API.

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

Для этого упражнения мне нужно визуализировать APIOps с точки зрения DevOps и сосредоточиться на следующих основных концепциях:

• Дизайн и тестирование

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

• Обслуживание

Создание дизайна

В 2021 году я написал две публикации, в которых иллюстрировал ценность, которую API-шлюз может принести проектам и командам, предлагающим API для потребления:

• [Как я перестал программировать повторяющиеся сервисные компоненты с помощью Kong] (https://hackernoon.com/use-the-kong-gateway-to-stop-coding-repetitive-service-components-i24a34bp)

• Разрушение монолитной базы данных с помощью Kong

Поскольку Kong Gateway — это решение с открытым исходным кодом, мне кажется, что использование инструментов Kong в моем исследовании идеально. Тот факт, что Kong предоставляет базовую технологию API для целого ряда технологических лидеров (Cisco, GlaxoSmithKline, Honeywell, PayPal, Nasdaq, Samsung), еще раз подтверждает мое решение.

Предположим следующий дизайн:

1. Используйте OpenAPI, чтобы внедрить основанные на стандартах контракты в Insomnia.

1. Kong Konnect будет служить центром обслуживания для пользователей API.

1. Kong Gateway централизует общие аспекты, общие для микросервисов.

Рассмотрим следующую иллюстрацию, иллюстрирующую мой подход:

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

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

В результате такого подхода полностью СУХОЙ (не повторяйтесь) дизайн будет существовать от создания API до управления API. Это отлично подходит как для разработчиков сервисного уровня, создающих API, так и для разработчиков функциональных групп, использующих эти API. А как насчет инженеров DevOps, дополняющих эти команды?

Внедрение APIOps и DevOps

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

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

Давайте углубимся, чтобы понять, как Kong упрощает применение DevOps к разработке API.

Дизайн и тестирование

Insomnia — это гораздо больше, чем просто HTTP-клиент и редактор OpenAPI (YAML). Он может проверять, отлаживать и тестировать новые проекты API перед развертыванием в Kong Konnect. По этой причине Insomnia следует считать столь же важной для разработчиков сервисного уровня, как и их основную IDE, используемую для создания фактического сервисного API.

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

Статья [Speed-Review API Specifications with Insomnia] (https://konghq.com/blog/api-specifications/?utm_source=guest&utm_medium=devspotlight&utm_campaign=community) от Kong описывает каждый шаг этого процесса, включая использование Insomnia. для отправки кода в Kong Konnect ServiceHub.

Развертывание

С точки зрения DevOps эти же артефакты могут быть частью автоматизированной обработки непрерывной интеграции (CI) с использованием Inso, который версия командной строки Insomnia.

Ниже приведена иллюстрация, демонстрирующая, как Inso может выполнять автоматизированные задачи в рамках конвейера CI, находящегося в репозитории на основе git:

Документация [Introduction to Inso CLI] (https://docs.insomnia.rest/inso-cli/introduction) – отличный способ ускорить использование Inso с существующими конвейерами CI/CD.

Поддержание

На уровне шлюза API Kong предоставляет инструмент декларативной настройки (называемый decK) для обновления конфигураций, включая сквозные обновления для всех опубликованных API, работающих в Kong. Шлюз. Поток колоды показан ниже:

Например, мы можем использовать decK для изменения общего компонента ограничения скорости в API для удовлетворения потребностей бизнеса после публикации API. Приведенный выше поток позволяет извлечь существующую конфигурацию для анализа, которую можно обновить, а затем развернуть обратно в шлюз API, обрабатывающий компонент. Помимо обновлений на основе git, необходимых для внесения изменений, оставшийся поток процессов может быть частью конвейера CI/CD.

Заключение: APIOps с точки зрения DevOps

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

Команда Kong не только предоставляет отличный набор продуктов, который взаимодействует с каждым этапом разработки API, но также предоставляет необходимые инструменты для проверки, развертывания и обслуживания этих API. Еще более впечатляющей является способность работать на декларативном уровне и на уровне git, придерживаясь конвейерных подходов, которые продолжают рекомендовать инженеры DevOps.

С прошлого года я пытаюсь жить в соответствии со следующим заявлением о миссии, которое, как мне кажется, применимо к любому ИТ-специалисту:

«Сосредоточьте свое время на предоставлении возможностей/функциональности, которые повышают ценность вашей интеллектуальной собственности. Используйте фреймворки, продукты и услуги для всего остального».

- Дж. Вестер

Kong, безусловно, придерживается моей личной миссии, стремясь сделать APIOps реалистичным вариантом. С момента создания пакета продуктов Kong как декларативный дизайн, так и интеграция DevOps всегда были в центре внимания.

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

Хорошего дня!