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

Статья составлена из переводов сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway.

Примечание. Термин API Gateway, который обозначает саму концепцию, мы всегда переводим в статье как API-шлюз, а конкретную реализацию этой концепции, Kubernetes Gateway API, нередко называем сокращенно — Gateway API.

Балансировщики нагрузки, обратные прокси и API-шлюзы: чем пахнут ремесла

Балансировщики нагрузки: диспетчеры трафика

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

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

Обратные прокси: почтовые операторы

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

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

API-шлюзы: библиотекари

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

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

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

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

API Gateway и Gateway API

В этой части статьи рассматривается адаптация API-шлюзов к требованиям современных нативных облачных приложений, в том числе концепция API-шлюза как части облачной операционной системы, роль новых проектов Kubernetes Gateway API и Envoy Gateway, а также потенциальные улучшения.

Роль API-шлюза в нативных облачных приложениях

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

Типичное нативное облачное приложение включает в себя различные компоненты, в том числе фронтенд, сервисы Backend For Frontend (BFF), сервисы бэкенда и базу данных. Давайте рассмотрим каждый из компонентов подробнее и выясним, насколько важную роль в оркестрации и управлении коммуникацией между ними играет API-шлюз.

*Рисунок 1. Архитектура нативного облачного приложения*

Компоненты нативных облачных приложений

Frontend. Фронтенд — это часть, обращенная к пользователю. Она отвечает за отображение пользовательского интерфейса и взаимодействие с конечными пользователями. Фронтенд состоит из веб- или мобильных приложений, которые общаются с внутренними сервисами через API, предоставляемые API-шлюзом. Компоненты фронтенда создаются с использованием фреймворков вроде React, Angular или Vue.js и должны быть легковесными, отзывчивыми и масштабируемыми, чтобы эффективно обрабатывать запросы пользователей.

Сервисы Backend For Frontend (BFF). Являясь неотъемлемой частью нативных облачных приложений, BFF-сервисы представляют собой специализированные компоненты, которые выступают в роли посредников, агрегируя и преобразуя данные, поступающие от бэкенд-сервисов, — все это ради удовлетворения различных потребностей фронтенда. Они инкапсулируют бизнес-логику, выполняют аутентификацию и авторизацию, оптимизируют доставку данных для повышения производительности и удобства работы пользователей. API-шлюз обеспечивает маршрутизацию запросов от фронтенда к соответствующему сервису BFF исходя из функциональной задачи.

Бэкенд-сервисы. Облачные приложения, как правило, состоят из нескольких внутренних сервисов, каждый из которых отвечает за определенный набор функций или микросервисов. Эти сервисы спроектированы с акцентом на минимальную взаимосвязанность, независимость в развертывании и способность к горизонтальному масштабированию. Бэкенд-сервисы взаимодействуют друг с другом через API, и API-шлюз играет важную роль в маршрутизации и распределении нагрузки между ними. Часто они строятся с использованием таких технологий, как Node.js, Java, Python, Ballerina или Go, и используют контейнерные технологии для развертывания и масштабирования.

Базы данных. Для хранения и управления данными приложения может использоваться либо традиционная реляционная база данных, либо база данных NoSQL (в зависимости от конкретных требований приложения).

Роль API-шлюзов

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

Организации с большим количеством сервисов обычно группируют их по бизнес-доменам. Для этого используются принципы доменно-ориентированного проектирования (domain-driven design, DDD). Когда сервисы в домене связываются с сервисами в других доменах, вызовы обычно проходят через API-шлюз. В таких случаях, как правило, применяются два API-шлюза: один для внутренних API, другой — для внешних.

*Рисунок 2. Шлюзы API в нативной облачной архитектуре*

Kubernetes как облачная операционная система и API-шлюзы как ее часть

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

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

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

По мере того как Kubernetes развивается в качестве операционной системы для облака, API-шлюз становится неотъемлемой частью этой ОС. С ростом популярности нативных облачных приложений API-шлюз превратился в важнейший компонент инфраструктуры, необходимый для построения приложений и управления ими. Это уже не просто отдельный сервис, а неотъемлемая часть облачной операционной системы. Такой сдвиг обусловлен потребностью в стандартизированном и централизованном подходе к управлению API — как это уже сделано для сервисов и задач (jobs) в нативной облачной экосистеме.

Абстракция для API

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

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

Kubernetes Gateway API

Понимая, что управление API в облачном ландшафте — ключевая проблема, сообщество Kubernetes разработало Kubernetes Gateway API. Gateway API призван сделать API полноправным элементом Kubernetes, предоставляя стандартизированный способ для определения API-шлюзов и управления ими в экосистеме Kubernetes.

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

На днях в блоге Kubernetes появилась новость о выходе ingress2gateway, в которой тоже содержатся интересные подробности по теме Gateway API и упоминается, что GA (General Availability) релиз Gateway API выйдет в течение нескольких недель.

Проект Envoy Gateway

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

Envoy выступает в роли мощного и гибкого прокси-сервера для уровня данных (data plane), который управляет трафиком между внешними клиентами и микросервисами, работающими на Kubernetes. Расширяемая архитектура позволяет интегрировать его с различными механизмами аутентификации, service mesh и другими облачными компонентами.

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

Прощай, API-шлюз. Да здравствует Gateway API!

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

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

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

Сдвиг в настройке и управлении API

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

Этот сдвиг позволяет разработчикам и командам эксплуатации расширить контроль над процессом настройки API. Теперь можно задавать правила маршрутизации, политики безопасности и преобразования для API, используя привычные определения ресурсов Kubernetes. Кроме того, Gateway API позволяет управлять конфигурациями API-шлюзов в рамках концепции «инфраструктура как код», обеспечивая согласованность, версионность и масштабируемость.

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

Заключение

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

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

P.S.

Читайте также в нашем блоге:

Что такое API-шлюзы и Gateway API и почему за ними будущее нативных облачных приложений