Управление несколькими облаками с помощью шлюза API и сервисной сетки — часть 1

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

Инфраструктура: от облака к мультиоблаку

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

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

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

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

Шлюз API: связь на бизнес-уровне

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

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

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

Шлюзы API можно расширять с помощью сторонних API и подключаемых модулей, которые уже доступны или могут быть созданы специально для нужд организации. Многие организации, такие как Xero, например, предоставляют свою платформу партнерам для создания услуг и продуктов на ее основе. С точки зрения ИТ-операций некоторые из API-интерфейсов поставщиков, которые чаще всего интегрируются со шлюзами API организации, — это Okta для Oauth, AWS Lambda для бессерверных приложений и инструменты мониторинга, такие как Datadog. Шлюз API обеспечивает предсказуемость и согласованность интеграции приложений.

Жизненный цикл шлюза API

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

Управление жизненным циклом API включает в себя множество шагов, как показано ниже.

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

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

Шлюзы API, построенные на мультиоблачной инфраструктуре

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

Лучшие решения шлюза API

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

В верхней части списка находятся Apigee и Mulesoft. Apigee была приобретена Google несколько лет назад после успешного старта в области управления API. С тех пор Google интегрировал Apigee со своей облачной платформой Google. Mulesoft также была приобретена Salesforce в ходе исторической сделки на 6,5 млрд долларов. Это пространство было занято и росло сейчас в новую эру Kubernetes.

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

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

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

Шлюзы API: незаменимое, но не полное решение

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