Гибридное и мультиоблачное управление API: вызовы и выборы

1. Мультиоблачные и гибридные облачные решения

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

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

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

• Привязка к поставщику: Когда продукт облачного провайдера глубоко интегрирован в бизнес, перенос бизнеса в другое облако или полный уход из облака становится довольно сложной задачей. Это особенно часто встречается для продуктов PaaS или SaaS, которые имеют сильную связь с бизнесом. К сожалению, это часто происходит, когда бизнес находится в периоде быстрого роста, и лица, принимающие решения, упускают из виду эффект привязки при использовании облачных продуктов.
• Проблемы доступности: Здесь применим принцип диверсификации, который означает, что мы не кладем все яйца в одну корзину. В период масштабирования бизнеса организации часто отдают приоритет быстрому запуску продуктов и захвату доли рынка, пренебрегая инфраструктурой. Это может привести к отключениям электроэнергии или обрывам кабелей в регионе облака, что негативно скажется на бизнесе.

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

"Мультиоблако" означает одновременное использование нескольких публичных облаков, развертывание бизнеса зеркально или гетерогенно в этих облаках. При этом используются стандартные сервисы (чтобы избежать привязки к поставщику). Благодаря использованию мультиоблака, когда одно облако становится недоступным, влияние на бизнес можно минимизировать, обеспечивая непрерывность бизнеса путем изменения DNS-разрешения и включения резервного облака.

"Гибридное облако" означает, что организации, помимо использования одного или нескольких публичных облаков, также имеют свои частные облака (или центры обработки данных). В этом случае некоторые сервисы могут быть развернуты в частных облаках, а другие — в публичных облаках. Или все сервисы развернуты в облаке, а частное облако отвечает за управление и мониторинг. В любом случае, гибкость и доступность развертывания программного обеспечения значительно улучшаются после внедрения модели "мультиоблака" или "гибридного облака".

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

2. Необходимость управления API в сценариях мультиоблака и гибридного облака

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

Поддержка управления несколькими кластерами

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

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

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

Поддержка совместной работы

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

В частности, администраторы могут приглашать других членов организации для участия в управлении кластером API-шлюза, используя RBAC (управление доступом на основе ролей) или другие стратегии для назначения различных разрешений членам команды. Например, установка роли Organization Admin (возможность выполнять любые операции) для администратора и Service Admin (возможность поддерживать только несколько сервисов и маршрутов) для обычного разработчика. Такой подход обеспечивает безопасность операций при реализации совместной работы. Это также облегчает своевременное восстановление учетных записей или изменение разрешений в случае увольнения сотрудников или изменения их должностей.

Возможность работы на любой инфраструктуре

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

3. Решения

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

Разные решения в разных облаках

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

Преимущества включают:

1. Очень низкая стоимость использования, без необходимости развертывания или обслуживания.
2. Обычно поддерживается оплата по мере использования; на ранних этапах использования могут потребоваться минимальные затраты.

Недостатки включают:

1. Использование API-шлюзов в разных облаках часто несовместимо друг с другом, поэтому выполнение одной и той же конфигурации требует разных подходов.
2. Функциональность продуктов не симметрична среди разных провайдеров. Например, один провайдер может поддерживать mTLS, а другой — нет.
3. В сценарии "гибридного облака" может потребоваться выбор другого открытого или коммерческого API-шлюза и его развертывание в частном облаке пользователя.

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

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

Решение с открытым исходным кодом для API-шлюза

В качестве альтернативы использованию разных решений в разных облаках пользователи могут рассмотреть использование решений с открытым исходным кодом для API-шлюза, таких как Apache APISIX, Kong, Tyk, Traefik и т.д. Этот подход позволяет пользователям использовать один и тот же API-шлюз во всех облаках, включая частные центры обработки данных, что позволяет избежать проблем совместимости между разными решениями. Зрелый и надежный API-шлюз с открытым исходным кодом может помочь пользователям решить множество проблем в различных сценариях. Даже если он не охватывает все сценарии, эти API-шлюзы обычно позволяют пользователям расширять их различными способами. Например, Apache APISIX позволяет пользователям расширять его с использованием языков и технологий, таких как Go, Java, Python, Lua, WASM и т.д.

Однако эти API-шлюзы с открытым исходным кодом обычно используют стратегию Open Core, при которой основные функции продукта открыты, но возможности управления на уровне предприятия, такие как визуализированная консоль, управление несколькими кластерами, аудит, SSO (единый вход) и т.д., часто являются платными (интегрированы в их коммерческие продукты). Если пользователи не хотят платить, они могут только выбрать разработку собственной платформы управления (также известной как плоскость управления шлюза) для управления этими API-шлюзами, что означает необходимость найма штатного инженера для выполнения этой работы.

Приобретение SaaS-услуги для API-шлюза уровня предприятия

Если API-шлюзы с открытым исходным кодом удовлетворяют требованиям по функциональности, но стоимость самостоятельной разработки управления неприемлема, пользователи также могут рассмотреть возможность обращения к оригинальным производителям этих открытых программ (например, API7.ai за Apache APISIX, Kong Inc за Kong и Tyk Inc за Tyk и т.д.). Эти производители часто предоставляют различные продукты и услуги поддержки для API-шлюзов уровня предприятия. Особенно в сценарии "мультиоблака" и "гибридного облака" эти производители последовательно выпустили свои SaaS-продукты. SaaS-продукты для API-шлюза часто сосредоточены на стороне управления, предоставляя готовую к использованию консоль без необходимости беспокоиться о том, где развернут экземпляр API-шлюза (конечно, некоторые SaaS-услуги также поддерживают хостинг экземпляра API-шлюза, но это часто вызывает другие проблемы, такие как задержка при проксировании API).

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

Конечно, приобретение SaaS-услуг требует осторожности. Поэтому перед подтверждением заказа пользователи должны оценить SaaS-услугу по следующим аспектам:

1. Может ли эта SaaS-услуга удовлетворить текущие и будущие потребности использования?
2. Является ли поставщик SaaS-услуги профессиональным и заслуживающим доверия? Какие примеры использования у них есть?
3. Соответствует ли эта SaaS-услуга требованиям, таким как GDPR, и имеет ли отчеты аудита SOC2?
4. Есть ли у этой SaaS-услуги четкие условия SLA?
5. Как взимается плата за эту SaaS-услугу? Могут ли пользователи оценить будущие расходы на один год или несколько лет?

Полностью самостоятельная разработка

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

4. Заключение

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

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