Централизованная шина vs Service Mesh: как митап превратить в баттл

Когда мы поняли, что проводить очередной митап нам будет скучно, то решили превратить его в нечто более остросюжетное. А именно в дуэль, в поединок ^[1] между двумя интеграционными подходами — ESB и Distributed — честь которых защищали тяжеловесные эксперты. В этом посте расскажем, как шел бой, и узнаем победителя.

Пара слов о формате

За централизованную шину выступил Александр Трехлебов ^[2], наш корпоративный архитектор. За децентрализацию — Андрей Трушкин, руководитель центра инноваций и перспективных технологий Промсвязьбанка. Они по очереди выступили с докладами о своих технологиях и ответили на разные вопросы, провокационные и не очень. Вот как оно было.

Почему ESB — это круто?

Для начала следует ввести в курс дела и рассказать, как все начиналось. Многие наверняка помнят, что на самом первом этапе всё происходило без всякой интеграции, когда каждая система общалась и проводила свое интеграционной тестирование с каждой другой системой.

Соответственно, если человек увольнялся или еще что-то с ним происходило, то никто не знал, как это все будет работать. Каждый комп взаимодействовал с каким-то сервером. Какой протокол, какое взаимодействие? Это все знал только тот человек, который работал в системе.

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

Далее выяснилось, что чаще всего с шиной общаются через очереди или через REST.

Со временем, правда, необходимость в шине и REST во многих случаях отпала. Но это выглядело как откат назад, важные вопросы повисли снова:

• Как осуществлять оркестрацию, если нет шины. Где это будет происходить?
• Как быть с форматами данных и протоколов?

Кроме того, производительность в централизованной системе гораздо лучше, чем в Distributed. Можно и на скорость рассчитывать, и на объем, и на доступность. Всё это потому, что это — одна система, обслуживанием которой занимается определенная команда.

Насколько уязвима эта система? Что будет, если один компьютер будет взломан?

Всегда есть резервирование и централизация. В случае, что кто-то один вышел из строя, то система будет работать.

Кто отвечает за шину? Ваша же команда или сторонние разработчики?

Во внутренней команде мы делаем операционные сервисы, обеспечиваем надежность, мониторинг. Если что-то не работает, мы знаем, где искать. Существует вопрос: «Можно ли доверять вендорам в таких случаях и сторонним командам?» Здесь нужен хороший мониторинг. Потому что за качество, в любом случае, отвечает внутренняя команда.

По мере развития шины сервисы не становятся связанными. Вы меняете сервисы релизами или как? Как быть с Agile?

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

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

Как долго команда ищет нужный ей сервис, и где она его ищет?

Все имеют мечту о том, чтобы существовала карта мира, на которой по континентам разбросаны все основные области бизнеса. И это даже частично реализовано. Туда заходит аналитик и начинает усиленно бродить по континентам, через какое-то время находит то взаимодействие, которое нужно. Дальше, если все подходит идеально, он его просто использует. Если нет — описывает в ТЗ, какие ему нужно дополнения. Было бы здорово иметь такой вариант, но пока актуально менее удобные системы, которые требуют намного больше времени и сил для работы с ними.

А может быть Service Mesh круче?

Начнем с того, что за 3-4 года действительно многое изменилось. Но что именно произошло? Произошла та самая банальность, которую регулярно повторяют все спикеры, и мимо которой мы также не можем пройти: мир меняется.

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

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

А теперь представим, что систем в компании не 20 — ведь она стремится перейти к той самой архитектуре, которую называют модным словом «микросервисы». А что такое микросервис? Существует много определений, одно из них периодически использует Мартин Фаулер: это сервис, который в состоянии разработать mid-разработчик за один спринт. Представим сколько таких сервисов будет в крупной компании. Например, Netflix оценивает количество своих микросервисов в 800-900. В принципе, в компании, которая стремится построить партнерскую внешнюю экосистему, эти сервисы могут перевалить и за тысячу. А ведь каждый из таких сервисов в перспективе выдерживает грандиозную нагрузку и должен развиваться независимо.

А что с шиной? Если шина остается этим общим комплексом между ними, то получается, что она становится узким местом и задерживает разработку сервисов. Не просто потому, что она ждет эти самые сервисы, а потому, что она развивается отдельной командой, людьми, которые владеют этими самыми технологиями и навыками.

