Я много раз рассказывал о том, что сервисную шину в компании мы использовали не по назначению. Мы не разрабатывали сервисы для того, чтоб предоставлять их внешним приложениям для доступа к данным и операциям других систем, как это описывается в сценариях интеграции приложений. И пусть простят меня команды, которым пришлось использовать эти сервисы: разработчики мобильных приложений, сервисных платформ и т.д. Эти решения делались не для вас. Сервисную шину мы использовали для того, чтоб разрабатывать сервисы для наших клиентов в строгом соответствием с гартнеровским 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]