Микросервисы. Закат хайпа?

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

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

Главный, но не единственный, наиболее часто упоминаемый, но вряд ли самый востребованный потомок микросервиса – это функция из Function as a Service; основной элемент в модели бессерверных вычислений. Если вы хотите держать загруженными в оперативную память и прогретыми тысячи обработчиков самых невероятных расширений вашего бизнес-процесса, расширений, исполняемых пару раз в день или даже в месяц, а еще обладаете соответствующими бюджетами, то это тема не для вас. Если нет, то наверное станете раздумывать как все ваши stateless микросервисы, особенно с быстрой процедурой инициализации (без init container-ов и подгрузкой мегабайт данных с затерявшихся в интернете серверов), переделать в функции FaaS.

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

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

Всё перечисленное выше, конечно же можно засунуть в один процесс. Но вопрос: зачем это делать? Кому-то правда хочется навесить на один сервис обработчик команд и API для чтения данных? Ну, в этом случае, подумайте об использовании СУБД. Её разработчики наверняка это сделали лучше. Более того, репликацию данных на другие экземпляры процесса они скорее всего уже тоже реализовали.

ОК, это была не очень добрая шутка, теперь о более сложных вещах. Распределенные транзакции и разделение по разным базам данных ограниченных контекстов. Многие, наверняка, попробовали. Кто-то успел пожалеть о таком решении. Разделение данных по разным базам – отличная идея. Особенно если мы знаем, что именно и зачем мы выносим в отдельную базу данных. Особенно если эти данные не меняются в ходе исполнения транзакций. Ладно, пусть меняются, но делают это безвозвратно и не подлежат восстановлению при откате транзакции (event sourcing, логи и т.п.). Тема распределенных транзакций еще долго будет оставаться классным поводом для разговора. Потому не будем больше о ней в этой заметке, оставив её для зумов, и сразу перейдем к заключению.

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

Для Telegram-канала https://t.me/it_arch

Один комментарий к “Микросервисы. Закат хайпа?”

  1. “Возможно, в design time такие границы и существуют, но как только приложение запускается на выполнение карета превращается в тыкву граница эта остается исключительно в голове разработчика. ” – Это же давно известно – надо идти от бизнеса, а не от ИТ. Вот посмотри на дискуссию – https://www.facebook.com/groups/archdev/permalink/3215297861866462/?comment_id=3215437705185811

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *