Зачем организациям Enterprise Service Bus

050833689Я много раз рассказывал о том, что сервисную шину в компании мы использовали не по назначению. Мы не разрабатывали сервисы для того, чтоб предоставлять их внешним приложениям для доступа к данным и операциям других систем, как это описывается в сценариях интеграции приложений. И пусть простят меня команды, которым пришлось использовать эти сервисы: разработчики мобильных приложений, сервисных платформ и т.д. Эти решения делались не для вас. Сервисную шину мы использовали для того, чтоб разрабатывать сервисы для наших клиентов в строгом соответствием с гартнеровским pace layer подходом.

То, что SOAP web-сервисы не очень подходя для построения высоконагруженных приложений было понятно еще 2007 году (см. мою презентацию Event-driven SOA). Не смотря на то, что на headhunter до сих пор полно вакансий архитектора ESB со знанием XML, RPC-style сервис-ориентированной архитектуры продолжают использовать только госструктуры и некоторые финансовые организации не очень хорошо разбирающиеся в ИТ. Большинство же нормальных айтишников говорят сейчас совсем другие слова: модель акторов, CQRS и event sourcing, Apache Storm и лямбда архитектура. Все эти штуки выросли из так называемой управляемой событиями архитектуры. Если вы не знаете что это такое, то вам стоит посмотреть тексты и презентации на странице Staged Event-Driven architecture (SEDA). В двух словах: речь идет о том, чтоб строить вашу вычислительную систему как набор независимых компонент, обменивающихся друг с другом сообщениями через очереди. Так называемая слабая связность (loose coupling). В частности, это позволяет распределять такие компоненты по серверам, создавая масштабируемые отказоустойчивые решения. (Кстати, разработчики традиционных ESB, BPM, CRM и прочих ERP решений этого до сих пор не делают. Так что приобретая очередное «коробочное решение» вы непременно покупаете проблемы с масштабированием и внесением изменений).

Но наша главная цель была не в масштабировании и отказоустойчивости, а в быстром запуске новых сервисов для клиентов компании. Основная проблема, связанная с ИТ в современных организациях в невозможности быстрой разработки новых качественных услуг для клиентов и партнеров. Сервис-ориентированная архитектура, по сути своей, это диагноз ИТ-отделам организаций. Попытка найти ответ на вопрос, почему ИТ-решения делаются медленно и  дорого, а результат не удобен для клиента. Согласно SOA причина в этих самых унаследованных (legacy) приложениях, под завязку набитых ненужным функционалом и несущих на себе огромный технический долг. Однако, если вы умеете перехватывать события, происходящие в таких приложениях, то новый функционал можно разрабатывать снаружи, не затрагивая устаревшие системы. Сервисная шина – главный претендент на создание платформы для разработки таких решений.   Несколько примеров событий: регистрация клиента, подключение/отключение услуг, изменение состояния клиента, поступление платежа или исчерпание средств, действия клиента в системе самообслуживания, обращение в контакт-центр, запрос с мобильного телефона. Был даже пример, когда мы перехватывали выход клиента в сеть передачи данных с неправильными настройками. Поверх этих событий разработано огромное количество сценариев: уведомления, начисления бонусов, управление параметрами сервиса и т.д. Если вы умеете перехватывать события и быстро реализовывать новые сценарии их обработки, то логика предоставления услуг ограничивается только вашей фантазией. Вы можете автоматизировать ручные операции, заменив сотрудников маленькими программными роботами. Пришел человек на работу, включил компьютер, а стая программных роботов за него все уже сделала. Сотруднику остается только спуститься в HR отдел, чтоб трудовую книжку забрать. Вы можете использовать в сценариях результаты аналитики больших данных или делать такую аналитику в реальном времени. Главное, что для всего этого не надо дорабатывать унаследованные приложения.

Я с большим уважением отношусь к гибким методологиям разработки, но решение проблемы time2market посредством архитектуры – более радикально. Не натягивайте agile на уже существующие разработки. Если по тем или иным причинам развивающая систему команда вас уже не устраивает, то лучше не станет. Просто заставьте ребят сократить количество изменений, автоматизировать тестирование и накройте систему современным мониторингом.  (Я не про тот мониторинг, что был у нас. Сейчас, вслед за оффлайновыми решениями Big Data,  появляются системы большой аналитики в реальном времени. Цель таких решений – обнаруживать ошибки разработчиков и администраторов не через неделю, когда компания уже потеряла большой мешок денег, в немного раньше).

