Service mesh что это
Что такое Service Mesh?
И снова здравствуйте. В преддверии старта курса «Архитектор ПО» мы подготовили еще один полезный перевод.
Service Mesh – это конфигурируемый инфраструктурный уровень с низкой задержкой, который нужен для обработки большого объема сетевых межпроцессных коммуникаций между программными интерфейсами приложения (API). Service Mesh обеспечивает быструю, надёжную и безопасную коммуникацию между контейнеризированными и часто эфемерными сервисами инфраструктуры приложений. Service Mesh предоставляет такие возможности, как обнаружение сервисов, балансировку нагрузки, шифрование, прозрачность, трассируемость, аутентификацию и авторизацию, а также поддержку шаблона автоматического выключения (circuit breaker).
Service Mesh обычно реализуется путем предоставления каждому экземпляру сервиса экземпляра прокси, который называется Sidecar. Sidecar обрабатывают коммуникации между сервисами, производят мониторинг и устраняют проблемы безопасности, то есть все, что может быть абстрагировано от отдельных сервисов. Таким образом, разработчики могут писать, поддерживать и обслуживать код приложения в сервисах, а системные администраторы могут работать с Service Mesh и запускать приложение.
Istio от Google, IBM и Lyft, на данный момент является самый известной Service Mesh-архитектурой. А Kubernetes, который изначально разрабатывался в Google, сейчас является единственным фреймворком для оркестрации контейнеров, который поддерживается Istio. Вендоры пытаются создать коммерческие поддерживаемые версии Istio. Интересно, что нового они смогут привнести в проект с открытым исходным кодом.
Однако Istio – это не единственный вариант, поскольку разрабатываются и другие реализации Service Mesh. Паттерн sidecar proxy является наиболее популярной реализацией, как можно судить по проектам Buoyant, HashiCorp, Solo.io и другим. Существуют и альтернативные архитектуры: технологический инструментарий Netflix – это один из подходов, где функционал Service Mesh реализуется за счет библиотек Ribbon, Hysterix, Eureka, Archaius, а также таких платформ, как Azure Service Fabric.
Service Mesh также имеет свою собственную терминологию для компонентов-сервисов и функций:
Control Plane в Service Mesh распределяет конфигурацию между Sidecar Proxy и Data Plane.
Часто архитектура Service Mesh применяется для решения сложных операционных задач с использованием контейнеров и микросервисов. Пионерами в области микросервисов являются такие компании как Lyft, Netflix и Twitter, которые предоставляют стабильно работающие сервисы миллионам пользователей по всему миру. (Здесь вы можете познакомиться с подробным описанием некоторых архитектурных задач, с которыми столкнулся Netflix). Для менее требовательных прикладных задач скорее всего будет достаточно более простых архитектур.
Архитектура Service Mesh вряд ли когда-нибудь станет ответом на все вопросы, связанные с работой приложений и их доставкой. Архитекторы и разработчики обладают огромным арсеналом инструментов, и только один из них — молоток, который среди множества задач должен решать лишь одну – забивать гвозди. Microservices Reference Architecture от NGINX, например, включает в себя несколько различных моделей, которые дают непрерывный спектр подходов к решению задач с помощью микросервисов.
Элементы, которые объединяются в архитектуре Service Mesh, такие как NGINX, контейнеры, Kubernetes и микросервисы в качестве архитектурного подхода, могут быть не менее продуктивно использованы и в реализациях без Service Mesh. Например, Istio был разработан как полноценная архитектура Service Mesh, но модульность говорит о том, что разработчики могут выбирать и применять только необходимые им компоненты технологий. Помня об этом, необходимо сформировать четкое понимание концепции Service Mesh, даже если вы не уверены в том, что сможете когда-нибудь полноценно ее реализовать в приложении.
5 самых популярных вопросов при внедрении service mesh в корпорации на примере Istio
Не только на мировом, но и на российском рынке можно заметить волну интереса к технологиям сервисных сеток, или service mesh. Ниже под катом мы разберемся, какие задачи эта технология решает, как она развивалась, а также с какими вопросами сталкиваются корпорации при адаптации Istio у себя в ИТ-инфраструктуре.
Мое знакомство с service mesh было во многом случайным, когда в 2017 году мне на глаза попался анонс о сотрудничестве Google и IBM по созданию нового open source проекта. Не сказать, что партнерства крупнейших технологических компаний редки, но именно этот случай вызвал у меня большой интерес. Во-первых, примеров взаимодействия именно компаний Google и IBM все же не так много: пожалуй, наиболее известными фактами будут работа вокруг открытой аппаратной архитектуры OpenPOWER, а также наличие сервисов IBM в Google Cloud. Во-вторых, несмотря на наличие примеров, когда и Google, и IBM развивают один и тот же open source проект (Kubernetes или TensorFlow), случаев, чтобы обе эти компании стали именно основателями проекта, очень мало, и они достаточно уникальны. И, в-третьих, наличие среди основателей проекта IBM и Google компании Lyft – конкурента Uber как сервиса вызова такси, вызывало вопросы и неподдельный интерес. Тот анонс в 2017 году рассказывал о выпуске технологии Istio, предназначенной для управления взаимодействием различных сервисов. Поначалу не совсем очевидно, в чем заключается проблема и зачем создавать такой проект, так как подходов по управлению взаимодействием между сервисами было известно довольно много. Чтобы понять проблематику, стоит взглянуть на ситуацию шире и посмотреть на изменения в ИТ-архитектуре на тот момент времени.
Что такое service mesh
Причины появления и столь стремительно нарастающей популярности service mesh неразрывно связаны с изменениями в ИТ архитектуре. Представить появление service mesh без микросервисной архитектуры достаточно сложно – давайте посмотрим почему. Можно долго спорить, что такое микросервисная архитектура, так как единого и устоявшегося определения нет (и вообще эта тема заслуживает отдельной статьи), но для упрощения остановимся на следующих ключевых характеристиках: это небольшие автономные части бизнес-логики, реализованные как сервисы, каждый из которых имеет свой цикл сборки и поддержки. В таком случае логично задуматься о том, как эти небольшие сервисы будут взаимодействовать друг с другом и как контролировать этот процесс. Здесь и появляется service mesh. В реальной жизни эту технологию можно сравнить с дорожным навигатором. На дорогах могут случаться различные ситуации: аварии, заторы, выход из строя светофоров, а система позволяет вам добраться из пункта «А» в пункт «Б» наиболее оптимальным способом, зная обо всех произошедших событиях.
Ключевыми задачами, которые берет на себя service mesh, являются:
Эволюция развития service mesh
В настоящее время service mesh стал отдельным слоем и во многом стандартом де-факто современной ИТ-архитектуры на уровне инфраструктуры. Можно ли строить современные решения без service mesh и реализовывать этот функционал как-то по-другому? Конечно, да, только вопрос в удобстве, гибкости, времени реализации и дальнейшей поддержке решения. Безусловно, задачи, связанные с управлением трафика или балансировкой, можно решить самому на уровне кода для каждого из сервисов. Но так как микросервисная архитектура подразумевает существование десятков, сотен или даже тысяч различных сервисов, то реализовывать один и тот же функционал при разработке каждого из них совсем не удобно. Зачем разрабатывать один и тот же функционал десятки или сотни раз, если можно вынести его отдельно?
Первые реализации service mesh были сделаны на прикладном уровне. Самый известный пример – фреймворк (или набор библиотек) Netflix OSS, доступный для использования с 2012 года. В него вошли компоненты, реализующие функционал, присущий service mesh: с помощью Eureka производится обнаружение сервисов (service discovery), с помощью Hystrix – ряд паттернов обнаружений ошибок (circuit breaker), Zuul решает задачи динамической маршрутизации (dynamic routing).
На необходимость изменения этого подхода оказали сильное влияние следующие факторы:
Istio как пример следующей волны эволюции технологии использует sidecar (Envoy от Lyft), то есть прокси, который располагается рядом с каждым сервисом и берет на себя функционал по управлению политиками безопасности, трафиком, сбор телеметрии и пр. Это позволяет быть нейтральным к выбору языка программирования, иметь хорошую интеграцию с Kubernetes как стандарта де-факто по оркестрации контейнерных сред и не иметь никаких зависимостей от прикладной логики сервисов. По факту именно на этом шаге эволюции технологии service mesh произошло ее окончательное выделение в отдельный инфраструктурный слой как самостоятельный уровень современной ИТ-архитектуры.
Адаптация технологии в корпоративном мире
Все большая популярность микросервисной архитектуры и контейнерных технологий и те преимущества, которые они дают, не оставили в стороне большие российские корпорации, которые начали задумываться об использовании этих подходов у себя. Вместе с этим возникает ряд вопросов по использованию service mesh и, в частности, Istio. Многие сомневаются в том, что технология достаточно зрелая для использования в корпоративном мире, что обладает достаточным функционалом и способна выдерживать большие нагрузки. Ниже будут даны ответы на пять наиболее популярных вопросов, которые нам задавали ИТ сотрудники корпораций про использование Istio, чтобы помочь убедиться в ее готовности к внедрению.
Вопрос 1: Достигла ли технология Istio достаточной зрелости для внедрения в корпорациях?
Так как мы говорим о крупных организациях, то для них вопрос зрелости той или иной технологии является одним из самых первых. Что подразумевается под зрелостью? Параметрами зрелости могут быть функциональность, стабильность работы, количество промышленных внедрений, максимальная нагрузка, а также соответствие ряду нефункциональных требований, например, по отказоустойчивости или масштабированию. Важно понимать, что для каждой компании количественные значения каждого из параметров будут своими в зависимости от ее масштабов и сценариев использования.
Что можно сказать про Istio? С точки зрения стабильности работы в мире open source немаловажным является выпуск версии 1.0, которая сообществом контрибьюторов Istio была представлена еще летом 2018 года. Примерами по использованию технологии являются уже десятки компаний, наиболее известными среди которых являются Ebay, Yahoo и банк ING. Интересными примером является история использования Istio при эксплуатации истребителя F16. Отдельно стоит выделить факт, что ведущие облачные провайдеры IBM и Google предоставляют сервисы на базе Istio для своих клиентов. Более того, Istio используется даже как часть новых open source фреймворков. Пример: Kabanero, направленный на более быструю разработку приложений поверх контейнерной инфраструктуры.
С точки зрения нефункциональных требований в корпорациях уделяется большое внимание требованиям по отказоустойчивости, и здесь Istio предоставляет большое число опций по развертыванию, как внутри одного, так и нескольких кластеров Kubernetes. Ниже в статье мы рассмотрим вопрос об опциях развертывания подробнее. Думаю, излишне говорить, что все эти аргументы однозначно позволяют судить о том, что Istio как технология достигла достаточного уровня зрелости для внедрения в корпоративном сегменте для решения бизнес-критичных задач.
Вопрос 2: Service mesh — для новых сред с контейнерами, а что делать с традиционным ландшафтом на виртуальных машинах?
Service mesh принадлежит типу технологий, относящихся к cloud native, которые создавались в эру развития контейнеров. Но, вспоминая реальность ИТ ландшафта корпораций, можно заметить, что промышленных систем, работающих поверх контейнеров не так много, и корпорации стоят лишь в начале пути по их массовому использованию. Многие бизнес-критичные задачи по-прежнему работают на виртуальных машинах и здесь возникает вопрос: неужели для них нельзя использовать Istio?
Краткий ответ – конечно, можно. Istio позволяет создавать разные конфигурации с использованием как контейнерной инфраструктуры, так и виртуальных машин или даже bare metal. Для связи виртуальных машин и service mesh необходимо выполнить ряд действий, например обеспечить видимость IP-адресов кластера с Istio и пр. Более подробное описание и примеры можно найти здесь.
Вопрос 3: Какую модель развертывания выбрать?
Этот вопрос, между прочим, весьма непростой и затрагивающий много областей, включая как технические вещи (нефункциональные требования по отказоустойчивости, безопасности и производительности), так и организационные (структуру команд). Какие опции развертывания возможны?
Безусловно, внутри мультикластерного развертывания могут быть также варианты размещения контрольных панелей: не обязательно размещать одну контрольную панель на один кластер, несколько кластеров могут использовать одну контрольную панель.
На практике на определение опции развертывания уходит не одна неделя проектирования, так как архитекторам необходимо прийти к компромиссу между хорошим уровнем изоляции ресурсов и накладными расходами на взаимодействие между кластерами.
Вопрос 4: А какую нагрузку выдержит?
Так как речь идет о корпорациях, то, как правило, они обслуживают большое число клиентов и, соответственно, имеют на своих системах большие нагрузки. Поэтому вопрос абсолютно не праздный и на практике не редки случаи, когда та или иная новая технология не давала нужную производительность и не могла обеспечить предоставление сервисов компании по запросу клиентов.
Конечно, самый грамотный ответ на этот вопрос: зависит от множества факторов. То, как развернута система, какие требования по отказоустойчивости или изоляции, какая версия технологии используется – все эти факторы оказывают прямое воздействие на производительность. Но вряд ли этот ответ способен дать хоть какие-то оценки, поэтому посмотрим на уже имеющийся опыт других компаний. К сожалению, в открытых источниках сложно найти детальную информацию от компаний по их опыту использования Istio, но на различных встречах, митапах или конференциях уже в начале 2019 года одной из компаний в области информационной безопасности были представлены цифры в десятки тысяч транзакций в секунду (TPS) системы, использующей Istio. Многие корпорации провели пилотные проекты и получили результаты в несколько сотен транзакций в секунду. Много это или мало? Для примера, только несколько крупных банков России имеют нагрузки в несколько тысяч TPS на своих ИТ системах, поэтому оценка даже в несколько сотен TPS с лихвой покроет подавляющее большинство задач любой корпорации.
Вопрос 5: Когда будут нужные нам фичи?
Во время внедрения Istio технические специалисты организаций часто обращаются в IBM как к компании-основателю проекта с вопросами о сроках реализации конкретных новых фич технологии.
На этом вопросе можно хорошо показать разницу между проприетарным программным обеспечением от какого-либо вендора и миром open source. Многие корпорации с точки зрения своих ожиданий одинаково относятся и к тем, и другим технологиям, хотя в ряде моментов различия достаточно большие и ждать такой же ответственности от участников open source проекта, как от компании-производителя коммерческого ПО, странно. Безусловно, за большинством успешных open source проектов стоит одна или несколько компаний, которая, как правило, и является основателем. Но в отличие от коммерческого ПО, компания-основатель не может просто так взять и добавить фичу в проект без обратной связи от других контрибьюторов. Здесь есть и свои плюсы, и минусы. Бывали случаи, когда один из контрибьюторов брался за реализацию конкретной фичи, в которой были заинтересованы многие участники проекта, но срывал сроки из-за занятости и болезни, отодвигая релиз на несколько месяцев вперед. Поэтому в случае open source проекта гарантировать выход конкретной фичи в конкретный срок намного тяжелее, чем в случае с коммерческим ПО. С другой стороны, нет такой прямой зависимости от решения одной компании, так как реализацию может взять на себя другой участник проекта.
Поэтому четкого ответа на этот вопрос не существует, но есть ряд рекомендаций, которые позволят держать руку на пульсе происходящего в open source проекте. На примере Istio cписок рабочих групп проекта известен, их встречи и протоколы обсуждений открыты, доступна возможность задавать вопросы и описывать проблемы – во всех этих, а также многих других вещах представители корпораций могут участвовать. В текущий момент времени корпорации крайне осторожно принимают участие в жизни сообщества, и очень хочется надеяться, что в ближайшее время этот тренд изменится.
Вместо заключения
Что можно сказать в итоге? Несмотря на то, что Istio — достаточно молодая технология, ее текущий уровень зрелости и существующий функционал полностью отвечают требованиям корпораций. Видно, что среди крупных российских компаний интерес к Istio за последний год существенно вырос и все больше и больше ИТ команд начинают свои первые проекты, а ряд из них уже использует технологию в промышленной среде.
Для тех, кто хочет видеть Istio не только в своих ИТ системах, но и на полке или столе, мой коллега создал модель парусника как копию логотипа Istio для распечатки на 3D-принтере, которую можно скачать здесь.
Зачем мы делаем Enterprise Service Mesh
Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.
Популярность шаблона Service Mesh растет с популярностью облачных технологий. Он представляет собой выделенный инфраструктурный слой, который упрощает взаимодействие между различными сетевыми сервисами. Современные облачные приложения состоят из сотен и даже тысяч таких сервисов, каждый из которых может иметь тысячи копий.
Взаимодействие между этими сервисами и управление ими — ключевая задача Service Mesh. Фактически это сетевая модель из множества прокси, управляемая централизованно и выполняющая набор весьма полезных функций.
На уровне прокси (data plane):
Для чего нужен Service Mesh в корпоративном секторе
Использование Service Mesh приносит множество очевидных преимуществ. Прежде всего, это просто удобно разработчикам: для написания кода появляется технологическая платформа, которая существенно упрощает интеграцию в облачную инфраструктуру за счет того, что транспортный слой полностью изолирован от прикладной логики.
Кроме того, Service Mesh упрощает взаимоотношения поставщиков и потребителей. Сегодня поставщикам и потребителям API гораздо проще договориться об интерфейсах и контрактах самостоятельно, не привлекая для этого специального интеграционного посредника и арбитра – корпоративную сервисную шину. Такой подход существенно влияет на два показателя. Увеличивается скорость вывода новой функциональности на рынок (time-to-market), но при этом повышается стоимость решения, так как интеграцию приходится делать самостоятельно. Использование Service Mesh командами разработки бизнес-функциональности позволяет сохранить здесь баланс. В итоге поставщики API могут сфокусироваться исключительно на прикладной составляющей своего сервиса и просто опубликовать его в Service Mesh — API сразу станет доступен всем клиентам, а качество интеграции будет production ready и не потребует ни одной строчки дополнительного кода.
Следующим преимуществом является то, что разработчик, используя Service Mesh, фокусируется исключительно на бизнес-функциональности — на продуктовой, а не на технологической составляющей своего сервиса. Например, уже не приходится думать о том, что в ситуации, когда сервис будет вызываться по сети, где-то может произойти обрыв соединения. Кроме того, Service Mesh помогает сбалансировать трафик между копиями одного и того же сервиса: если одна из копий «умерла», то система переключит весь трафик на оставшиеся живые копии.
Service Mesh — это хорошая основа для создания распределенных приложений, которая скрывает от клиента детали обеспечения вызовов его сервисов как изнутри, так и снаружи. Все приложения, использующие Service Mesh, на транспортном уровне изолированы и от сети, и друг от друга: никакой связи между ними нет. При этом разработчик получает полный контроль над своими сервисами.
Нельзя не отметить, что обновление распределенных приложений в среде, где используется Service Mesh, становится проще. Например, blue/green-развертывание, при котором для установки доступны две среды приложения, одна из которых не обновляется и находится в режиме ожидания. Откат на прошлую версию в случае неудачного релиза осуществляется специальным роутером, с ролью которого прекрасно справляется Service Mesh. Для обкатки новой версии можно использовать и канареечный релиз — переключить на новую версию только 10% трафика или запросы от пилотной группы клиентов. Основной трафик идет на старую версию, ничего не ломается.
Также Service Mesh дает нам контроль SLA в реальном времени. Система распределенных прокси не позволит завалить сервис, когда кто-то из клиентов превысит выданную ему квоту. Если пропускная способность по API ограничена, никто не сможет заддосить его большим количеством транзакций: Service Mesh стоит перед сервисом и не пропускает лишний трафик. Он просто будет отбиваться в интеграционном слое, а сами сервисы продолжат работать, не замечая этого.
Если компания хочет сократить расходы на развитие интеграционных решений, Service Mesh также выручает: на его open-source версии можно перейти с коммерческих продуктов. Наш Enterprise Service Mesh базируется на open-source версии Service Mesh.
Еще одно преимущество — наличие единого полноценного набора интеграционных сервисов. Поскольку вся интеграция строится через этот промежуточный слой, мы можем управлять всем интеграционным трафиком и связями между приложениями, которые формируют бизнес-ядро компании. Это очень удобно.
И наконец Service Mesh стимулирует компанию к переходу на динамическую инфраструктуру. Сейчас многие смотрят в сторону контейнеризации. Распиливать монолит на микросервисы, все это красиво внедрять — тема находится на подъеме. Но когда ты пытаешься перевести на новые рельсы систему, которая уже много лет в продакшне, то сразу сталкиваешься с целым рядом проблем: затолкать все это в контейнеры и развернуть на платформе непросто. А внедрение, синхронизация и взаимодействие этих распределенных компонентов —еще одна сложнейшая тема. Как они будут друг с другом общаться? Не будет ли каскадных сбоев? Service Mesh позволяет решить часть этих проблем и облегчить миграцию со старой архитектуры на новую за счет того, что про логику сетевого обмена можно забыть.
Зачем нужна кастомизация Service Mesh
У нас в компании уживаются вместе сотни систем и модулей, а runtime очень нагружен. Так что простого паттерна, когда одна система вызывает другую и получает ответ, недостаточно, потому что в production мы хотим большего. Что еще нужно от корпоративного Service Mesh?
Сервис обработки событий
Представим, что нам нужно сделать real-time event processing — систему, которая в реальном времени анализирует действия клиента и может сразу сделать ему релевантное предложение. Чтобы реализовать подобную функциональность, используется архитектурный паттерн под названием event-driven architecture (EDA). Ни один из актуальных Service Mesh такие паттерны нативно не поддерживает, а ведь это очень важно, особенно для банка!
Довольно странно, что «удаленный вызов» Remote Procedure Call (RPC) поддерживают все версии Service Mesh, а с EDA они не дружат. Потому что Service Mesh — это подобие современной распределенной интеграции, а EDA — очень актуальный архитектурный паттерн, который позволяет делать уникальные вещи в плане клиентского опыта.
Наш Enterprise Service Mesh данную проблему должен решать. Кроме того, мы хотим видеть в нем реализацию гарантированной доставки, потоковой и комплексной обработки событий с использованием разнообразных фильтров и шаблонов.
Сервис передачи файлов
Помимо EDA было бы неплохо иметь возможность передавать файлы: в масштабах Enterprise очень часто возможна только файловая интеграция. В частности, используется архитектурный паттерн ETL (Extract, Transform, Load — «извлечение, преобразование, загрузка»). В нем, как правило, все обмениваются исключительно файлами: используются большие данные, которые нецелесообразно пихать отдельными запросами. Возможность нативной поддержки передачи файлов в Enterprise Service Mesh дает необходимую для бизнеса гибкость.
Сервис оркестрации
В крупных организациях почти всегда есть разные команды, которые делают разные продукты. Например, в банке одни команды работают с депозитами, а другие — с кредитными продуктами, и таких кейсов достаточно много. Это разные люди, разные команды, которые делают свои продукты, разрабатывают свои API и предоставляют их другим. И очень часто возникает потребность в композиции этих сервисов, а также имплементации сложной логики последовательного вызова набора API. Для решения данной проблемы необходимо решение в интеграционном слое, которое позволит упростить всю эту композитную логику (вызов нескольких API, описание маршрута запросов и т.д.). Это и есть сервис оркестрации в Enterprise Service Mesh.
AI и ML
Когда микросервисы общаются через единый интеграционный слой, Service Mesh, естественно, знает все о вызовах каждого сервиса. Мы собираем телеметрию: кто кого вызывал, когда, как долго, сколько раз и так далее. Когда этих сервисов сотни тысяч, а вызовов — миллиарды, то все это накапливается и формирует Big Data. Эти данные можно проанализировать средствами ИИ, machine learning и пр., а потом сделать на основе результатов анализа какие-то полезные вещи. Было бы уместно хотя бы частично передать искусственному интеллекту управление всем этим сетевым трафиком и вызовами приложений, интегрированных в Service Mesh.
Сервис API Gateway (Шлюз API)
Как правило, в Service Mesh есть прокси и сервисы, которые обращаются друг с другом внутри доверенного периметра. Но существуют еще и внешние контрагенты. Требования к API, предоставляемым этой группе потребителей, намного серьезнее. Эту задачу мы делим на две основные части.
Сервис поддержки специфических протоколов и форматов данных (шлюз АС)
На текущий момент большинство решений Service Mesh умеют нативно работать только с трафиком HTTP и HTTP2 или в урезанном режиме на уровне TCP/IP. У Enterprise Service Mesh появляется много других весьма специфических протоколов передачи данных. Одни системы могут использовать брокеры сообщений, другие интегрированы на уровне баз данных. Если в компании есть SAP, то он также может использовать собственную систему интеграции. Причем все это работает и является важной частью бизнеса.
Нельзя просто сказать: «Давайте откажемся от legacy и сделаем новые системы, которые смогут использовать Service Mesh». Чтобы подружить все старые системы с новыми (на микросервисной архитектуре), системам, которые могут использовать Service Mesh, понадобится какой-то адаптер, посредник, шлюз. Согласитесь, было бы неплохо, если бы он поставлялся в коробке вместе с сервисом. Шлюз АС как раз и может поддержать любой вариант интеграции. Только представьте, вы просто устанавливаете Enterprise Service Mesh, и он уже готов взаимодействовать со всеми протоколами, которые вам нужны. Для нас такой подход очень важен.
Примерно так мы представляем корпоративную версию Service Mesh (Enterprise Service Mesh). Описанная кастомизация решает большинство проблем, возникающих при попытках использовать готовые open-source версии интеграционной платформы. Появившись всего пару лет назад, архитектура Service Mesh продолжает развиваться, и мы рады, что можем внести вклад в ее развитие. Надеемся, что наш опыт будет вам полезен.