Микросервисы в контексте корпоративной архитектуры

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

К недостаткам микросервисной архитектуры относят:

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

Но не напоминают ли вам все эти тезисы перечисление текущих проблем корпоративного ИТ-ландшафта? Когда вместо внятной картинки из полутора десятков целевых систем мы видим десятки или даже сотни разрозненных приложений. Разные технологии, спонтанно выбранные программные средства, спутанные массивы данных и стихийная интеграция. Обычно, чтоб справиться с таким безобразием компании и берут на работу ИТ-архитектора. Именно этот персонаж должен сформулировать технологическую политику – минимально избыточный набор программных средств, необходимых для решения задач предприятия. Он же должен определить порядок управления данными, закрепить сущности за системами и наладить процессы сбора, обработки и распространения информации. А еще распутать спагетти оппортунистических интеграционных связей, скорее всего умело используя для этого корпоративную сервисную шину.  В общем приблизить картину ИТ ландшафта к левому рисунку.

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

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

Чтоб это отчетливо разглядеть надо перенести фокус внимания с отдельной информационной системы на весь корпоративный ИТ-ландшафт (ну или некоторую его существенную область). Этому не очень способствуют типичные объяснения микросервисной архитектуры в сравнении её с монолитом, но не обманывайтесь. Ведь слева художник нарисовал только малую часть ИТ-ландшафта. В его поле зрения попало всего одно приложение. На самом деле оно синтегрированно с десятком других систем, руками пользователей загружает в себя внешние данные, что-нибудь выкладывает на ftp сервера, не приписанные ни к одной информационной системе, и формирует реплику для системы отчетности (эта база данных нарисована на заднем плане и потому не видна).

Так стоит ли бояться появления микросервисов в корпоративном ИТ-ландшафте?

Реклама

2 thoughts on “Микросервисы в контексте корпоративной архитектуры

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

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s