Видео: skillsmatter.com/skillscasts/5235-keynote-an-integrated-services-approach
Длинна: 1 час, сайт требует регистрации (email) перед показом видео. На сайте много интересных видеоматериаллов.
Udi Dahan — автор NServiceBus и очень талантливый оратор и учитель. Я слежу за его выступлениями уже несколько лет — Udi всегда есть что сказать и слушать это познавательно и интересно.
Презентации открывала 2й день конференции посвященной микросервисам, Udi весело и аргументированно осмеял популярную нынче тему микросервисов и предложил отслеживать логическую и физическую реализацию, еще раз подумать “зачем нам этот цирк” и провести паралелли между орг структорой, сервисами и многофункциональными командами. Мне лично было очень интересны моменты не “как писать/разворачивать микросервис?” (как бы тактика), а “зачем?” и “чем этот подход лучше?” и собственно как это может жить в большой организации (как бы стратегия).
Данный текст представляет собой конспект, написанный в общем-то для осмысления и запоминания материала. Я скорее “чукча-читатель”, чем “чукча-писатель”, поэтому за рифмой следить особо не буду. Работаю мелким development менеджером в большой компании (200 — 12.000 — 90.000 человек, смотря что считать) и учавствую в нескольких проектах, где участником, а где и зрителем. В последнее время организационные и политические задачи поражают своей сложностью и “пописать код” воспринимается как отдых. Это я “пожаловался на жизнь” и теперь переходим к конспекту.
"Видео длится практически час; видео и звук очень хорошие; слайдов не нашел потому делал скриншоты; английский легкий и внятный, самое сложное слово “cohesive” потому очень рекомендую посмотреть, можно даже всей командой, чтобы было общее понимание и терминология.
Микросервисы не решат многие проблемы — неправильную постановку задачи, слабые процессы и дурные привычки сотрудников:
- Неправильная постановка задачи — заказчик может быть не прав либо “сам не знает что хочет” либо “предлагает решение (добать мне эту колонку)”.
- Процессы — микросервисы сложнее чем мотолиты в плане развертывания, и жить легче не станет, если есть какие-то проблемы с DevOp или Continuous Integration / Deployment то они вылезут наружу очень быстро.
- Плохие привычки — плохой код не станет лучше.
И только дисциплина и осознание (maturity) помогут нам, аминь.
И еще есть закон соответствия архитектуры продукта его же оганизационной структуре.
Тут Udi слегка прошелся по непреодолимым 40-летним законам…
Дальше больше — модные понятия подаются как де факто лучше чем старые, что в корне неправильно. И вообще — все борятся со зависимостями (coupling) в любых их проявлениях, практически возведя в основной архитектурный принцип: сильно_зависимые=монолит=плохо и слабо_зависимые=микросервисы=хорошо!
Udi предлагает посмотреть на coupling еще раз.
Слева — это как мы писали “всегда” — один процесс, класс C1 вызывает метод класса C2 напрямую и так же прямо передает параметры.
Справа — мы разместили С1 и C2 в разные процесс (конечно классы теперь надо оформить как компоненты, но это логически ничего не меняет). Всесто прямого вызова мы теперь используем RPC или XML+SOAP или JSON+REST. Можно ли сказать что компоненты стали “логически независимыми”? Нет. Изменилось ли логика “концептуально”? Нет.
Дальше Udi говорит, что надо бояться инициативного программиста который считает себя самым умным и творчески решает то, что он считает важной задачей — борьбу с явными зависимостями между компонентами. Данные, по сути, “прячут” в базу и передают “только ID”. Особо умные и продвинутые прячут базу DB в “сервис” который “очень маштабируемый и совсем не SQL”. И гордо говорят — вот вам два слабо связанных сервиса!
Но все стало в разы хуже: явная, хорошо отслеживаемая и документированная чуть ли не на уровне исходных кодов зависимость теперь “спрятана” и замаскирована десятком слоев разных протоколов, языков и технологий. И это только начало!
Дальше хуже — сервисы пишут разные команды и схема в базе перестает быть “чья-то” — она теперь сама по себе. Но “умный” программист и тут не сдается, а прячет часть схемы просто в поле — JSON это ведь строка, д? Да! И вот вам “расширяемость”! И вот вам metadata и бизнес правила — надо? Ну ведь круто и модно? Дааа!!!
А теперь давайте сравним “добавить еще один параметр x в Foo(a,b,c,d,x)“ и “еще одно поле” в то что получилось после новомодных улучшений.
И в какой-то момент мы понимаем, что есть вещи которые “логически должны быть связаны” и не надо с этим бороться. Если, на пример, разорвать связи в атоме, то мы получим много энергии, деструктивной, и то же самое в бизнес логике. Udi предлагает использовать понятие “cohesive” (сплоченность).
И тогда как бы становится проще — да мы видим, что в системе есть несколько атомов (которые не надо разрывать!) и они как-то связаны.
Дальше Udi обращает внимание, что UI это тоже часть “сервиса” (атома, микросервиса) и традиционный подход когда “у нас есть команда знатоков HTML/JS/CSS — они нам все сделают, а мы поговорим о сложных серверных частях” это не очень правильный подход. И что UI надо бы, по хорошему, тоже делить на microviews. И “традиционны” подход в котором “продукт” включает в себя и цену и название и картинку и т.д. — это очень упрощенный подход который не имеет ничего общего ни с бизнесом, ни с реальностью.
И немного о том, что (микро)сервисы могут быть разные — и по технологиям и по требованиям к deployment.
Дальше Udi как-то незаметно перешел на место микросервисов в “рельной” жизни и в процессе ведения проектов, где продукт работает на разных платформах и написан (обычно) разными командами.
И все происходит очень медленно и натурально, но в какой-то момент обнаруживается, что одни и те же, концептуально, блоки повторяются в разных проектах, и их можно тоже рассматривать как более крупные сервисы или компоненты.
И все вроде бы хорошо, но можно присмотреться и увидеть, что стек технологий очень разный — где .Net, а где и Objective-C. И как-то уже странно видеть много технологий внутри одного микросервиса (uS1) и задаются вопросы типа “у нас же есть команда которая пишет на Objective-C, и команда которая пишет на T-SQL”. Да, здесь мы столкнулись с Conway’s Law — организация пытается подмять проект под свою структуру. Можно попытать предложить cross-functional team, но это воспринимается тоже через призму Conway’s Law — “да да, конечно, программисты и тестеры должны работать вместе, главное чтобы программисты работали в той же технологи что и я”.
Далее Udi объясняет, что программисты должны работать в разных технологиях. Тогда мы как бы остается в пределах организационных структур…
… тут я остановил видео и пытался сопоставить видел ли я подобное в жизни? Да и Нет. Во первых, я видел не много программистов которые могут переключаться между .Net — CSS — JavaScript — Java — Objective-C в течении дня. Переключаться для “поговорить” могут, наверное, все, но переключаться чтобы “отлаживать сложный код” — нет, не видел. Но наверное это часто — в течении дня, да и представить такое сложно — это не работа, а аврал сплошной. Если рассмотреть переключение “раз в квартал”, то это более реально, но тоже, людей, которые могут осмысленно писать новое в разных технологиях, я знаю мало, очень и очень мало. В средней команде прийдется еще и переучивать народ ежеквартально — средний программист очень быстро забывает даже свой собственный код, не то что особенности какой-то библиотеки или конфигурации утилит.
А во вторых, в этот момент обычно получается, что писать код надо паралельно, и на каждую технологию-язык набирают отдельную команду, а теми разработчиками, о которых говорит Udi, становятся не программисты, а бизнес аналитики или владельцы продукты (сервиса) — то есть мы все равно остаемся в рамках Conway’s Law…
И задаешься вопросом — а правильно ли называть подобное “микросервисом”? Особенно когда мы видим, что оно совсем не микро… да и деплоятся они как бы в разные места — то есть вроде бы они разные сервисы. Но подход “от деплоймента” не главный — например почти всегда все, что мы захотим запихнуть в мобильное приложение, будет упаковано в один пакет — просто потому, что так оно будет быстрее работать-стартовать-и т.д. То есть мы объединим много “сервисов” в один пакет просто потому что такова специфика данного устройства. Ну и хорошо — это физические компоненты.
Заключительная часть доклада, это, по сути, попытка воззвать, что все допущения и привычки, которыми мы пользовались все эти годы, их можно иногда пересматривать дабы понять — а работают ли они так же хорошо как и раньше? или что-то можно и улучшать?