Микросервисы в контексте корпоративной архитектуры
Обычно, чтоб убедить кого-нибудь в том, что микросервисная архитектура — это хорошо, её сравнивают с монолитом. Даже картинку специальную рисуют: с левой стороны база данных, сервер приложений и пользовательский интерфейс – это монолит(подразумеваем, что монолит — это плохо), а с правой стороны паутина фигурок и стрелочек между ними (типа, вот это хорошо). Не знают, убедит ли такая картинка случайного собеседника, но архитектор, будучи до конца честен сам с собой, должен сказать, что хорошо – это то что слева. И есть достаточное количество экспертов, которые критически восприняли идеи микросервисной архитектуры и постарались обратить наше внимание не только на достоинства, но и на недостатки такого подхода.
К недостаткам микросервисной архитектуры относят:
Размывание технологической экспертизы, вызванное использованием большого разнообразия программных средств и отсутствием единого управления при выборе технологий
Сложность графа интеграционных взаимодействий. Незрелость современных подходов к обнаружению сервисов и организации обмена командами и данными
Децентрализованное управление данными. Высокую вариативность в представлении данных, выборе структур хранения и механизмов обработки
Несогласованность жизненных циклов отдельных компонент системы. Проблемы версионности, взаимного влияния изменений
Дублирование всего чего только можно: функционала, данных, правил и алгоритмов обработки. В общем, злостное нарушение концептуальной целостности, в любом её понимании.
Но не напоминают ли вам все эти тезисы перечисление текущих проблем корпоративного ИТ-ландшафта? Когда вместо внятной картинки из полутора десятков целевых систем мы видим десятки или даже сотни разрозненных приложений. Разные технологии, спонтанно выбранные программные средства, спутанные массивы данных и стихийная интеграция. Обычно, чтоб справиться с таким безобразием компании и берут на работу ИТ-архитектора. Именно этот персонаж должен сформулировать технологическую политику – минимально избыточный набор программных средств, необходимых для решения задач предприятия. Он же должен определить порядок управления данными, закрепить сущности за системами и наладить процессы сбора, обработки и распространения информации. А еще распутать спагетти оппортунистических интеграционных связей, скорее всего умело используя для этого корпоративную сервисную шину. В общем приблизить картину ИТ ландшафта к левому рисунку.
Оставим за границами этой заметки обсуждение принципиальной реализуемости такой трансформации. Статистику компаний, не только нарисовавших целевую архитектуру, но и сумевших приблизиться к ней никто не считал. Я хочу обратить ваше внимание на другой аспект:
Нагрузку, связанную с потенциальными трудностями управления микросервисной архитектурой, организации уже несут. А вот выгод от применения микросервисов еще не получают
Чтоб это отчетливо разглядеть надо перенести фокус внимания с отдельной информационной системы на весь корпоративный ИТ-ландшафт (ну или некоторую его существенную область). Этому не очень способствуют типичные объяснения микросервисной архитектуры в сравнении её с монолитом, но не обманывайтесь. Ведь слева художник нарисовал только малую часть ИТ-ландшафта. В его поле зрения попало всего одно приложение. На самом деле оно синтегрированно с десятком других систем, руками пользователей загружает в себя внешние данные, что-нибудь выкладывает на ftp сервера, не приписанные ни к одной информационной системе, и формирует реплику для системы отчетности (эта база данных нарисована на заднем плане и потому не видна).
Так стоит ли бояться появления микросервисов в корпоративном ИТ-ландшафте?