Одним словом, я надеюсь, что сумел донести идею о том, что ESB – это способ обеспечить себе свободу принятия решений. Что вы будете делать, когда в очередной раз прибежит ваш заказчик и скажет что через месяц надо запустить новый продукт или услугу? Пойдете дорабатывать существующие приложения, команда разработки которых завалена ворохом предыдущих задач и многолетним техническим долгом, устроите тендер по покупке новой системы или воспользуетесь предложенным выше подходом и разработает пару новых слабосвязанных компонент – решать вам. А я устрою маленький опрос:

[polldaddy poll=8370362]

Зачем организациям Enterprise Service Bus: 5 комментариев

  1. Насколько я понимаю, дополнительные варианты ответов на опрос не отображаются. Поэтому, я буду дублировать их здесь и постараюсь прокомментировать. Итак:

    ESB, event dispatcher, BPM, BRM and others should be architected together

    В принципе, да. Я о том и пишу, что не надо переписывать все с нуля. Существующие решения можно переиспользовать. Правда они должны иметь нормальные API, уметь отправлять events и не становиться критическим звеном по масштабированию, отказоустойчивости и времени внесения изменений.

    ESB лишь поможет перехватить сообщение без серьёзного вмешательства, А дальше ?

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

  2. Статься интересная, много полемических в части области применения как технических, так организационных моментов.

    1.”SOAP web-сервисы не очень подходя для построения высоконагруженных приложений было понятно еще 2007 году (см. мою презентацию Event-driven SOA)

    SOAP не противоречит Event-driven подходу. Первое – формат, второе – паттерн коммуникации. Пример возможного синтеза – SOAP over JMS(http://www.w3.org/TR/soapjms/).
    Примеры реализации – в Apche CXF(http://cxf.apache.org/docs/soap-over-jms-10-support.html), в Axis2 (https://axis.apache.org/axis2/java/transports/jms.html), в оракловых решениях(http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/b25603/transportjms.htm)

    То, что XML не самый быстрый/экономный по объему и скорости валидации формат – с этим согласен. Со стандартизацией, совместимостью технологической реализации основанных на XML протоколов,
    инструментальной поддержкой у XML и основанных на нем форматов(WSDL,SOAP, XSD) все хорошо по сравнению с стальными.

    В качестве примеров области применения приведу две крайности- я бы категорически возражал(и на практике это делал) против применения XML как формата при создании мобильного приложения
    и столь же категорически настаивал(также из практики) на применении SOAP при сервисном взаимодействии системы бухучета и WMS-системы.

    2. Если вызов метода в сервисе описан в WSDL one-way, то возврат в вызывающий код происходит по факту передачи сообщения в брокер, независимо от факта получения его получателем, то есть собственно мы получаем ту самую асинхронность в отправке вызовов/сообщений.
    WSDL/SOAP/XML не являются ограничителями в организации EDA, за исключением

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

    Фактически первые два абзаца статьи описывают второй вариант организационной ситуации. 2 вариант работает с точностью до нюансов в компаниях, где разработка не является профильной деятельностью, так и в проектно-ориентированных компаниях разработчиках, где внятно финансируется и обеспечивается ресурсами только деятельность, порождающая конечный функционал, требуемый бизнесом. Наблюдаю/наблюдал эту ситуацию как в одном из крупнейших в стране ритейловых холдингах, так и одном и операторов большой тройки(не Билайн ;)),так и в компании-разработчике-интеграторе-спутнике этого оператора.
    Пока ниша для вашего подхода, как я понимаю, находится в новых, незабюрократизированных быстроразвивающихся компаниях, где передовые технологии + услвоия их применения являются ключевым конкурентным преимуществом.

    4. Что нового приносит EDА и есть ли принципиальные отличия от SOA – большой вопрос.
    пп 1,2 описывают пример непротиворечащего подходу EDA варианта реализации сервисного взаимодействия на базе существующих технологий, предназначенных для построения SOA решений.
    Называть что-то отправкой сообщения и one-way call – на мой взгляд дело вкуса.

    5. В качестве иллюстрации критики подхода EDA как SOA 2.0 могу привести пример 2 презентаций, которые иллюстрируют наше обсуждение:

    Продвижение EDA
    http://www.slideshare.net/jeppec/what-soa-eda-and-cqrs-version
    Критика этой презентации
    http://www.slideshare.net/jdubray/soa-vs-eda

    Вторая презентация написанная Jean-Jacques Dubray, одним из двух авторов по практической реализации SOA, которых я считаю достойными прочтения.
    Интересны с этой точки зрения его статьи на InfoQ.

    6. Создается впечатление, что последние два абзаца подводят к микросервисной архитектуре (http://martinfowler.com/articles/microservices.html), здесь есть 2 подводных камня:
    организационный – в общих чертах выше
    технический – сейчас управляемость микросервисной архитектуры в плане управления ресурсами (CPU, memory) еще не получила, насколько мне известно, от runtime платформ (Java, .NET). В Java для разработки и развертывания вполне пригодны например OSGI и его расширения + контейнеры – Apachr Felix и решения поверх него – Apache Karaf и надстройки над ним, Eclipse Equinox, для мониторинга и распределения ресурсов пока Oracle в JRE еще не разродился.

    1. Игорь, спасибо за развернутый и интересный комментарий. Надеюсь, он будет интересен и читателям блога. Несколько ответов по пунктам:

      1. …SOAP не противоречит Event-driven подходу…
      2. Если вызов метода в сервисе описан в WSDL one-way, то возврат в вызывающий код происходит по факту передачи сообщения в брокер, независимо от факта получения его получателем,

      Конечно, не противоречит. SOAP достаточно универсален и позволяет реализовать различные паттерны взаимодействия. Я не хочу здесь углубляться в тему о том, что SOAP игнорирует методы HTTP, а семейство стандартов WS-* создает излишнюю сложность. Принципиально на SOAP можно сделать асинхронные взаимодействия. Их можно сделать даже на базе данных. Создать интерфейсную табличку, в которую один процесс будет добавлять записи, а другой – читать и перекладывать в следующую табличку. А телекомовское оборудование до сих пор по событиям выкладывает файлы CDR, которые другие системы собирают и обрабатывают. Вопрос, скорее в том, для чего тот или иной инструмент был придуман и несут ли нам какую-либо ценность дополнительные издержки.

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

      Как раз наоборот. Такие компании сами разберутся, проблема IT complexity у них еще не столь актуальна. Я рассказываю большим компаниям о том, что им не обязательно заново перекапывать весь свой ИТ-ландшафт (они с этим не справятся по техническим и финансовым ограничениям). Что сделано, то сделано. Теперь надо отгородить все это забором ESB и развиваться с чистой его стороны. Это альтернативный подход замене/переписыванию КИС.

      4. Что нового приносит EDА и есть ли принципиальные отличия от SOA — большой вопрос.

      Наверное, это вопрос к Gartner. У них много статей о том, что SOA включает в себя 3 стиля: RPC-style (old), EDA и web/resource oriented architecture

      5. В качестве иллюстрации критики подхода EDA как SOA 2.0 могу привести пример 2 презентаций, которые иллюстрируют наше обсуждение:

      Спасибо! Интересно

      6. Создается впечатление, что последние два абзаца подводят к микросервисной архитектуре

      В принципе, да. Но средства по развертыванию и управлению микросервисами опаздывают. По факту за потоком событий выстраиваются обработчики, написанные разными людьми на различных технологиях и используемые в разных организациях. Своего рода «партнерские экосистемы».

  3. Considering that ESB is actually a communication middleware it sounds like you recommend to equip all people with mobile phones to improve the enterprise functioning. Usually, to achieve the same goal, companies try to prepare better plans and instrument/organise the work to be done. Maybe there are some unstated conditions in which your approach is attractive?

    Thanks,
    AS

Добавить комментарий

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