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

В первой части этой серии, состоящей из двух частей, мы обсудили появление мультиоблака как новой нормы для корпоративных облачных конфигураций. Мы также увидели, что шлюз API имеет важные функции для управления многооблачными приложениями — они централизованно управляются глобально распределенными. Они созданы для соединения приложений и служб с использованием общей структуры. Они ускоряют интеграцию в предприятие. Мы также увидели лучших поставщиков в этой области — Apigee, Mulesoft, Kong, Tyk и AWS API Gateway. В этом посте мы обсудим мощное дополнительное решение для шлюзов API — сервисные сетки. Мы также обсудим, как они могут работать вместе, чтобы помочь вам получить максимальную отдачу от мультиоблачной установки.

Сервисная сетка: связь на уровне инфраструктуры

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

По словам Уильяма Моргана, одного из создателей сервисной сетки Linkerd с открытым исходным кодом, «сервисная сетка — это инструмент для добавления функций наблюдения, безопасности и надежности в приложения путем вставки этих функций на уровне платформы, а не на уровне приложения». Сетевые сервисы, такие как Istio и Linkerd, используют модель «сайдкара», когда они внедряют прокси в каждый модуль в Kubernetes. В качестве вспомогательного средства для многих инструментов сервисной сетки используется Envoy. Эти sidecars обрабатывают связь между микросервисами.

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

Сервисная сетка: плюсы и минусы

Инструменты Service Mesh имеют свои преимущества и недостатки, которые необходимо учитывать. Это комплексные сетевые решения, способные справляться со сложными распределенными приложениями. Они обеспечивают более глубокую видимость связи между службами.

Тем не менее, они имеют некоторые недостатки, которые нельзя игнорировать. Во-первых, инструменты сервисной сетки сложно настроить. Для запуска первого экземпляра Istio требуется крутая кривая обучения и хорошее понимание всей системы. Сложная архитектура затрудняет управление в масштабе. Многие компоненты необходимо регулярно обновлять, поддерживать в безопасности и адаптировать в соответствии с приложениями. Тем не менее, есть и положительные стороны, и некоторые решения Service Mesh, такие как Linkerd, проще в настройке и эксплуатации, чем другие.

Кроме того, некоторое совпадение между сервисной сеткой и API-шлюзом затрудняет определение места сервисной сетки в архитектуре.

Сервисная сетка и шлюзы API работают вместе

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

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

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

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

Инструменты сервисной сетки сегодня

[tg_youtube video_id="cAMsONJadyI"]

Когда дело доходит до реализации сервисной сетки, вариантов не так много, как у шлюзов API, но выбор есть. Существуют Istio и Linkerd с открытым исходным кодом, которые на сегодняшний день являются самыми популярными инструментами сервисной сетки. Linkerd является старшим из двух и был инструментом, который создал пространство. У Linkerd небольшое, но сильное сообщество разработчиков открытого исходного кода, и они быстро встают и приступают к работе. Зрелый продукт, он регулируется CNCF и хорошо интегрирован с Kubernetes.

Istio ворвался на сцену позже, но переживает взрывной рост благодаря поддержке таких компаний, как Google, и широкому набору функций. Тем не менее, это вызывает озабоченность, поскольку отрасль хотела бы, чтобы такой важный инструмент не находился под контролем одной компании, такой как Google, а управлялся консорциумом, таким как CNCF. Недавнее переключение лицензирования Elasticsearch с Apache v2.0 на SSPL является одним из примеров того, как проекты с открытым исходным кодом могут пойти не так, если не будут управляться нейтрально и ответственно.

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

Все вышеперечисленные инструменты сервисной сетки имеют открытый исходный код — сегодня на рынке не так много коммерческих решений для сервисной сетки. Google включает управляемый сервис Istio в свое предложение Anthos. Это напоминание о том, что для инструментов сервисной сетки еще только начинается.

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

Сервисные сетки и шлюзы API: лучше вместе в многооблачном мире

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