Вы обратили внимание на то, что количество статей и выступлений, скептически настроенных в отношении микросервисной архитектуры, возросло? Правилом хорошего тона считается, если не ругать микросервисы, то, по крайней мере, отзываться в духе: не всё так просто! Почему так происходит? Рискну дать свой вариант ответа ссылаясь на модель проникновения технологий(adoption curve), опубликованную InfoQ в мае этого года
Но сначала несколько слов о самой модели. Наверное, самое толковое её описание дано в книжке Джеффри Мура «Преодоление пропасти», хотя сама теория Diffusion of innovations появилась раньше и была популяризована американским социологом Эвереттом Роджерсом еще в 1962 году. Однако у Мура есть ряд важных моментов, на которые часто не обращают внимание. И это не только «пропасть» между ранними последователями(энтузиасты) и ранним большинством(прагматики). В не меньшей степени следует понимать, что представители этих групп – очень разные люди. И от той или иной технологии они ожидают довольно разных вещей.
Ранние последователи, как и новаторы, «покупаются» на новые концепции в самом начале жизненного цикла продукта, но, в отличие от новаторов, не разбираются в технологических тонкостях… Раннее большинство частично разделяет с ранними последователями пристрастие к технологии, но в конечном счете ими движет хорошо развитый практицизм.
Вернемся к микросервисам, которые по мнению экспертов InfoQ перехали из второго в третий этап проникновения инноваций. Не знаю, кто именно был приверженцем микросервисов на этапе их зарождения, в момент срабатывания технологических триггеров, но очевидно, что предыдущие несколько лет основными популяризаторами микросервисной архитектуры являлись разработчики. Не очень понимания, для чего именно нужен этот подход и как извлечь из него хоть какие преимущества, адепты микросервисов, тем не менее, нахваливали его при каждом удобном случае.
Сегодня ситуация изменилась. В ходе недавнего мини-курса «Три вебинара о микросервисах» я получил сразу несколько вопросов относительно влияния микросервисного подхода на традиционную корпоративную архитектуру. Не только на системы дистанционного обслуживания, но и на автоматизацию автоматизацию бизнес-процессов, реализуемую посредством BPMS и даже традиционных «коробочных» приложений. Возможно, слушателей задел мой тезис о том, что старой сервисной архитектуре SOA+BPM нет места в новой реальности и разработчики BPM-решений, по крайней мере такие передовые как Camunda, пытаются это осмыслить.
Такое развитие событий довольно логично, как и изменения характера вопросов относительно микросервисов, с вопросов типа «Как?» на вопросы категории «Зачем?». В общем микросервисы, действительно переехали в новую целевую аудиторию. (Обратите внимание, что такие слова, как Kubernetes или CQRS всё еще остаются в зоне энтузиастов)
Чем это грозит разработчикам? Да, в общем, мало чем хорошим. Если на прежних стадиях проникновения технологии можно было с умным видом предлагать микросервисы своим заказчикам, то теперь заказчики перехватывают инициативу. И требовать они будут не микросервисную архитектуру, а масшабируемость, автоматическое восстановление, технологическую независимость и… сокращение сроков внесения изменений, конечно, т.е. свой горячо любимый time2market. Становится решительно непонятно, как использовать старые айтишные отмазки. Вот раньше, когда заказчик просил провести изменение, которое нам почему-то, ну вот совсем не нравится, что мы говорили? Мы говорили, что так делать нельзя, потому что такое изменение порушит текущий функционал. Ну, или что сделать его нам не позволяют ограничения в технологии: мол java у нас не той версии или СУБД слишком реляционная. Сейчас грамотный заказчик резонно заметит: ну, вы не трогайте старый функционал, запилите мне новую фичу в виде отдельного микросервиса, на подходящем технологическом стеке. Системным администраторам не сильно легче. Раньше было как: не хочешь развертывать компонент – не развертываешь. Change advisory board не утвердил, нагрузочное тестирование не выполнено, руководство администратора не согласовано… А сейчас развертыванием занимаются роботы, а безопасность остальных компонентов можно и механизмами типа circuit breaker обеспечить. Одним словом, беда с этими грамотными заказчиками. Зря мы, конечно, там сильно про микросервисы раструбили. Надо бы пойти, какую-нибудь ругательную заметку в блог написать.
С разработчикам понятно. А чем это грозит архитекторам?
Хороший вопрос. Думаю архитекторам пора переключаться на рассказывание историй про CQRS и k8s для ИТ и про партнерские экосистемы для бизнеса. Ну и операционная деятельность меняется на post-agile
Похоже пора провести вебинар по post-agile. И еще вопрос – планируются ли опубликовать материалы проведенного мини-курса на открытом ресурсе? Хочу взглянуть чем BPM+SOA “провинился” перед MSA.
Головой надо думать, а не тупо брать популярную технологию. Я 2 года назад говорил, что на хрен вам не нужны микросервисы, если вы не амазон и не гугл – подождите 2 года и всё сдохнет, будут на конференциях доклады сначала вида “Микросервисы – не всё так просто”, а потом просто “Микросервисы – г*но”. Щас пройдёт ещё пара лет и про кубернетес то же самое будет. “IT-фэшн” блин какой-то.
// Ну и при чём тут CQRS вообще не понятно – просто на картинке всё скинуто в одну кучу
“старой сервисной архитектуре SOA+BPM нет места в новой реальности”, – тоже зацепило.
В вебинарах эта тема раскрывается? или посоветуете где ещё почитать про это?