И теперь представим: у нас развивается, работает несколько десятков продуктовых команд. И каждая из них пилит несколько сервисов. А шину ведут две команды. Естественно эти команды с высокой степенью вероятности не смогут развивать эту самую интеграцию с необходимым уровнем скорости и качества.

Возникает вопрос: «Как нам обеспечить такую же быструю скорость, не теряя при этом доступности, безопасности и так далее?». Ответ очень простой: «Пусть эти сервисы взаимодействуют напрямую, без явного посредника».

Тогда поднимается следующий важный вопрос: «Как сервисам узнать друг о друге?». И здесь ответ тоже очень простой: можно придумать такую систему, с которой сервисы сами сообщали бы о себе. То есть в тот момент, когда сервис разработан, он будет самостоятельно публиковать информацию о себе в некоем реестре. И на основании этой информации, все сервисы смогут начать с ним взаимодействовать.

Таким образом и была сформирована концепция «сетки» сервисов — как она исходно называлась, «service mesh». Как некий промежуточный уровень интеграции между сервисами, который предоставляет такое интеграционное, как бы облачное решение.

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

Часто еще возникает вопрос: «Но что же делать с канонической моделью данных, источником которой, как правило, являлась ESB, в которую вложено так много средств и сил, чтобы ее реализовать и поддерживать?». Ведь она была стандартно-используемой моделью. Здесь встречный вопрос: «А какие преимущества она нам приносила? И не была ли она той самой точкой, которая задерживала нашу разработку?». Ведь при разработке сервисов модель расширяется все сильнее. Всегда будут возникать всё более новые задачи.

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

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

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

Многие производители программного обеспечения идут этим путем в части своих решений по интеграции. Уже есть и фреймворки, которые по сути реализуют концепцию service mesh (те же Linkerd или Istio). Так же уже происходит в рамках размещения большого количества сетевых прокси и сервисов интеграции service mesh. Много общего с service mesh и у систем оркестровки контейнеров, например Kubernetes.

Можно ли на основе ESB построить Distributed? То есть, можно ли из одной системы сделать другую? И если да, то в чем смысл этих споров?

Здесь приходит на ум Гегель и его «отрицание отрицания». Когда одна идея повторяет себя на более высоком историческом уровне. Прийти от одному к другому, на мой взгляд, можно. Другой вопрос в том, как мы будем идти к этому. Ведь по сути сама концепция микросервисов и их реализация во многом похожа на ту концепцию интеграции, которая была изначально: взаимодействие микросервисов между собой, каждый с каждым.

Можно ли прийти к интеграции по принципам сетки, если мы идем от ESB? Собственно, Red Hat, ныне IBM, уже идет по тому же принципу. Достаточно посмотреть на их представление о концепции интеграционного стека и гибкой интеграции (Agile Integration). Они предлагают наличие большого количества интеграционных прокси, не перегруженных логикой. Самое главное — это прозрачность и то самое знание о сервисах, которое требуются всем вновь поступающим участникам взаимодействия.

Понимает ли ваш банк, что ESB отжил свое, если продолжает в него инвестировать значительные бюджеты?

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

Где место бизнес-мониторингу в distributed system?

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

Как Вы видите план перехода к децентрализованной интеграции?

Переход к децентрализованной интеграции имеет смысл рассматривать в контексте перехода к новым архитектурным принципам. Это сложный переход, который не может произойти одномоментно. Да, можно пытаться провести его в формате «большого взрыва», но этот сценарий вариант несет в себе серьезные риски. Более логичным видится вариант создания нового контура параллельно с существующим и по мере его создания (в итеративном режиме) заведения в нем новых продуктов. По мере развития нового архитектурного контура туда могут переводиться и те продукты из текущего ИТ-ландшафта, которые выдержали проверку временем. Такой путь достаточно продолжительный – по оценкам до 4-5 лет – но вследствие итеративности можно получать результаты в режиме промышленной эксплуатации последовательно.

Кто же победил?

После трех интерактивных раундов с выступлениями, вопросами и ответами зал затаился в ожидании оглашения итогового результата. Наверное, вы догадываетесь, что победителем «PSB Battle» стал Андрей Трушкин и распределенная система.

В заключение предлагаем ролик, который поможет почувствовать атмосферу нашего баттла:

Автор: Ларионов Владимир

Источник ^[3]