Микросервисная архитектура
О микросервисной архитектуре не говорит сейчас только ленивый, но если вы впервые встречаетесь с этим термином, то прочитайте статью Мартина Фаулера или ее перевод на русский.
Я считаю, что микросервисная архитектура — это прямое следствие применения обратного закона Конвея к разработке огромных приложений. То есть чисто технически монолитное приложение будет проще в разработке и обслуживании, чем микросервисное с таким же функционалом. Но только до какого-то размера. В жизни любого монолита наступает такой этап, когда язык, на котором он написан, приходит к концу жизни (End Of Life), библиотеки и фреймворки, которые используются, перестают поддерживаться, а обновиться на новые версии языков, библиотек и фрейморков не представляется возможным. Плюс, в какой-то момент поправить какой-то кусок монолита так, чтобы не задеть какую-то другую часть, становится крайне затратным и сложным. Микросервисный подход, хоть и добавляет дополнительную сложность, помогает сохранять скорость развития продукта, даже когда тот становится необъятных размеров.
Микросервисный подход предъявляет много новых требований к организациям, которые хотят его использовать. Необходимо создать инфраструктуру, которая позволяет «по нажатию кнопки» создавать новые микросервисы. И это должны быть не просто облака в смысле IaaS, это должен быть полноценный PaaS для микросервисов. В идеальном случае, любой сотрудник должен где-то указать адрес репозитория с исходным кодом, а PaaS автоматически подключет новый микросервис к CI/CD системе, по запросу создает и удаляет тестовые окружения. Необходимо научить команды разработки пользоваться новым подходом, ведь тут и асинхронные запросы, и отсутствие большой развесистой БД — транзакционного источника правды, вместо которой теперь куча различных специализированных БД. Тут же появляется система Service Discovery, и ее использование тоже надо интегрировать во все новые приложения.
Но самая сложная часть, как мне кажется, создать гибкую оргструктуру, когда каждый сотрудник может встать с рабочего места в любой момент и сказать, что он уходит работать в другую команду над другим продуктом. Причем, это должно восприниматься, как что-то само собою разумеещеся, на него не должны после этого косо смотреть. Для этого надо уйти от классического интерпрайзного разделения на функциональные отделы. И хорошего ответа, как это сделать, не останавливая уже существующее производство, не знает никто. Но именно эта часть микросервисной трансформации самая сложная, потому что люди, как оказалось, самый твердый материал (даже тверже hardware).
На конференциях меня часто спрашивают, в чем разница между SOA и микросервисами. Я честно отвечаю, что технически разница не такая уж и большая, если она, вообще, есть. Но вот продуктовый подход к разработке, формирование оргструктуры под приложение, full stack команды, непрерывная поставка ПО — все это подразумевается, когда мы говорим про микросервисную архитектуру. При расцвете SOA, если даже и были такие слова, их никто не ставил рядом. То есть микросервисный подход — это больше о том, как команды совместно работают над созданием больших и сложных приложений, чем о технологиях.