Преобразование форматов данных, что обеспечивало возможность каждой интегрируемой системы функционировать в рамках собственной модели данных, при этом список потенциальных контрагентов мог расширяться за счет решения задачи дополнительных преобразований на уровне ESB.
Мониторинг интеграционных взаимодействий, которые должны были осуществляться строго посредством решения, реализующего шаблон ESB.
Таким образом, решение, реализующее шаблон ESB, оказывалось сквозным в масштабах организации, что привело к дополнению его функционала задачами информационной безопасности, аудита, трассировки и т. д. Кроме того, для реализации непосредственных задач решение реализовывало ряд шаблонов проектирования, представленных как в вышеупомянутом труде («Enterprise Integration Patterns»), так и в одной из основополагающих работ в сфере ИТ: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides «Design Patterns: Elements of Reusable Object-Oriented Software» (1994, ISBN 0-201-63361-2). К числу подобных шаблонов можно отнести каноническую модель данных, адаптер и т. д.
Как уже отмечалось выше, переход к SOA стал революционным в плане развития архитектуры и внедрения ИТ в организациях. В результате разгрузки учетных платформ от несвойственного им функционала передовые в технологическом плане финансовые организации смогли приступить к активной автоматизации своих производственных и бизнес-процессов. Практики SOA стали основными, при этом к началу 2010-х годов ведущие финансовые организации в целом завершили перевод собственной автоматизации в данном ключе. Сформированный ИТ-ландшафт был, безусловно, намного сложнее, чем представленный на Рисунке 7 пример в крупных финансовых организациях он включал в свой состав сотни и тысячи информационных систем. Можно отметить, что к этому периоду SOA из революционной практики стала эволюционной с ярко выраженной тенденцией к застою и деградации. В чем же выражалась соответствующая тенденция?
Представим себе ситуацию, что в финансовой организации 200 информационных систем, которые выстроены и взаимодействуют между собой в соответствии с принципами SOA. При этом каждая информационная система предоставляет 10 сервисов, посредством которых ее функционал доступен контрагентам. Как результат, на интеграционной шине представлено 2000 сервисов. Каждая из систем развивается независимо в соответствии с планами владельцев систем (предположим, что владельцами систем в организации являются бизнес-подразделения). Соответственно, команда специалистов, отвечающая за развитие ESB решения, должна поддерживать актуальность всех 2000 сервисов, добавлять новые, обеспечивать корректность функционирования всего комплекса. Не будем забывать, что нередким является случай, при котором потребителями одного сервиса являются несколько информационных систем. В таком случае при развитии соответствующего сервиса необходимо также поддерживать механизмы версионности, а также обеспечивать регрессионное тестирование. Емкость любой команды не является бесконечной величиной. Кроме того, важным является тот факт, что ESB не представляет собой конечной значимой бизнес-функциональности, то есть участие членов команды развития ESB решения в создании бизнес-ценности является опосредованным, что ограничивает возможности масштабирования соответствующей команды. Результатом, как правило, являлось то, что скорость внесения изменений на уровне ESB была существенно ниже, нежели в информационных системах, автоматизирующих прикладной функционал. Особенно заметной разница в скорости внесения изменений была при сравнении ESB с системами дистанционного банковского обслуживания (ДБО), где соответствующая скорость традиционно одна из самых высоких в автоматизации финансового сектора. Автор лично был свидетелем того, как уже выполненные доработки уровня ДБО ожидали необходимых интеграционных доработок год и более.
Шаблон ESB и следование ему было не единственной причиной потенциальной деградации. Заказчики и партнеры любой организации (финансовая не является исключением) заинтересованы в продуктах, которые она предоставляет. В случае финансовой организации это могут быть вклады, счета, кредиты, банковские гарантии и т. д. В случае следования методикам SOA предоставление продукта клиентам и партнерам предполагало реализацию соответствующего функционала в рамках нескольких информационных систем: канального представления, исполнения процессов, связанных с соответствующим продуктом, принятия решений в части исполняющихся процессов, постановки продукта на бухгалтерский учет и т. д. При этом нельзя забывать, что отдельные системы пусть и предоставляли свой функционал в виде набора сервисов, доступность которых контрагентам обеспечивало ESB решение, сами по себе оставались монолитными комплексами с длительными релизными циклами. Многие из этих систем требовали специфических компетенций для развития. При этом компетенции требовались не только технического, но и методологического характера. В результате выпуск продукта зависел от системы с максимально длительным релизным циклом. На фоне успехов стартапов, ряд которых к началу 2010-х годов уже стали технологическими гигантами, сложившаяся ситуация не могла устраивать представителей традиционных секторов экономики (пример, приведенный в настоящей книге для финансовой организации, является характерным для традиционных секторов экономики в целом). Тенденции, сформировавшиеся после экономического кризиса 2008-го года, также требовали повышения эффективности всех отраслей человеческой деятельности. Возникла необходимость в новом революционном переходе.
Первым этапом нового революционного перехода стала концепция микросервисной архитектуры, в соответствии с которой приложения представлялись в виде набора минимально зависимых (в идеальной ситуации независимых) модулей (микросервисов), каждый из которых представлял собой полноценную единицу развертывания с самостоятельным жизненным циклом. При этом взаимодействие микросервисов предполагалось осуществлять исключительно посредством API, что исключало необходимость владения информацией об особенностях исполнения контрагентов. Данная концепция соответствовала практикам гибкой разработки и DevOps. Пример предлагавшейся концепции представлен на Рисунке 8.
Рисунок 8. Пример концепции микросервисной архитектуры
Показанные на Рисунке 8 микросервисы и межсервисные взаимодействия представлены в качестве примера.
При проектировании решений на основе микросервисной архитектуры учитывались следующие характеристики и качества микросервисов:
Трудоемкость. Разработку микросервиса должна вести одна команда, сформированная в соответствии с гибкими практиками разработки.
Независимость. Локальные задачи решаются средствами микросервиса. Команда, реализующая микросервис, не должна ожидать исполнения подзадач (в составе данного микросервиса) другой командой. Возникновение ситуаций ожидания являлось признаком ошибок проектирования.
Бизнес-ориентированность. Микросервисы должны решать конкретные прикладные задачи заказчиков.
Простота интеграции. Для реализации взаимодействия микросервисов не требуется использования отдельных программных компонентов (по примеру рассмотренного выше ESB решения).
Учет возможных ошибок. Принимая во внимание возможность возникновения ошибок при выполнении жизненного цикла информационной системы, при проектировании последней в парадигме микросервисной архитектуры следует учитывать потенциальную недоступность каждого микросервиса. При этом система должна реагировать таким образом, чтобы минимизировать вероятность общесистемного сбоя.
Децентрализация данных. Отдельные микросервисы работают с независимыми источниками данных в рамках собственных моделей данных. Модели данных разных микросервисов развиваются независимо друг от друга.
На первый взгляд переход к практикам микросервисной архитектуры вносил существенные упрощения в разработку информационных систем, а также повышал наглядность их проектирования, принося следующие результаты:
Возможность гибкого выбора технологий. При независимом исполнении и развитии микросервисов, их автономности от особенностей реализации контрагентов, каждый микросервис может разрабатываться с использованием собственных технологий, выбор которых диктуется потребностями заказчика, наличием в компании соответствующих компетенций и т. д. Необходимо поддерживать лишь исключительно API-совместимость с контрагентами.
Независимость данных. Наличие собственных источников данных, а также использование собственных моделей данных исключает необходимость затрачивать существенные финансовые, временные и трудовые ресурсы на поддержание тяжеловесных шаблонов, таких, как каноническая модель данных.
Отказоустойчивость. При проектировании системы с учетом минимизации влияния каждого микросервиса на стабильность работы системы в целом, показатели отказоустойчивости последней возрастают.
Упрощение замены блоков функционала. В случае, когда бизнес-функции реализуются минимально зависимыми компонентами микросервисами их замена оказывает минимальное влияние на другие компоненты системы.
Удобство и дешевизна масштабирования. При увеличении нагрузки на систему отсутствует необходимость в масштабировании всего программного комплекса (в отличие от эпох монолитных приложений и SOA), а возможно масштабировать только те микросервисы, на которые оказывается дополнительная нагрузка, что снижает технологические и финансовые риски.
Соответствие создаваемой архитектуры организационной структуре предприятия. Возможным становится создание микросервисов, реализующих автоматизацию функционала, напрямую соответствующего должностным обязанностям подразделений предприятия. Таким образом уже на уровне концепции для микросервисной архитектуры реализуется закон Конвея.