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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Перенос конфигурации АТС в сервис 3CX PBX Express

В этой статье мы расскажем, как в сервисе 3CX PBX Express восстанавливать резервные копии существующих инсталляций АТС. Возможность восстановления конфигурации позволяет, например, переместить локальный сервер в облако, сменить хостинг или восстановить АТС в облаке после серьезного локального сбоя. Единственное требование ...

Первые штрафы по GDPR: кого уже наказали

GDRP вступил в силу больше шести месяцев назад, но первые «письма счастья» регуляторы начали выписывать лишь недавно. В материале — о тех компаниях, которые их уже получили. / фото Kiefer CC BY-SA «Мягкий запуск» GDPR GDPR вступил в силу 25 ...