Конспект презентации Udi Dahan “Интегрированный подход к сервисам” с конференции µCon 2014: The Microservices Conference
Видео: 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…
И задаешься вопросом —, а правильно ли называть подобное «микросервисом»? Особенно когда мы видим, что оно совсем не микро… да и деплоятся они как бы в разные места — то есть вроде бы они разные сервисы. Но подход «от деплоймента» не главный — например почти всегда все, что мы захотим запихнуть в мобильное приложение, будет упаковано в один пакет — просто потому, что так оно будет быстрее работать-стартовать-и т.д. То есть мы объединим много «сервисов» в один пакет просто потому что такова специфика данного устройства. Ну и хорошо — это физические компоненты.
Заключительная часть доклада, это, по сути, попытка воззвать, что все допущения и привычки, которыми мы пользовались все эти годы, их можно иногда пересматривать дабы понять —, а работают ли они так же хорошо как и раньше? или что-то можно и улучшать?
