Чистая архитектура и микросервисы

Боюсь, что этот текст выльется в достаточно большое количество букв. Но пишу сюда я тексты нечасто, так что может кто-нибудь его и осилит. Тем более, что использование микросервисов уже достаточно долго сопровождается вопросом: зачем мы это делаем. Несмотря на обилие вариантов ответов (например, отличный обзор Nate Schutta (+Matt Stine) Should that be a Microservice? Keep These Six Factors in Mind), вопрос этот задается снова и снова.

«Во многих отношениях микросервисы — это зомби-архитектура. Еще один штамм интеллектуальной заразы, которая просто отказывается умирать. теперь в виде микросервисов и бессерверных технологий» (Дэвид Хайнемайер Ханссон).

После недавнего сообщения в блоге AWS о том, что они отказались от микросервисов и вернулись к монолиту, старая война монолита против микросервисов возобновилась.

Какова ваша позиция по этому поводу? Вы — команда микросервисов или команда-монолит? Что, если бы я сказал вам, что это различие было своего рода фантазией и что люди спорят из-за фикции: микросервисы против монолита — это лишь одна часть более широкой истории.

Статья из AWS была воспринята как свидетельство того, что компания (как давний сторонник микросервисов) отказалась от микросервисов и вернулась к монолиту.

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

Но я хотел бы подчеркнуть, что это не имеет особого значения. Это всего лишь одна команда AWS, признающая, что их первая попытка создать архитектуру не увенчалась успехом (со временем), поэтому они попробовали другую архитектуру, и она сработала лучше. Но что с того? Судя по тому, что я видел за свою карьеру, это обычный способ хорошей разработки программного обеспечения.

Мы все хотим сосредоточиться на самом важном; делаем правильные вещи для наших клиентов. Принятие чьей-либо стороны в дебатах о микросервисах и монолите мешает этому. Иногда нам нужны микросервисы. Иногда нам нужен монолит. (Я еще не уверен, что мне когда-нибудь понадобится FaaS, но я сохраняю непредвзятость). Большую часть времени нам лучше находиться где-то между этими крайностями.

У меня есть свой вариант ответа.

Если говорить просто, идея заключается в переносе идей "Чистой архитектуры" Роберта С. Мартина (дядюшки Боба) из мира монолитных приложений в пространство распределенных архитектур.

Наверное, самое толковое описание применяемой в InfoQ модели дано в книге Джеффри Мура «Преодоление пропасти», хотя сама теория Diffusion of innovations появилась раньше и была популяризована американским социологом Эвереттом Роджерсом еще в 1962 году. Однако у Мура есть ряд важных моментов, на которые часто не обращают внимание. И это не только «пропасть» между ранними последователями (энтузиасты) и ранним большинством (прагматики). В не меньшей степени следует понимать, что представители этих групп – очень разные люди. И от той или иной технологии они ожидают довольно разных вещей.

Ранние последователи, как и новаторы, «покупаются» на новые концепции в самом начале жизненного цикла продукта, но, в отличие от новаторов, не разбираются в технологических тонкостях… Раннее большинство частично разделяет с ранними последователями пристрастие к технологии, но в конечном счете ими движет хорошо развитый практицизм.

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

Сегодня ситуация изменилась. За последнее время я получил сразу несколько вопросов относительно влияния микросервисного подхода на традиционную корпоративную архитектуру. Не только на системы дистанционного обслуживания, но и на автоматизацию бизнес-процессов, реализуемую посредством BPMS и даже традиционных «коробочных» приложений.  Возможно, задел мой тезис о том, что старой сервисной архитектуре SOA+BPM нет места в новой реальности и разработчики BPM-решений, по крайней мере такие передовые как Camunda, пытаются это осмыслить.

Такое развитие событий довольно логично, как и изменения характера вопросов относительно микросервисов, с вопросов типа «Как?» на вопросы категории «Зачем?». В общем микросервисы, действительно переехали в новую целевую аудиторию.

Чем это грозит разработчикам? Да, в общем, мало чем хорошим. Если на прежних стадиях проникновения технологии можно было с умным видом предлагать микросервисы своим заказчикам, то теперь заказчики перехватывают инициативу. И требовать они будут не микросервисную архитектуру, а масшабируемость, автоматическое восстановление, технологическую независимость и… сокращение сроков внесения изменений, конечно, то есть свой горячо любимый time2market.  Становится решительно непонятно, как использовать старые айтишные отмазки. Вот раньше, когда заказчик просил провести изменение, которое нам почему-то, ну вот совсем не нравится, что мы говорили? Мы говорили, что так делать нельзя, потому что такое изменение порушит текущий функционал. Ну, или что сделать его нам не позволяют ограничения в технологии: мол java у нас не той версии или СУБД слишком реляционная. Сейчас грамотный заказчик резонно заметит: ну, вы не трогайте старый функционал, запилите мне новую фичу в виде отдельного микросервиса, на подходящем технологическом стеке. Системным администраторам не сильно легче. Раньше было как: не хочешь развертывать компонент – не развертываешь. Change advisory board не утвердил, нагрузочное тестирование не выполнено, руководство администратора не согласовано… А сейчас развертыванием занимаются роботы, а безопасность (не информационную) остальных компонентов можно и механизмами типа circuit breaker обеспечить. Одним словом, беда с этими грамотными заказчиками. Зря мы, конечно, там сильно про микросервисы раструбили. Надо бы пойти, какую-нибудь ругательную заметку написать.

На этом всё. Мы перенесли архитектурные практики монолитных систем на распределенные. Расширили спектр ответов на вопрос зачем из первой ссылки этого текста некоторым архитектурным соображением: чтоб как можно дольше иметь как можно больше вариантов. Уверен, что для ряда читателей эти рассуждения покажутся банальными; а для кого-то — полезными.