Comments 24
Отличный текст, ода здравому смыслу.
Жаль, что сейчас набегут зайки-попрыгайки с узким кругозором, которые кое-как освоили только кусочек из мира технологий, и завалят всё комментариями "а зато на микросервисах можно так и так..."
Тут недавно в комментариях десктопный калькулятор предлагали на микросервисах писать, веб-приложением. Что уж про чуть более крупные проекты говорить..
Нуу.. Там не уточнили, хотят одну базу данных или много БД, нужен ли кластер(kubernetes) или нет, нужна ли шина данных (kafka) или нет, stateless или statefull. Нужно ли всё максимально усложнять или нет. А какая нагрузка? Можно использовать популярные фреймворки или нужно собирать гоночный болид? А сколько людей в команде и с какими навыками? В общем, нужны микросервисы - ок, собираем самое простое на микросервисах Spring Boot Microservices. До этого пишем кучу документов и весь анализ архитекторов на форумном движке, с указанием причин, следствий, прогнозов. Кто знает, может там не микросервисы нужны, а очень серьёзный корпоративный Application Server и транзакции в БД. Зря что-ли их корпорации писали? :-)
Нуу.. Там не уточнили, ..
Вот с такого подхода и начинается беда.
Бизнесу нужны не микросервисы, а вполне реальный конечный результат. И уже в зависимости от его требуемых параметров, нормальный адекватный проктировщик (архитектор) должен выбирать, реально что-то будет полезное с микросервисов или они там даром не сдались. Начинать надо не с выбора "кафка/зуукипер вкорячиваем"? )))
Там не уточнили, хотят одну базу данных или много БД, нужен ли кластер(kubernetes) или нет, нужна ли шина данных (kafka) или нет, stateless или statefull. Нужно ли всё максимально усложнять или нет. А какая нагрузка? Можно использовать популярные фреймворки или нужно собирать гоночный болид?
Кто там не уточнил? Статья похоже как раз про вас, перепутавших причины и следствия.
„все у нас должно быть на микросервисах“
Это не карго культ а перегиб с рекламой. Рационально обосновать необходимость могут только опытные разработчики. Таких не так много, поэтому решения чаще принимаются на основе рекламного шума.
Я что-то не особо вижу рекламу микросервисов. Зато у меня уже голова кругом от рекламы курсов менеджеров (в разработке ПО) как способа “вкатиться в айти”. Что мы имеем в результате? Правильно, управлять разработкой приходят вот такие менеджеры, у которых опыта разработки ноль от слова “совсем”, а на курсах им рассказали, что “Микросервисы рулят, назовите любое громкое имя на рынке — и там будут микросервисы”.
В отсутствие опыта вперёд зачастую выступает вера. А вера — основа карго-культа. “Сделаем микросервисы и скоро с неба упадут офигилиарды, как у микросервисных «Рога и копыта» и «Бочковые апельсины»”
Во ряде случаях микросервисы обосновываются не техническими, а иными причинами. Микросервисы — это меньшая осведомленность большинства сотрудников об общей картине проекта. Как следствие, они более взаимозаменяемы и меньше вероятность, что кто-то из них позднее сможет построить конкурента на стороне.
Во ряде случаях микросервисы обосновываются не техническими, а иными причинами.
Могу ещё причину привести. Разработчики: "а мы по другому не умеем, у нас лапки"
Если говорить о технических проблемах, то есть множество контр-примеров того, что микросервисы как решение "технических проблем", является путем куда более длинным и тяжелым, нежели SOA-подобный монолит, и тому есть куча примеров, множество докладов с highload-а идут с топиками подобными "как мы решили проблему нагрузки" и очень часто дело не в монолитах, достаточно вытащить из монолита узкое горлышко (bottle throat) и вы получите куда более потрясающие результаты не сильно уступающие монолитам.
В пример, можно взять Gitlab - там решили проблему с файловой IO нагрузкой по средствам выделения слейвов которые являются git-холдерами (RPC микро сервис которому дают git комманды), я когда то изучал архитектуру гитлаба и там полноценный монолит, все не координально важные но нагруженные фичи просто перенесены в сервисы.
Другой важный пример - Shopify. Тут решение еще более простое - они создали монолит по тенантам, каждый тенант отдельно имеет свой pod или несколько тенантов имеет свой под, из за чего лоад-балансеры распределяют с легкостью клиентов по не нагруженным тенант-podам. B свою очередь сверх-перегруженный маркет превращается в простой монолит, у которого не так уж и много нагрузки. Не правда ли, это прекрасное архитектурное решение? Казалось бы тир1 система для покупок, хайлоад, однако, все технические решения решаются на уровне архитектуры и деплоя, а не на уровне "хайпа".
Как мне кажется монолит - очень громоздкий способ решения простых проблем. Лишь действительно большие проблемы могут быть решены данным способом, а все остальные проблемы намного проще решаются при помощи монолитов или архитектурных SOA. Если у вас шташ в 100+ человек только разработчиков и у вас килотонны метрик, то очевидно, что монолит - единственно правильное решение, а иначе я бы 10 раз задумался, хочу ли я для каждой из команд тратить половину времени на то, чтобы документировать API, утверждать API между командами и тратить кучу времени на то, чтобы модифицировать API между командами(одна просит другую ради какой то фичи) и те. Да, связность падает, однако, на практике, очень редко, когда архитектура и АПИ утверждаются и не вносятся изменения в АПИ, а в этом главная проблема микросервисов - человеческая бюрократия в межсервисном взаимодействием. Если вы попробуете меня переубедить с аргументом, что деплой проще, то можете посмотреть топик Self Contained Systems, расширенный термин SOA или в простонародии сообщающиеся монолиты, они решают многие проблемы команд, независимости систем, отказоустойчивости и деплоя.
Вывод из данного треда можно сделать один - самое главное - это архитектурная проработка, "человеческая архитектура", а то, какой фреймворк или какую "физическую архитектуру" вы выбрали - не так уж важно, ведь даже микросервисы могут быть медленные, если вы не умеете ими пользоваться, а лишь пытаетесь залезть на хайп-трейн!
Полностью поддреживаю основной посыл, но чуть-чуть покритикую в частностях
По закону Конвея, если организация сформирована из «команд на две пиццы», то со временем она непременно перейдет к микросервисной архитектуре. Возникает наивный вопрос: неужели компании, в которых реализованы микросервисы, состоят из небольших автономных команд?
....
Так что, исходя из закона Конвея, все попытки выстроить микросервисную архитектуру обречены на провал.
В реале это легко достижимо, так как многие организации давно таки и работают. Все очень просто. В организации часто есть линейная структура, которая абсолютно традиционна и есть дерево по сути, и "проектная", когда под конкретную задачу нарезаются люди в "проект" с подчинением ПМу. Поэтому получить "команды на две пиццы" в организациях с традиционной структурой научились уже давно
На мой взгляд, главная причина для перехода на микросервисы – это независимое развертывание
Да, для меня это неоспоримое преимущество микросервисови чуть-ли не единственное. В монолите вы никак этого не получите. Поэтому микросервисная архитектура удобнее для команды, так как любой разработчик за считанные минуты может собрать "среду" для проверки своей версии кода как с эталонной версией приложения, так и к примеру с изменениями другого разработчика.
Также надо принять во внимание, что "под капотом" процедуры развертывания уже есть 100500 технологий, которые отлично работают. Т.е. это не теория, а вполне простые и понятные инструменты
Остальные "преимущества" микросервисов достижимы на монолите без особых сложностей. Но это ... почти никак :(
Бизнесу это правда не нужно, но это нужно команде
Кроме того, у этого подхода есть два допущения при проектировании:
Мы можем как-то определить границы модулей на этапе проектирования.
Все части необходимо изменять с разной скоростью.
И то, и то – явное заблуждение.
Вот тут я не понял, почему это заблуждение. Ну смотрите. При проектировании "логической" части приложения мы выделяем домены. Если есть время, даже прописываем связи и решаем, как их будем реализовывать, чтобы зависимости были явно прописаны, как и методы борьбы с негативными последствиями из-за отказов. Ну я, как архитектор, обычно до начала разработки прописываю для себя модули, их функции, связи/сервисы. Это нужно в том числе, для проверки того, что решение покрывает все то, что уже известно сейчас о бизнес требованиях и насколько принятые технические решения по стеку адекватны. Понятно, со временем может что-то меняться, но так как домены и логика - это отрадение реального мира, есть большая вероятность не промахнуться
Накину пару комментариев.
В реале это легко достижимо, так как многие организации давно таки и работают. Все очень просто. В организации часто есть линейная структура, которая абсолютно традиционна и есть дерево по сути, и "проектная", когда под конкретную задачу нарезаются люди в "проект" с подчинением ПМу. Поэтому получить "команды на две пиццы" в организациях с традиционной структурой научились уже давно
Нет, это не достижимо и не просто. Приведу простой пример из жизни. Большие компании в погоне за снижением риска коррупции и конфликта интересов используют простое решение - вводят в организационную структуру собственные отделы внутренней безопасности. Как Вы думаете это снижает уровень возникновения рисков коррупции и конфликтов интересов при трудоустройстве родственников на хорошие посты? Правильно - не снижает, а просто создает для этого новые правила - мутации, красиво "обмазанные" регламентами. Так же и с отдельными "проектными" офисами в жестко зарегулированных структурах. Первым признаком мутирования таких "проектных" групп является появление в них системного аналитика. Вы в курсе, что это вообщем-то чисто российский прикол, что в проекте появляется бизнес-аналитик и системный аналитик. За кордоном нет такой выделенной функции - она интегрирована в PM или лида. А у нас есть. И знаете зачем? Чтобы кого-то оставить крайним, потому что в жестких иерархических структурах - он должен быть. Если косяк с тем, что получилось - системный аналитик неправильно описал бизнес-требования или неправильно передал требования в разработку. Тут никаких самоуправляемых команд нет, как нет и продуктового мышления также им свойственного. Традиционная организационная структура синтезирует "крайних" даже в проектных командах, хотим мы этого или нет. Поэтому в жесткой иерархической структуре не может быть самоуправляемых команд, так как в принципе отсутствует культура коллективной ответственности за результат, но есть культура "крайнего". Как найти крайнего в распределенной самоорганизущейся микросервисной архитектуре? Закон Конвея работает.
Вот тут я не понял, почему это заблуждение. Ну смотрите. При проектировании "логической" части приложения мы выделяем домены. Если есть время, даже прописываем связи и решаем, как их будем реализовывать, чтобы зависимости были явно прописаны, как и методы борьбы с негативными последствиями из-за отказов. Ну я, как архитектор, обычно до начала разработки прописываю для себя модули, их функции, связи/сервисы. Это нужно в том числе, для проверки того, что решение покрывает все то, что уже известно сейчас о бизнес требованиях и насколько принятые технические решения по стеку адекватны. Понятно, со временем может что-то меняться, но так как домены и логика - это отрадение реального мира, есть большая вероятность не промахнуться
Формулировка автора выглядит категоричной. Полагаю, что в первом пункте акцент именно на границах модулей, которые являются зонами повышенной неопределенности и собственно отношению команды к риску дополнительных затрат из-за overengineering. Если отношение к риску консервативное - грубо говоря проект на стадии MVP и денег три копейки, то зачем брать на себя дополнительные риски на выстраивании дорогой микросервисной архитектуры. Но еще раз - это спорно. Как всегда "it depends". Во втором пункте полагаю автор хотел сказать, что только руководствуясь этим допущением нельзя принимать решение о построении всего приложения на микросервисной архитектре. Большую часть проекта, который изменяется с равной скоростью, разумнее сделать монолитом.
Нет, это не достижимо и не просто. Приведу простой пример из жизни
Вы как-то сильно ушли в сторону в своей организации :)
Причем здесь какие-то несколько "мифические" отделы внутренней безопасности? Я вообще не понял связи. Ну есть они, нет их, работают они эффективно или нет. Как это влияет на эффективность работы внутреннего PMO и команд, которые им управляются?
Также я не совсем понял о роли системного аналитика, или просто аналитика. К примеру, я работал в IBM. Там роль аналитика есть и отлично себя чувствует. Но опять же, как это связано с обсуждаемым вопросом?
По сути, проектная структура работает просто:
во-первых, она работает по своим правилам, которые согласовываются с процедурами других линеных подразделений. К примеру, процедуры передачи разработанного софта в "линейную" ИТ поддержку или согласование "линейной" ИТ безопасности. Но тут никаких проблем нет
во-вторых, на проект люди действительно набираются, и внутри могут уже устанавливать собственные правила, что тоже не является чем-то сложным или проблемой
команда в таком случае соответствуют размеру проекта, а в больших организациях с сложным ИТ-ландшафтом - может быть много команд, каждая из которых отвечает за свою часть
Успешность ПМО определяется очень просто (потому что он может быть неуспешным). Проекты делаются для изменения организации во имя ее блага. И на это выделяются ресурсы и бюджеты. Если проекты успешны - успешно и ПМО. Более того, часто оно монополизирует право на управление изменениями через проекты.
Если отношение к риску консервативное - грубо говоря проект на стадии MVP и денег три копейки, то зачем брать на себя дополнительные риски на выстраивании дорогой микросервисной архитектуры.
Ну давайте тоже трезво. Она не является дорогой с точки зрения выстраивания. Особенно, если команды уже собаку съели на этом и не изобретают колесо каждый раз. Есть очевидные накладные расходы на коммуникацию между модулями, но это не влияет на накладные расходы для разработки.
Как раз ее главное и неоспоримое преимущество - облегчение разделения работы между участниками процесса.
Ну и вы чуток путаете PoC и MVP. MVP - это уже рабочий продукт, и обычно он не стоит "три копейки". Это продукт, готовый к употреблению. Это PoC стоит "три копейки", так как его цель проверить, что мы на правильном пути и выкинуть в мусорную корзину, оставив чуток на память. MVP обычно делается по всем правилам "продуктивного" релиза
Возможно я как-то непонятно объяснил, поэтому приведу жизненный пример. Предположим в жестокой иерархической структуре, которая занимается товарно транспортными операциями нефти или газа, стартовал проект по созданию системы управления транспортными потоками на основе микросервисной архитектуры естественно. Для реализации проекта создана отдельная проектная структура, там архитектора, самоуправляемые команды, гибкие практики и все такое. Повезло и они правильно определили границы сервисов и вот одна команда разрабатывать и совершенствует сервис планирования загрузки трубы на основании откуда-то поступивших заявок, которые делает другая команда, и передает данные о порядке организаций партий продукта в какой-то другой микросервис. Вдруг, происходит сбои и в результате по какой то причине в трубе оказался избыток или недостаток углеводородов для поддержания технологического давления. Первыми как правило идут на плаху АСУТПшники и метрологи. Но выясняется, что там все ок. Приборы поверены, а в системе управления нет ошибок и все идет в плановом режиме. Вопросы к планово-диспетчерской службе, а те говорят - слушайте мы вот сюда что-то вбиваем, а там дальше микросервисы и вон в той agile структуре самоуправляемые команды какие-то. Я вас уверяю, после этого инцидента эта самоуправляемая команда будет ликвидирована, потому что иерархическая структура не умеет этим управлять. И будет создан большой такой монолитный сервис планировщик транспортных потоков, владельцем которого будет руководитель планово-диспетчерской службы, которому абсолютно плевать на архитектуру и не плевать на свое рабочее место. Конец истории.
Смотрите, давате разделять "культуру" управления и остальное
Я понимаю (хотя корни намного глубже), совдеповское прошгое оставило в наследство стиль, который можно охарактеризовать следующими принципами:
тащить и не пущать
я начальник - ты дурак
у ошибки всегда есть имя и фамилия и т.д.
Это да, есть - но такая реакция вызвана именно такой "культурой". Это конечно не значит, что на западе ее нет, но в целом ее проявления намного меньше.
Теперь о орг. структуре. Из личного опыта я могу привести две работающие модели:
Проект делает решение и отдает в консолидированную поддержку.
ИТ поддержка принимает решение как часть СВОЕГО ИТ-ландшафта и поддерживает. Прикол в том, что 3я линия поддержки - это микс из внутренних разработчиков/внешних вендоров. В описанном примере ИТ поддержка не сможет огульно обвинить "команду", так как ее УЖЕ НЕТ :) А дальше, есть риск получить ответку от равного по силе подразделения внутренней разработки, если косяк в части, которую делали они, либо вежливую, но часто более компетентную ответку от внешнего поставщика. Поэтому либо "разбираться" в сути, либо - играть в политику. Первое - ответ на ваш вопрос. Второе - нас уводит в область обсуждения культуры. И да, члены команды (я, как архитектор, к примеру), тоже могут быть сделаны козлом отпущения, точнее такая попытка будет совершена. А дальше, как показывает практика, пару публичных ответок - и желание безосновательно связываться пропадает. Политически же сила ПМО + внедрятелей в эффективном внедрении. Если ты обеспечиваешь развитие, то политически ИТ поддержка всегда на вторых ролях, но жаждет найти ошибку и тогда задвинуть по самые помидоры. Что стимулирует не лажать по крупному :) Очень стабильная конструкция, но надо иметь "зубы" и не бояться в ответ "бить", не глядя на погоны
Организация переходит к сервисному подходу и внутренним SLA. Это "следующий" (на самом деле он принципиально другой, пожтому и кавычки). Но тут все просто. Все обложились SLA и попытка "нападения" отражается сразу "на границе". Либо не отражается и команда идет получать заслуженный пистон
Я так понимаю, вам более интересен вариант 1. Он реален. Но ... надо понимать, что есть ПМО + его поддержка слабы и неэффективны - да, их будут бить и возмодно ногами. Это сложная работа, и многие не справляются. Поэтому рецепт не универсален, так как без кадров такой подход обречен. Но это касается почти любого подхода
про закон Конвея:
когда в организации есть отдельные подразделения
независимые, а то и имеющие разные кошельки
то они хотят иметь свою команду и свой сервис с блекджеком
даже если для компании в целом это не очень хорошо
тогда происходит распад приложения на сервисы, их команды, серверы, менеджеров, а иногда даже появляется распределенная географически система
Если этого нет, то не нужны вам сервисы - весь этот геморой
А в завершение статьи я предложу альтернативный и менее рискованный подходНу и где подход то? Начать с монолита? Америка открыта снова...
А можно начать сразу с архитектуры и определения бизнес модели, всё как следует описать и смоделировать большинство основных бизнес-процессов. Не писать код вообще, месяц другой. И ничто уже не помешает сделать микросервисы сразу.
А если команда маленькая - есть квантовые сервисы + чистая архитектура с инверсией зависимостей и разделение кодовой базы на слои, где слой технологий выпилить в библиотеки.
Основная идея квантового сервиса - одна кодовая база(один проект) - одна команда. Чистый монолит разлагать на докеры путём декомпозиции апи, то есть слоя интерфейса. При этом ядро бизнес модели лежит как кусок независимого от апи кода (и от СУБД если использовать чистую архитектуру, хотя на слоевую оверхеда меньше). На выходе получается целая пачка докеров с одного проекта. Каждый докер масштабируется горизонтально через балансировщик всё как в микросервисах. Но при этом внутри везде одинаковый код ядра. Код он много не весит его не жалко везде засунуть. А что это даёт ? Все плюсы микросервисов раз. Всё удобство монолита два. А ещё убирает оверхед на организацию общения между микросервисах. Потому что они все на борту уже содержат бизнес-модель всю. Вот - решение.
Вполне себе предложение, как я писал выше, монолит(так сказать все пошло от SOA) не обязан быть одним, просто чем больше сервис(система), тем больше он подходит под термин монолита, никто не мешает выделить на огромный кровавый энтерпрайс 5-6 монолитов, заставить их сообщаться и добавить пару "микро" сервиса, которые будут написаны native и иметь высокую скорость обработки запросов, по факту просто решать необходимые вопрос о производительности.
Вот эти приколы про декомпозицию монолита и те очень часто заводят в никуда. Однако, не могу не отметить, если у проекта монолит из 2000х и он на java, то да такое лучше было бы переписать на что то более современно, хотя бы исходя из того, что куча депрекейт кода связанного с безопасность. Вот если у вас стек монолита на интерпретируемом языке, обычно кодовая база в десятки раз меньше, чем на той же Java или .Net, потому всякие Github, Gitlab, Shopify не удалили и не переписали ядро монолита на такие классные микросервисы.
Хотя, можно и пойти по пути Озона - у них сотни микросервисов, но по рассказам все равно есть "фавортные" микросервисы которые можно с натяжкой назвать микро, ведь там куда больше бизнес логики, чем в других.
Так что статья, наверное, в первую очередь говорит о том, что дело не в том какой тулчейн у вас в проекте, а насколько правильно этим tool-ами пользуется команда и как хорошо ПОД них написали архитектуру.
Не обязательно дробить монолит на 100500 МИКРОсервисов. Можно "резать" его на более крупные куски. Например как это делает SAP. Есть модули FI, CO, PP и пр. Каждый модуль может разрабатываться, развертываться и апдейтиться независимо друг от друга.
Если проводить аналогию со стротельством дома: вместо микросервисов "кран на кухне", "освещение спальни", "входная дверь" можно использовать более крупные блоки "кухня", "спальня", "прихожая" и т.д.
Микросервисы победили. Или не совсем