Чистая архитектура и микросервисы

cleanБоюсь, что этот текст выльется в достаточно большое количество букв. Но пишу сюда я тексты нечасто, так что может кто-нибудь его и осилит. Тем более, что использование микросервисов уже достаточно долго сопровождается вопросом: зачем мы это делаем. Несмотря на обилие вариантов ответов (см., например, отличный обзор Nate Schutta (+Matt Stine) Should that be a Microservice? Keep These Six Factors in Mind), вопрос этот задается снова и снова. У меня есть свой вариант ответа. Если говорить просто заключается он в переносе идей Чистой архитектуры Роберта С. Мартина (дядюшки Боба) из мира [монолитных] приложений в пространство распределенных архитектур. Цитата из его книжки Чистая архитектура. Искусство разработки программного обеспечения:

Архитектура программной системы – это форма, которая придается системе её создателями. Эта форма образуется делением системы на компоненты, их организацией и определением способов взаимодействия между ними. Цель формы – упростить разработку, развертывание и сопровождение программной системы, содержащейся в ней. Главная стратегия такого упрощения в том, чтоб как можно дольше иметь как можно больше вариантов.

Можно по-разному относиться к идеям этой книжки. Я даже не стану утверждать, что они всегда и всему подходят. Но небольшую часть из них, прежде чем вернуться к микросервисам, мне придется повторить.
Итак, поехали! Читать далее Чистая архитектура и микросервисы

Уровни зрелости разработчиков интеграционных решений

