«Мы хотим сделать систему по учету персонала. Только у наших архитекторов есть требование, что все у нас должно быть на микросервисах». Это, пожалуй, самый бесячий заход, который нам приходится слышать, как разработчику Jmix – платформы быстрой разработки корпоративных веб-приложений. Почему только микросервисы? Какие проблемы, кроме независимого развертывания они решают? Это действительно необходимо для всех типов приложений? Мы, для полного понимания, ни в коем случае не являемся противниками микросервисной архитектуры, однако неистово сопротивляемся слепому следованию «карго культа». Часто случается, что ничего, кроме удорожания разработки, поддержки и эксплуатации такие решения не приносят. Собственно, об этом и пишет Nikolas Frankel, автор статьи, перевод которой представлен ниже.
Если вы ходите на конференции или читаете технические статьи, то, возможно, думаете, что микросервисы – это единственный и правильный способ выстроить систему. Несмотря на некую оппозицию в лице более трезвых умов, стандартной архитектурой по умолчанию все равно считаются микросервисы. В данной статье мне бы хотелось объяснить, почему это не так. Для начала обратимся к истокам микросервисов и фундаментальной причине их использования. Затем я расскажу, почему микросервисы не подходят для структур большинства организаций. Далее подробно поговорим о главной проблеме, требующей решения. А в завершение статьи я предложу альтернативный и менее рискованный подход.
Вы не работаете с микросервисами
Похоже, что микросервисы сейчас везде. В названии конференции должны фигурировать микросервисы, иначе она не привлечет к себе так много участников. А какие-то конференции и вовсе посвящены только микросервисам. Если говорить о разработчиках, то Hype-Driven Development (она же разработка, основанная на хайпе, или HDD) уже достигла своего апогея. Каждому разработчику нужно указывать в резюме «микросервисы». В противном случае, их могут даже не рассматривать на какую-то должность. Я постоянно твержу, что наша отрасль сошла с ума: большинство тенденций продиктованы хайпом, а не здравым смыслом. Прежде, чем мы продолжим, необходимо определить, что такое микросервисы. Я ограничусь цитатой Мартина Фаулера, поскольку она отражает самую суть.
Если вкратце, то это подход к разработке отдельного приложения как набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с помощью легковесных механизмов, часто с API-интерфейсом HTTP-ресурсов. Эти сервисы построены вокруг бизнес-возможностей и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления данными сервисами, а сами сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных.
Микросервисы. Определение этого нового понятия в архитектуре
Далее в статье описываются характеристики микросервисов:
компонентизация в виде сервисов (оно же: представление через компоненты);
выстраивание вокруг бизнес-потребностей;
умные конечные точки и тупые каналы;
децентрализованное система управления;
децентрализованное управление данными;
автоматизация инфраструктуры;
страховка от сбоев;
эволюционный дизайн;
продукты, а не проекты.
В общем и целом, все выглядит вполне неплохо, пока мы не доходим до последнего пункта. Проект и продукт – вещи совершенно разные. У проекта есть запланированная дата завершения, а продукт будут разрабатывать до тех пор, пока не решат вывести из эксплуатации (иначе говоря, свернуть). Как это в реальности: большинство организаций планируют проекты. То есть они не могут заявлять, что создают микросервисы (если, конечно, не захотят доказать неправоту Фаулера). До начала всей этой шумихи с микросервисами писатели и спикеры старались объяснить закон Конвея:
Любая организация, которая разрабатывает систему (в широком смысле), создает проекты, структуры которых являются копией структуры связей организации.
Следовательно, если вы хотите спроектировать микросервисную архитектуру, но нужно выстраивать свою организацию вокруг небольших команд. И такой подход действительно задокументирован в Amazon Web Services:
«Мы стараемся создавать команды такого размера, чтобы их можно было бы накормить двумя пиццами», – сказал Безос: «Мы назвали это правилом «команды на две пиццы»».
Основная идея «команды на две пиццы» заключается в том, что для достижения максимально возможной производительности команда должна быть как можно более независимой. Для таких команд характерна самоорганизованность и автономность. По закону Конвея, если организация сформирована из «команд на две пиццы», то со временем она непременно перейдет к микросервисной архитектуре. Возникает наивный вопрос: неужели компании, в которых реализованы микросервисы, состоят из небольших автономных команд? К сожалению, традиционные компании по-прежнему формируются из разобщенных подразделений. А единственный способ достичь приличных результатов с микросервисной архитектурой – это выстроить организацию вокруг них. Но это масштабное изменение организационной структуры! На него нужно время, готовность пойти на такой шаг, а также специализированная помощь со стороны экспертов по изменению стратегии управления.
Однако в реальности все совершенно не так. Технический руководитель или специалист по архитектуре читает о микросервисах. По большей части они запоминают сплошные плюсы, забывая о требованиях и минусах. Более того, из-за специфики своей должности, они рассматривают задачи с технической точки зрения. Так что, исходя из закона Конвея, все попытки выстроить микросервисную архитектуру обречены на провал. Результатом этой затеи может стать информационная система, которая не сможет задействовать практически никакие сильные стороны микросервисов (если таковые имеются), но зато столкнется во всеми их недостатками.
Время поставки
Одном из своих постов Фаулер упоминает плюсы и минусы микросервисов:
На мой взгляд, главная причина для перехода на микросервисы – это независимое развертывание:
Есть множество других способов реализовать жесткие границы модулей, причем с меньшим количеством трудностей.
Технологическое разнообразие может удовлетворить технические амбиции некоторых сотрудников. В то же время оно наносит ущерб всей организации в целом, затрудняя найм, обучение и снижая т.н. «фактор кирпича» (Примечание от автора: на англ. bus-factor).
А теперь вопрос: почему так жаждут независимого развертывания? Бизнесу совершенно нет дела до развертывания как такового; ИТ-отдел – это просто огромный черный ящик. В ИТ важны два показателя:
Срок реализации – время, которое нужно команде разработки для реализации определенной функции.
Время развертывания – время, которое нужно команде интеграции для развертывания готовой реализации в рабочей среде.
Но все это внутренние процессы в ИТ. Бизнес волнует лишь то, сколько времени потребуется на запуск спецификации в производство, а не ее внутренние разбивки. Давайте считать время поставки суммой сроков реализации и времени развертывания.
Сокращение времени доставки – проблема далеко не новая, и в прошлом уже находились другие решения.
Время поставки отличается от времени производства, одного из «золотых» стандартов в DevOps. Время производства включает в себя время спецификации – временную задержку от основной идеи до окончательной спецификации. Мой опыт показывает, что время спецификации сводится к многократным дискуссиям между управленцами и ИТ. Конечно же, во многом это зависит от зрелости организации. И все же, в рамках данной статьи корректнее использовать время поставки.
Обработчик правил
До того, как люди вывели теоретические концепции гибкой методологии и непрерывного развертывания, предприятия развертывали системы по несколько раз в год. Мы называли их «релизными поездами» (Release train). Ведь они и правда похожи на поезда: если какую-то функцию доделали с опозданием, то придется ждать следующего релизного поезда. В зависимости от частот релизов, речь могла идти о паре месяцев или даже полугоде. А бизнес не хотел опоздать на поезд!
Единственными допустимыми изменениями (кроме релизного поезда) были исправления ошибок. Это традиция, проверенная временем: впихнуть в исправленную версию одну-две незначительные доработки, чтобы не приходилось ждать следующего поезда. Бывало, что все получалось, но чаще всего релиз-менеджер (он же страж) накладывал свое вето. Периодически начиналось перетягивание каната между управленцами, которые хотели как можно быстрее перейти к развертыванию, и командой, видевшей в этом какие-то риски. Напряжение между бизнесом и ИТ помогло найти оригинальные решения. Среди которых были обработчики правил:
Обработчик правил – это программная система, которая выполняет одно или несколько бизнес-правил в рабочей среде. Правила могут диктоваться правовыми нормами («Сотрудник может быть уволен без причины или по любой причине, кроме незаконной»), корпоративной политикой («Все клиенты, единовременно потратившие свыше $100, получают 10% скидку), либо другими источниками. Система бизнес-правил позволяет определять, тестировать, выполнять и поддерживать корпоративные политики и операционные решения отдельно от кода приложения.
В качестве примера рассмотрим приложение для расчета налогов. Налоги могут в любой день поменяться. И чтобы снять с ИТ-отдела излишнюю нагрузку, логику расчета налогов вынесли в обработчик правил.
Пользовательский интерфейс, код маршрутизации и бизнес-логика, не связанная с налогами, остались в самом приложении. Основная идея сводится к тому, чтобы у бизнеса была возможность настроить эти правила в рабочей среде самостоятельно, без вмешательства ИТ. Бизнес-эксперты могут изменять правила вне зависимости от частоты выхода релизов. Конечно, с большими полномочиями приходит и большая ответственность. Бизнес – независим, но страдает от последствий ошибок в конфигурации.
Части кода меняются с разной скоростью
В приложении выше мы перенесли логику расчета налогов в обработчик правил. Разработчики приложений заранее решили, что чаще всего будет меняться именно эта логика. И действительно: любое изменение в законодательстве может сказаться на расчете налогов и повлечь за собой изменения в коде. Так что лучше отделить жизненный цикл расчета налогов от обычного приложения, ведь они меняются в разном темпе. А что еще хуже: первый меняется с произвольной скоростью, и бизнес не влияет на закон.
Пример с налогами весьма банален. Тем не менее, суть в том, что во всем многообразии приложений одни их части меняются чаще других. В результате приверженцы микросервисного подхода разбивают приложение на отдельные единицы, которые можно будет изменять по отдельности. В первом разделе я показал, почему такая схема не работает без выбора правильной структуры организации.
Кроме того, у этого подхода есть два допущения при проектировании:
Мы можем как-то определить границы модулей на этапе проектирования.
Все части необходимо изменять с разной скоростью.
И то, и то – явное заблуждение.
Современный консенсус о микросервисах, похоже, предлагает начинать с монолитов. И лишь потом – спустя какое-то время – можно детализировать границы. Вот тогда и наступает момент поделить все на микросервисы.
А что, если вместо разбивки на микросервисы, просто «отсечь» часть, которая меняется чаще всего (или хаотичнее)? Так у нас останется тот же монолит за вычетом одной единицы. И для этого модуля будут доступны различные способы реализации:
обработчик правил – если вы уже с ними работали и остались довольны;
бессерверные функции;
«обычные» микросервисы;
какой-то другой вариант?
Как отсекать?
Как только вы продумали границы и изолировали модуль для «отсечения», возникает следующая проблема: каким образом это сделать? В одной своей известной статье Мартин Фаулер (опять он!) описывает паттерн «Душитель» (Strangler):
Обходной путь: постепенно выстраивать новую систему по границам старой, позволяя ей медленно расти в течение нескольких лет, пока она не задушит старую. На словах кажется сложным. Но я все чаще думаю о том, что подобные варианты – недостаточно опробованы. При этом мною выявлено несколько эффективных базовых стратегий. К основополагающей стратегии относится перехват событий (EventInterception), который подходит для постепенного переноса функционала в фикус-душитель и захвата ресурсов (AssetCapture).
Таким шаблоном можно пользоваться для перехода к микросервисной архитектуре. К слову сказать, Крис Ричардсон включил его в свою подборку микросервисных шаблонов. В то же время ничто не мешает вам:
перенести часть приложения куда-то еще. К примеру, в бессерверную функцию;
в любой момент остановиться.
Самая большая проблема связана с клиентами. Перенос конечной точки HTTP в другое место гарантированно все сломает. Однако с помощью интерфейсного API-шлюза проблема решается на ура. Просто направьте запрос в новое местоположение точки, и все готово.
Заключение
В данной статье я подчеркнул, что для большинства организаций микросервисы в том виде, в котором их представляют на конференциях, обречены на провал. В то же время современная среда требует частого обновления отдельных частей кода. А поскольку до первого развертывания будет трудно разобраться во всех модулях, логичнее начать с простого монолита. Со временем мы можем проанализировать, какие части системы обновляются чаще всего.
На данном этапе можно отсечь эти части, превратив их в отдельные модули развертывания. Природа таких модулей (микросервис, бессерверная функция и т.д.) не меняет общей архитектуры. А для корректной работы клиентов надо просто поменять маршруты в API-шлюзе со старой конечной точки на новую.
Комментарии (22)
Algrinn
09.10.2023 09:31Нуу.. Там не уточнили, хотят одну базу данных или много БД, нужен ли кластер(kubernetes) или нет, нужна ли шина данных (kafka) или нет, stateless или statefull. Нужно ли всё максимально усложнять или нет. А какая нагрузка? Можно использовать популярные фреймворки или нужно собирать гоночный болид? А сколько людей в команде и с какими навыками? В общем, нужны микросервисы - ок, собираем самое простое на микросервисах Spring Boot Microservices. До этого пишем кучу документов и весь анализ архитекторов на форумном движке, с указанием причин, следствий, прогнозов. Кто знает, может там не микросервисы нужны, а очень серьёзный корпоративный Application Server и транзакции в БД. Зря что-ли их корпорации писали? :-)
DikSoft
09.10.2023 09:31+2Нуу.. Там не уточнили, ..
Вот с такого подхода и начинается беда.
Бизнесу нужны не микросервисы, а вполне реальный конечный результат. И уже в зависимости от его требуемых параметров, нормальный адекватный проктировщик (архитектор) должен выбирать, реально что-то будет полезное с микросервисов или они там даром не сдались. Начинать надо не с выбора "кафка/зуукипер вкорячиваем"? )))
BASic_37
09.10.2023 09:31+1Там не уточнили, хотят одну базу данных или много БД, нужен ли кластер(kubernetes) или нет, нужна ли шина данных (kafka) или нет, stateless или statefull. Нужно ли всё максимально усложнять или нет. А какая нагрузка? Можно использовать популярные фреймворки или нужно собирать гоночный болид?
Кто там не уточнил? Статья похоже как раз про вас, перепутавших причины и следствия.
ihouser
09.10.2023 09:31„все у нас должно быть на микросервисах“
Это не карго культ а перегиб с рекламой. Рационально обосновать необходимость могут только опытные разработчики. Таких не так много, поэтому решения чаще принимаются на основе рекламного шума.
kekoz
09.10.2023 09:31Я что-то не особо вижу рекламу микросервисов. Зато у меня уже голова кругом от рекламы курсов менеджеров (в разработке ПО) как способа “вкатиться в айти”. Что мы имеем в результате? Правильно, управлять разработкой приходят вот такие менеджеры, у которых опыта разработки ноль от слова “совсем”, а на курсах им рассказали, что “Микросервисы рулят, назовите любое громкое имя на рынке — и там будут микросервисы”.
В отсутствие опыта вперёд зачастую выступает вера. А вера — основа карго-культа. “Сделаем микросервисы и скоро с неба упадут офигилиарды, как у микросервисных «Рога и копыта» и «Бочковые апельсины»”
ihouser
09.10.2023 09:31Карго-культ, это когда "модно, молодежно, у соседа есть" ну и вера в придачу. А когда на курсах "знающий" рассказывают, это уже рекламная информация. Хоть и не качественная, но информация.
Вообщем, тут грань между верой и информацией размыта, так что давайте не будем ее уточнять :)
dom1n1k
09.10.2023 09:31Во ряде случаях микросервисы обосновываются не техническими, а иными причинами. Микросервисы — это меньшая осведомленность большинства сотрудников об общей картине проекта. Как следствие, они более взаимозаменяемы и меньше вероятность, что кто-то из них позднее сможет построить конкурента на стороне.
DikSoft
09.10.2023 09:31+1Во ряде случаях микросервисы обосновываются не техническими, а иными причинами.
Могу ещё причину привести. Разработчики: "а мы по другому не умеем, у нас лапки"
KartonDev
09.10.2023 09:31+3Если говорить о технических проблемах, то есть множество контр-примеров того, что микросервисы как решение "технических проблем", является путем куда более длинным и тяжелым, нежели SOA-подобный монолит, и тому есть куча примеров, множество докладов с highload-а идут с топиками подобными "как мы решили проблему нагрузки" и очень часто дело не в монолитах, достаточно вытащить из монолита узкое горлышко (bottle throat) и вы получите куда более потрясающие результаты не сильно уступающие монолитам.
В пример, можно взять Gitlab - там решили проблему с файловой IO нагрузкой по средствам выделения слейвов которые являются git-холдерами (RPC микро сервис которому дают git комманды), я когда то изучал архитектуру гитлаба и там полноценный монолит, все не координально важные но нагруженные фичи просто перенесены в сервисы.
Другой важный пример - Shopify. Тут решение еще более простое - они создали монолит по тенантам, каждый тенант отдельно имеет свой pod или несколько тенантов имеет свой под, из за чего лоад-балансеры распределяют с легкостью клиентов по не нагруженным тенант-podам. B свою очередь сверх-перегруженный маркет превращается в простой монолит, у которого не так уж и много нагрузки. Не правда ли, это прекрасное архитектурное решение? Казалось бы тир1 система для покупок, хайлоад, однако, все технические решения решаются на уровне архитектуры и деплоя, а не на уровне "хайпа".
Как мне кажется монолит - очень громоздкий способ решения простых проблем. Лишь действительно большие проблемы могут быть решены данным способом, а все остальные проблемы намного проще решаются при помощи монолитов или архитектурных SOA. Если у вас шташ в 100+ человек только разработчиков и у вас килотонны метрик, то очевидно, что монолит - единственно правильное решение, а иначе я бы 10 раз задумался, хочу ли я для каждой из команд тратить половину времени на то, чтобы документировать API, утверждать API между командами и тратить кучу времени на то, чтобы модифицировать API между командами(одна просит другую ради какой то фичи) и те. Да, связность падает, однако, на практике, очень редко, когда архитектура и АПИ утверждаются и не вносятся изменения в АПИ, а в этом главная проблема микросервисов - человеческая бюрократия в межсервисном взаимодействием. Если вы попробуете меня переубедить с аргументом, что деплой проще, то можете посмотреть топик Self Contained Systems, расширенный термин SOA или в простонародии сообщающиеся монолиты, они решают многие проблемы команд, независимости систем, отказоустойчивости и деплоя.
Вывод из данного треда можно сделать один - самое главное - это архитектурная проработка, "человеческая архитектура", а то, какой фреймворк или какую "физическую архитектуру" вы выбрали - не так уж важно, ведь даже микросервисы могут быть медленные, если вы не умеете ими пользоваться, а лишь пытаетесь залезть на хайп-трейн!
aktuba
09.10.2023 09:31+2что кто-то из них позднее сможет построить конкурента на стороне
Каких только "обоснований" микросервисам не слышал, но вот такое впервые... "Построить конкурента"? Вы серьезно? Вон, доступен код почти всех сервисов Яндекса. Много конкурентов появилось?
dom1n1k
09.10.2023 09:31Код это одно, а погружение в нюансы и их мотивацию — другое. На это годы могут уйти.
aktuba
09.10.2023 09:31Это верно. Как и то, что в 99.99% случаев код не играет никакой роли, важны данные и процессы. Большинство сервисов не имеет каких-либо ноу-хау.
dom1n1k
09.10.2023 09:31Так про то и речь. Не про код как таковой, а про картину, которая формируется в голове у людей в процессе работы над ним. Если человек пилит микросервис под узкую задачу, картина тоже сужается.
Это, если что, не я придумал.
Batalmv
09.10.2023 09:31+1Полностью поддреживаю основной посыл, но чуть-чуть покритикую в частностях
По закону Конвея, если организация сформирована из «команд на две пиццы», то со временем она непременно перейдет к микросервисной архитектуре. Возникает наивный вопрос: неужели компании, в которых реализованы микросервисы, состоят из небольших автономных команд?
....
Так что, исходя из закона Конвея, все попытки выстроить микросервисную архитектуру обречены на провал.
В реале это легко достижимо, так как многие организации давно таки и работают. Все очень просто. В организации часто есть линейная структура, которая абсолютно традиционна и есть дерево по сути, и "проектная", когда под конкретную задачу нарезаются люди в "проект" с подчинением ПМу. Поэтому получить "команды на две пиццы" в организациях с традиционной структурой научились уже давно
На мой взгляд, главная причина для перехода на микросервисы – это независимое развертывание
Да, для меня это неоспоримое преимущество микросервисови чуть-ли не единственное. В монолите вы никак этого не получите. Поэтому микросервисная архитектура удобнее для команды, так как любой разработчик за считанные минуты может собрать "среду" для проверки своей версии кода как с эталонной версией приложения, так и к примеру с изменениями другого разработчика.
Также надо принять во внимание, что "под капотом" процедуры развертывания уже есть 100500 технологий, которые отлично работают. Т.е. это не теория, а вполне простые и понятные инструменты
Остальные "преимущества" микросервисов достижимы на монолите без особых сложностей. Но это ... почти никак :(
Бизнесу это правда не нужно, но это нужно команде
Кроме того, у этого подхода есть два допущения при проектировании:
Мы можем как-то определить границы модулей на этапе проектирования.
Все части необходимо изменять с разной скоростью.
И то, и то – явное заблуждение.
Вот тут я не понял, почему это заблуждение. Ну смотрите. При проектировании "логической" части приложения мы выделяем домены. Если есть время, даже прописываем связи и решаем, как их будем реализовывать, чтобы зависимости были явно прописаны, как и методы борьбы с негативными последствиями из-за отказов. Ну я, как архитектор, обычно до начала разработки прописываю для себя модули, их функции, связи/сервисы. Это нужно в том числе, для проверки того, что решение покрывает все то, что уже известно сейчас о бизнес требованиях и насколько принятые технические решения по стеку адекватны. Понятно, со временем может что-то меняться, но так как домены и логика - это отрадение реального мира, есть большая вероятность не промахнуться
vfadeev_sam
09.10.2023 09:31+1Накину пару комментариев.
В реале это легко достижимо, так как многие организации давно таки и работают. Все очень просто. В организации часто есть линейная структура, которая абсолютно традиционна и есть дерево по сути, и "проектная", когда под конкретную задачу нарезаются люди в "проект" с подчинением ПМу. Поэтому получить "команды на две пиццы" в организациях с традиционной структурой научились уже давно
Нет, это не достижимо и не просто. Приведу простой пример из жизни. Большие компании в погоне за снижением риска коррупции и конфликта интересов используют простое решение - вводят в организационную структуру собственные отделы внутренней безопасности. Как Вы думаете это снижает уровень возникновения рисков коррупции и конфликтов интересов при трудоустройстве родственников на хорошие посты? Правильно - не снижает, а просто создает для этого новые правила - мутации, красиво "обмазанные" регламентами. Так же и с отдельными "проектными" офисами в жестко зарегулированных структурах. Первым признаком мутирования таких "проектных" групп является появление в них системного аналитика. Вы в курсе, что это вообщем-то чисто российский прикол, что в проекте появляется бизнес-аналитик и системный аналитик. За кордоном нет такой выделенной функции - она интегрирована в PM или лида. А у нас есть. И знаете зачем? Чтобы кого-то оставить крайним, потому что в жестких иерархических структурах - он должен быть. Если косяк с тем, что получилось - системный аналитик неправильно описал бизнес-требования или неправильно передал требования в разработку. Тут никаких самоуправляемых команд нет, как нет и продуктового мышления также им свойственного. Традиционная организационная структура синтезирует "крайних" даже в проектных командах, хотим мы этого или нет. Поэтому в жесткой иерархической структуре не может быть самоуправляемых команд, так как в принципе отсутствует культура коллективной ответственности за результат, но есть культура "крайнего". Как найти крайнего в распределенной самоорганизущейся микросервисной архитектуре? Закон Конвея работает.
Вот тут я не понял, почему это заблуждение. Ну смотрите. При проектировании "логической" части приложения мы выделяем домены. Если есть время, даже прописываем связи и решаем, как их будем реализовывать, чтобы зависимости были явно прописаны, как и методы борьбы с негативными последствиями из-за отказов. Ну я, как архитектор, обычно до начала разработки прописываю для себя модули, их функции, связи/сервисы. Это нужно в том числе, для проверки того, что решение покрывает все то, что уже известно сейчас о бизнес требованиях и насколько принятые технические решения по стеку адекватны. Понятно, со временем может что-то меняться, но так как домены и логика - это отрадение реального мира, есть большая вероятность не промахнуться
Формулировка автора выглядит категоричной. Полагаю, что в первом пункте акцент именно на границах модулей, которые являются зонами повышенной неопределенности и собственно отношению команды к риску дополнительных затрат из-за overengineering. Если отношение к риску консервативное - грубо говоря проект на стадии MVP и денег три копейки, то зачем брать на себя дополнительные риски на выстраивании дорогой микросервисной архитектуры. Но еще раз - это спорно. Как всегда "it depends". Во втором пункте полагаю автор хотел сказать, что только руководствуясь этим допущением нельзя принимать решение о построении всего приложения на микросервисной архитектре. Большую часть проекта, который изменяется с равной скоростью, разумнее сделать монолитом.
Batalmv
09.10.2023 09:31+1Нет, это не достижимо и не просто. Приведу простой пример из жизни
Вы как-то сильно ушли в сторону в своей организации :)
Причем здесь какие-то несколько "мифические" отделы внутренней безопасности? Я вообще не понял связи. Ну есть они, нет их, работают они эффективно или нет. Как это влияет на эффективность работы внутреннего PMO и команд, которые им управляются?
Также я не совсем понял о роли системного аналитика, или просто аналитика. К примеру, я работал в IBM. Там роль аналитика есть и отлично себя чувствует. Но опять же, как это связано с обсуждаемым вопросом?
По сути, проектная структура работает просто:
во-первых, она работает по своим правилам, которые согласовываются с процедурами других линеных подразделений. К примеру, процедуры передачи разработанного софта в "линейную" ИТ поддержку или согласование "линейной" ИТ безопасности. Но тут никаких проблем нет
во-вторых, на проект люди действительно набираются, и внутри могут уже устанавливать собственные правила, что тоже не является чем-то сложным или проблемой
команда в таком случае соответствуют размеру проекта, а в больших организациях с сложным ИТ-ландшафтом - может быть много команд, каждая из которых отвечает за свою часть
Успешность ПМО определяется очень просто (потому что он может быть неуспешным). Проекты делаются для изменения организации во имя ее блага. И на это выделяются ресурсы и бюджеты. Если проекты успешны - успешно и ПМО. Более того, часто оно монополизирует право на управление изменениями через проекты.
Если отношение к риску консервативное - грубо говоря проект на стадии MVP и денег три копейки, то зачем брать на себя дополнительные риски на выстраивании дорогой микросервисной архитектуры.
Ну давайте тоже трезво. Она не является дорогой с точки зрения выстраивания. Особенно, если команды уже собаку съели на этом и не изобретают колесо каждый раз. Есть очевидные накладные расходы на коммуникацию между модулями, но это не влияет на накладные расходы для разработки.
Как раз ее главное и неоспоримое преимущество - облегчение разделения работы между участниками процесса.
Ну и вы чуток путаете PoC и MVP. MVP - это уже рабочий продукт, и обычно он не стоит "три копейки". Это продукт, готовый к употреблению. Это PoC стоит "три копейки", так как его цель проверить, что мы на правильном пути и выкинуть в мусорную корзину, оставив чуток на память. MVP обычно делается по всем правилам "продуктивного" релиза
vfadeev_sam
09.10.2023 09:31Возможно я как-то непонятно объяснил, поэтому приведу жизненный пример. Предположим в жестокой иерархической структуре, которая занимается товарно транспортными операциями нефти или газа, стартовал проект по созданию системы управления транспортными потоками на основе микросервисной архитектуры естественно. Для реализации проекта создана отдельная проектная структура, там архитектора, самоуправляемые команды, гибкие практики и все такое. Повезло и они правильно определили границы сервисов и вот одна команда разрабатывать и совершенствует сервис планирования загрузки трубы на основании откуда-то поступивших заявок, которые делает другая команда, и передает данные о порядке организаций партий продукта в какой-то другой микросервис. Вдруг, происходит сбои и в результате по какой то причине в трубе оказался избыток или недостаток углеводородов для поддержания технологического давления. Первыми как правило идут на плаху АСУТПшники и метрологи. Но выясняется, что там все ок. Приборы поверены, а в системе управления нет ошибок и все идет в плановом режиме. Вопросы к планово-диспетчерской службе, а те говорят - слушайте мы вот сюда что-то вбиваем, а там дальше микросервисы и вон в той agile структуре самоуправляемые команды какие-то. Я вас уверяю, после этого инцидента эта самоуправляемая команда будет ликвидирована, потому что иерархическая структура не умеет этим управлять. И будет создан большой такой монолитный сервис планировщик транспортных потоков, владельцем которого будет руководитель планово-диспетчерской службы, которому абсолютно плевать на архитектуру и не плевать на свое рабочее место. Конец истории.
Batalmv
09.10.2023 09:31Смотрите, давате разделять "культуру" управления и остальное
Я понимаю (хотя корни намного глубже), совдеповское прошгое оставило в наследство стиль, который можно охарактеризовать следующими принципами:
тащить и не пущать
я начальник - ты дурак
у ошибки всегда есть имя и фамилия и т.д.
Это да, есть - но такая реакция вызвана именно такой "культурой". Это конечно не значит, что на западе ее нет, но в целом ее проявления намного меньше.
Теперь о орг. структуре. Из личного опыта я могу привести две работающие модели:
-
Проект делает решение и отдает в консолидированную поддержку.
ИТ поддержка принимает решение как часть СВОЕГО ИТ-ландшафта и поддерживает. Прикол в том, что 3я линия поддержки - это микс из внутренних разработчиков/внешних вендоров. В описанном примере ИТ поддержка не сможет огульно обвинить "команду", так как ее УЖЕ НЕТ :) А дальше, есть риск получить ответку от равного по силе подразделения внутренней разработки, если косяк в части, которую делали они, либо вежливую, но часто более компетентную ответку от внешнего поставщика. Поэтому либо "разбираться" в сути, либо - играть в политику. Первое - ответ на ваш вопрос. Второе - нас уводит в область обсуждения культуры. И да, члены команды (я, как архитектор, к примеру), тоже могут быть сделаны козлом отпущения, точнее такая попытка будет совершена. А дальше, как показывает практика, пару публичных ответок - и желание безосновательно связываться пропадает. Политически же сила ПМО + внедрятелей в эффективном внедрении. Если ты обеспечиваешь развитие, то политически ИТ поддержка всегда на вторых ролях, но жаждет найти ошибку и тогда задвинуть по самые помидоры. Что стимулирует не лажать по крупному :) Очень стабильная конструкция, но надо иметь "зубы" и не бояться в ответ "бить", не глядя на погоны
Организация переходит к сервисному подходу и внутренним SLA. Это "следующий" (на самом деле он принципиально другой, пожтому и кавычки). Но тут все просто. Все обложились SLA и попытка "нападения" отражается сразу "на границе". Либо не отражается и команда идет получать заслуженный пистон
Я так понимаю, вам более интересен вариант 1. Он реален. Но ... надо понимать, что есть ПМО + его поддержка слабы и неэффективны - да, их будут бить и возмодно ногами. Это сложная работа, и многие не справляются. Поэтому рецепт не универсален, так как без кадров такой подход обречен. Но это касается почти любого подхода
titan_pc
09.10.2023 09:31-1А в завершение статьи я предложу альтернативный и менее рискованный подходНу и где подход то? Начать с монолита? Америка открыта снова...
А можно начать сразу с архитектуры и определения бизнес модели, всё как следует описать и смоделировать большинство основных бизнес-процессов. Не писать код вообще, месяц другой. И ничто уже не помешает сделать микросервисы сразу.
А если команда маленькая - есть квантовые сервисы + чистая архитектура с инверсией зависимостей и разделение кодовой базы на слои, где слой технологий выпилить в библиотеки.
Основная идея квантового сервиса - одна кодовая база(один проект) - одна команда. Чистый монолит разлагать на докеры путём декомпозиции апи, то есть слоя интерфейса. При этом ядро бизнес модели лежит как кусок независимого от апи кода (и от СУБД если использовать чистую архитектуру, хотя на слоевую оверхеда меньше). На выходе получается целая пачка докеров с одного проекта. Каждый докер масштабируется горизонтально через балансировщик всё как в микросервисах. Но при этом внутри везде одинаковый код ядра. Код он много не весит его не жалко везде засунуть. А что это даёт ? Все плюсы микросервисов раз. Всё удобство монолита два. А ещё убирает оверхед на организацию общения между микросервисах. Потому что они все на борту уже содержат бизнес-модель всю. Вот - решение.
KartonDev
09.10.2023 09:31Вполне себе предложение, как я писал выше, монолит(так сказать все пошло от SOA) не обязан быть одним, просто чем больше сервис(система), тем больше он подходит под термин монолита, никто не мешает выделить на огромный кровавый энтерпрайс 5-6 монолитов, заставить их сообщаться и добавить пару "микро" сервиса, которые будут написаны native и иметь высокую скорость обработки запросов, по факту просто решать необходимые вопрос о производительности.
Вот эти приколы про декомпозицию монолита и те очень часто заводят в никуда. Однако, не могу не отметить, если у проекта монолит из 2000х и он на java, то да такое лучше было бы переписать на что то более современно, хотя бы исходя из того, что куча депрекейт кода связанного с безопасность. Вот если у вас стек монолита на интерпретируемом языке, обычно кодовая база в десятки раз меньше, чем на той же Java или .Net, потому всякие Github, Gitlab, Shopify не удалили и не переписали ядро монолита на такие классные микросервисы.
Хотя, можно и пойти по пути Озона - у них сотни микросервисов, но по рассказам все равно есть "фавортные" микросервисы которые можно с натяжкой назвать микро, ведь там куда больше бизнес логики, чем в других.
Так что статья, наверное, в первую очередь говорит о том, что дело не в том какой тулчейн у вас в проекте, а насколько правильно этим tool-ами пользуется команда и как хорошо ПОД них написали архитектуру.
rakerunner
09.10.2023 09:31Не обязательно дробить монолит на 100500 МИКРОсервисов. Можно "резать" его на более крупные куски. Например как это делает SAP. Есть модули FI, CO, PP и пр. Каждый модуль может разрабатываться, развертываться и апдейтиться независимо друг от друга.
Если проводить аналогию со стротельством дома: вместо микросервисов "кран на кухне", "освещение спальни", "входная дверь" можно использовать более крупные блоки "кухня", "спальня", "прихожая" и т.д.
DikSoft
Отличный текст, ода здравому смыслу.
Жаль, что сейчас набегут зайки-попрыгайки с узким кругозором, которые кое-как освоили только кусочек из мира технологий, и завалят всё комментариями "а зато на микросервисах можно так и так..."
Тут недавно в комментариях десктопный калькулятор предлагали на микросервисах писать, веб-приложением. Что уж про чуть более крупные проекты говорить..