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

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

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

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

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

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

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

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

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