esbЛет 7-10 тому назад, во времена всеобщего увлечения сервис-ориентированной архитектурой было модно придумывать уровни зрелости SOA сервисов. Open Group придумал Service Integration Maturity Model (OSIMM). IBM отметился свое трактовкой уровней зрелости (см., например Solution design in WebSphere… ), обещающий достигнут пятого из семи возможных уровней зрелости посредством внедрения WebSphere Process Server  (см. рисунок ниже). Ну, а Microsoft c Informatica-ой занимались оценкой уровней зрелости в деле интеграции данных (A Maturity Model for Data Integration) В общем, каждый занимался своим делом. IBM даже порывался сделать у нас консалтинговый проект, но мы сами приписали себе второй или третий уровень зрелости и сразу согласились на пилотный проект с WS Process Server.По результатам пилота мы даже приняли решение внедрить BPEL Engine, правда не от IBM-а, а open source, да и WebSphere Message Broker из эксплуатации вывели (кому нужен инструмент не того уровня зрелости 😉 Читать далее Уровни зрелости разработчиков интеграционных решений

Трансформация ИТ: сервисная архитектура и интеграция

47702335-33ad-c494-7ae5-98bbcc7ac027Десять лет прошло с момента публикации аналитиком компании Gartner Ефимом Натисом (Yefim V. Natis) статьи Applied SOA: Conquering IT Complexity Through Software Architecture. Это статья довольно быстро была переведена на русский язык и вышла в журнале «Открытые системы» под заголовком Покорение сложности ИТ. Примерно в это же время в отечественных компаниях начались разговоры про сервис-ориентированную архитектуру,  интеграционные среды, а чуть позже трансформацию ИТ. За прошедшие десять лет мы узнали множество новых слов: облачные вычисления, социальные сети, мобильные приложения и даже большие данные,  но так и не научились контролировать сложность корпоративных информационных систем. Давайте отойдем немного назад и попробуем разобраться почему Читать далее Трансформация ИТ: сервисная архитектура и интеграция

Архитектура частного облака

PartlyCloudy1На протяжении нескольких лет тема облачных вычислений (cloud computing) была целиком и полностью спекулятивной. Вероятно, причиной тому являлся приоритет бизнес-модели над технологиям. Технологические лидеры, безусловно, рассказывали широкой общественности о том,  что же такое облако; поясняли, что облака бывают публичные, частные и гибридные, но за всеми этими разговорами отчетливо виднелись длинные уши маркетинга и продаж. И желание у персонажей, которых я назвал «технологическими лидерами» было только одно – вместо лицензий и проектов продавать услуги. Причем не так как раньше, не услуги по разработке программного обеспечения, а услуги, оплачиваемые постоянно, в ходе всего жизненного цикла. На сегодняшний день ситуация поменялась. Покупка услуг по подписке стала привычным делом. Мы стали покупать не только услуги ЖКХ или пакеты услуг связи, но и музыку по 169 рублей в месяц в Apple Music. Вероятно, скоро можно будет подписаться  на месячный пакет еды в близлежащем супермаркете. В общем, тема бизнес-модели стала неактуальной. Пришло время поразбираться в технологиях. Читать далее Архитектура частного облака

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

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

Адаптивный кейс-менеджмент и основные данные

Перед отпуском я написал серию сообщений о SOA, ESB, EDA и Master Data Management. Потом я написал о том, как собрать это все вместе. А по возвращении из отпуска позволил себе добавить в эту конструкцию еще и BPM. Но честно говоря, я еще не сказал главного, о чем мне и напомнил доклад Анатолия Левенчука “Между проектами и процессами: адаптивное управление кейсами”. Настоятельно рекомендую его послушать.

Прежде чем перейти к главному, я все же соберу ссылки на все упомянутые выше сообщения:

Читать далее Адаптивный кейс-менеджмент и основные данные

Master Data Management, EDA, ESB, SOA: собираем все вместе

Реализация повторно используемых интерфейсов предполагает, что мы будем хотя бы чуть-чуть абстрагироваться от конкретных задач и требований сегодняшнего дня. Иначе интерфейсы нам придется переделывать постоянно. Повторю пример из комментариев к сообщению Как сделать хороший API? При разработке программного интерфейса к каталогу книг методы

 

getBookAuthor(…) и getBookPublisher(…)

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

getBookProperty(authorID,…)

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

getItemProperty(itemID, propertyID,…)

Преимущества такого подхода достаточно очевидны. Впрочем, в дополнение к преимуществам появляются и определенные сложности. Одна из них состоит в необходимости разработки дополнительных функций для получения списка item-ов и списка их свойств. Причем перечни свойств элементов различных типов может не совпадать. Описание структуры данных принято выносить в мета-данные (meta-data management). Т.е. у нас должен появиться справочник, в который мы будем вносить эти данные и программные интерфейсы для чтения этих справочников из приложений. Вот мы и добрались до управления основными данными (master data management, нормативно-справочная информация) о котором говорили в сообщении Интерес к управлению данными возвращается Это станет особенно актуальным если информацию получать мы будем из нескольких разнородных приложений с различными программными интерфейсами. Кстати именно в этом случае нам понадобится ESB и управляемая событиями архитектура (Even-driven architecture) Может показаться, что я противоречу своим более ранним сообщениям. Однако, если разобраться чуть глубже, то станет понятно почему это не так (см. рисунок)

В каждом из унаследованных приложений свои структуры данных и свои программные интерфейсы (в одном книжки, в другом компакт-диски ). В каждом, в лучшем случае, свои справочники свойств или же тривиальный хардкод, что встречается чаще. Первое что нужно сделать – научить приложения уведомлять MDM-систему обо всех изменениях в справочниках (Event Driven стиль). В крайнем случае, можно наладить ETL процесс, который будет регулярно сканировать базу данных на предмет выявления изменений и отражать их в MDM. Для того чтоб получить перечень свойств книг или перечень свойств компакт-дисков, очевидно, не следует вызывать API унаследованных приложений, а следует обратиться к MDM системе. (Подробнее см. Gregor Hohp Programming Without a Call Stack – Event-driven Architectures) И в завершении картинки у нас появляется сервисная шина предприятия (ESB), которая берет на себя функции преобразования запросов из getItemProperty() в реализованный унаследованным приложением getBookAuthor(), а так же маршрутизации запросов между приложениям. Кроме того, ESB окажется полезным и при чтении MDM, например, для сокрытия задержек обновления данных в MDM, кеширования запросов и т.д. Сам процесс обновления данных в MDM системе можно и даже нужно реализовать в ESB, т.к. это позволит нам реализовать достаточно эффективные стратегии управления данными. Не стану углубляться в подробности, т.к. описание данных стратегий потребует некоторого погружения в описание архитектуры Web. Интересующихся отсылаю к диссертации изобретателя стиля RESTful Роя Филдинга (краткое введение в тему RESTful и Enterprise 2.0)

Event-driven architecture

В 2006 году Gartner закрыл аналитическую группу, которая занималась управляемой событиями архитектурой (Event-driven architecture, EDA). Термин EDA предложил аналитик Gartner Roy W. Schulte тремя годами раньше в работе The Growing Role of Events in Enterprise Applications Обзор работы на русском языке можно посмотреть в статье EDA – архитектура, управляемая событиями До какого-то момента SOA и EDA в сознании аналитиков шли рука о руку (см., например 2.0 The Mission and Future of Integration), но потом управляемая событиями архитектура впала в немилость и была забыта. Может быть, концепция была слишком революционной, а может идея Complex event processing (CEP) отвлекла на себя основной внимание, но из-за задержки внедрения таких технологий как RFID ушла в тень, прихватив с собой и EDA, не важно. Для нас важно другое:

  • во-первых, в отличии от SOA, EDA – это действительно архитектура, т.е. определенный подход к построению информационной системы предприятия;
  • во-вторых, концепция управляемой событиями архитектуры объясняет, почему сегодня интерес к сервисной шине предприятия (ESB) опережает интерес к SOA (см. ссылки в сообщении Forrester: SOA жив и здоров)

Читать далее Event-driven architecture

Forrester: SOA жив и здоров

Примерно таким заголовком анонсировали интернет издания мартовское исследование Forrester SOA Adoption 2010: Still Important, Still Strong Оказывается 71% опрошенных компаний уже используют SOA или собираются это сделать в течении 2011 года. То же самое говорит почти половина средних и малых компаний. Организации довольны результатами, получаемыми от сервис-ориентированной архитектуры и не собираются от неё отказываться. Безусловно, определенная часть опрошенных просто не понимает о чем говорит, но единодушие в ответах респондентов показывает, что «пациент скорее жив, чем мертв».

Не менее интересное исследование появилось в конце апреля The Forrester Wave™: Enterprise Service Bus, Q2 2011. Рынок ESB продолжает неплохо расти. Кроме вполне привычных для ESB задач, таких как маршрутизация сообщений и преобразование данных 35% компаний используют ESB непосредственно для разработки сервисов, а 14% для прикладной разработки на BPEL (28% используют BPEL для оркестровки). Кстати, с языком исполнения бизнес-процессов WS_BPEL ситуация тоже интересная. 2-3 года назад только ленивый не говорил о том, что SOA и BPM – браться на век. Затем из лагеря BPM стали отчетливо слышаться голоса, что BPEL not for people. В ответ могу попрекнуть разработчиков BPMS в монолитности архитектуры их флагманских продуктов. Далеко не все BPMSы, те который для людей, а не так называемый IC-BPMS, отвечают принципам сервис-ориентированной архитектуры, потому как сервисов они не предоставляют. В итоге, у больших вендоров в линейке присутствуют как минимум по два продукта: один для быстрого рисования процессов и пользовательских интерфейсов к ним, а другой для интеграции в корпоративную информационную систему, т.е. интероперабельный. Читать далее Forrester: SOA жив и здоров

Услуга интеграции приложений для оператора связи

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

Потребности оператора связи в интеграции приложений можно условно разбить на следующие группы: Читать далее Услуга интеграции приложений для оператора связи