Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Все что тут написано — бесполезно без SAGA. Все вот эти «легкочитаемые» схемы должны иметь обязательные откаты с каждой точки. А бизнес это рисовать не желает, очень сложный и лишний процесс с их точки зрения. И мусорные транзакции висят, висят и висят. Мелочи, да.
Обычно бизнес это и не рисует, а это разрабатывается кодом и деплоится так же как и всё остальное, но визуально, наглядно. Действительно, бизнес может что-то поменять, но на крупных проектах все их модификации пройдут «код-ревью» и весь деплой как обычно.
За контракты и общий контекст ответственна BPMS. Откаты там где необходимо конечно нужно рисовать, мы накидали тестовый бизнес-процесс для рассказа возможностей и общего понимания того, как можно оркестрировать микросервисы — это была цель статьи.
За контракты и общий контекст ответственна BPMS. Откаты там где необходимо конечно нужно рисовать, мы накидали тестовый бизнес-процесс для рассказа возможностей и общего понимания того, как можно оркестрировать микросервисы — это была цель статьи.
Скажите, Camunda ведь поддерживает SAGA функционал полностью? Просто на ваших примерах не было compensatable transactions, но их можно легко добавить, верно? И на сколько можно пользоваться бесплатной версией на практике, имею ввиду?
Конечно поддерживает, Camunda — одно из самых совершенных BPMS на сегодняшний момент. У нас не на всех примерах ест события и транзакции просто потому, что хочется показать сам принцип.
По поводу бесплатной версии — да, можно пользоваться бесплатной версией. Много чего не будет, но вот мы знаем что ребята из Тинькофф пишут собственные средства которые дополняют функционал и являются опенсорс (excamad например). Если вы — очень крупное предприятие, вы можете использовать бесплатную версию Camunda и написать что нужно самостоятельно.
Если вам нужны все функции Camunda Enterprise но вы не очень крупная организация (как правило вопрос не денег а внутренних политик по лицензиям), попробуйте jBPM — он «всего» раз в 5 медленнее, что для многих случаев не столь критично (т.к. сама скорость бизнес-процесса может сильнее зависить от скорости микросервисов и потери BPMS на этом фоне не очень существенны).
По поводу бесплатной версии — да, можно пользоваться бесплатной версией. Много чего не будет, но вот мы знаем что ребята из Тинькофф пишут собственные средства которые дополняют функционал и являются опенсорс (excamad например). Если вы — очень крупное предприятие, вы можете использовать бесплатную версию Camunda и написать что нужно самостоятельно.
Если вам нужны все функции Camunda Enterprise но вы не очень крупная организация (как правило вопрос не денег а внутренних политик по лицензиям), попробуйте jBPM — он «всего» раз в 5 медленнее, что для многих случаев не столь критично (т.к. сама скорость бизнес-процесса может сильнее зависить от скорости микросервисов и потери BPMS на этом фоне не очень существенны).
Если вам нужны все функции Camunda Enterprise но вы не очень крупная организация (как правило вопрос не денег а внутренних политик по лицензиям), попробуйте jBPM — он «всего» раз в 5 медленнее, что для многих случаев не столь критично (т.к. сама скорость бизнес-процесса может сильнее зависить от скорости микросервисов и потери BPMS на этом фоне не очень существенны).
Я правильно понимаю, что jBPM больше подходит для ситуаций, где нет большой собственной команды программистов?
ну это относительно. Есть если у вас есть микросервисы и оркестратор, значит это уже само по себе предполагает что у вас большое количество функционала, а организация и компетенция команды такая, что компания и команда понимает процессное управление, что само по себе делает требования к софту более сложным, внимание к it более пристальным и как следствие, больше задач на поддержку.
jBPM дешевле в сопровождении и да, что-то там может поддерживаться не разработчиками. У Camunda более строгое отношение к бизнес-процессам (поощряется все проводить через деплой). Чувствую, нужно написать разбор jBPM vs Camunda, мы это сделаем.
jBPM дешевле в сопровождении и да, что-то там может поддерживаться не разработчиками. У Camunda более строгое отношение к бизнес-процессам (поощряется все проводить через деплой). Чувствую, нужно написать разбор jBPM vs Camunda, мы это сделаем.
Camunda уже написали сравнение:
camunda.com/learn/whitepapers/camunda-bpm-vs-jboss
И первый пункт сравнения:
Мне и интересно — насколько это близко к реальности?
camunda.com/learn/whitepapers/camunda-bpm-vs-jboss
И первый пункт сравнения:
Camunda BPM 7 strategically aims for ‘Developer-Friendliness’, whilst JBoss jBPM 6 strives for the ‘Zero-Code-BPM’-ideal.
Мне и интересно — насколько это близко к реальности?
Здравствуйте, вы обещали написать разбор jBPM vs Camunda. Очень хотелось бы почитать )
В BPMS проектах не может быть мало разработчиков потому что проекты крупные.
Нам кажется, что jBPM может применяться на меньших по размеру проектах ввиду того что он обеспечит больше скорости изменений процессов внутри.
Кроме того, не забывайте, Camunda бесплатная с очень урезанным функционалом. В jBPM можете начать без лицензий.
Нам кажется, что jBPM может применяться на меньших по размеру проектах ввиду того что он обеспечит больше скорости изменений процессов внутри.
Кроме того, не забывайте, Camunda бесплатная с очень урезанным функционалом. В jBPM можете начать без лицензий.
Откаты доменноспецифичных вещей делаются из кода что ли? Как тогда это соотносится с заявлениями про гибкость в конце статьи? Ну и рисовать оркестратор без откатов с каждого шага — это классический пример продажников, которые показывают только позитиные стороны продукта. Ибо получится страшненький паучок на схеме, не продать. Проблема только в том, что клиент в итоге и получит паучок.
Важно то, что клиент получит на схеме именно тот бизнес-процесс, который работает у него.
Откаты операции — это ещё один блок на действие.
Да, схема будет сложнее (если не обеспечивать согласовательный уровень, что возможно), но мы и не предполагаем что BPMS будет использоваться на схемах из трёх блоков — тут важнее визибилити и принцип гарантированной независимости и унификации общения между микросервисами.
Микросервисный подход хорош для крупных проектов, а его удобно оркестрировать BPMS. Вот основная ценность для бизнеса. Бизнес не питает иллюзий что их процессы из 10 блоков (хотя если реально нужно «в 10 блоков», то это можно сделать, обеспечив схему сначала на согласовательном уровне — на верхнем уровне будет очень просто, но каждый блок будет в свою очередь более сложным и т.п.)
Откаты операции — это ещё один блок на действие.
Да, схема будет сложнее (если не обеспечивать согласовательный уровень, что возможно), но мы и не предполагаем что BPMS будет использоваться на схемах из трёх блоков — тут важнее визибилити и принцип гарантированной независимости и унификации общения между микросервисами.
Микросервисный подход хорош для крупных проектов, а его удобно оркестрировать BPMS. Вот основная ценность для бизнеса. Бизнес не питает иллюзий что их процессы из 10 блоков (хотя если реально нужно «в 10 блоков», то это можно сделать, обеспечив схему сначала на согласовательном уровне — на верхнем уровне будет очень просто, но каждый блок будет в свою очередь более сложным и т.п.)
Если для доработки склада надо перепилить 5 модулей, то после перехода на микросервисы надо допилить 5 микросервисов. Если рисование в нотации BPML позволяет ограничить границы микросервиса и менять только один, то такая же схема в ТЗ к монолиту позволит менять только один модуль
Пока монолит небольшой, это не проблема. Со временем, монолит раздувается. Встаёт вопрос рефакторинга. В крупных системах с кучей кастомной логики (ещё на базе какой-нибудь коробки — например Magento) обновления ядра — проблема (ведь нужно отрефакторить все модули с учетом того что добавлено в ядро вендором).
Еще одна проблема монолита — TDD, который значительно более трудоёмкий (а иногда даже настолько трудоёмкий что бессмысленный). А чем больше функционала, тем больше вероятность регрессии.
Речь же не идёт о маленьких проектах — у нашей компании в портфеле таких почти нет.
BPMN позволяет видеть бизнесу то, как проходит бизнес-процесс. Многие сложные операции (вроде таймеров, транзакций) в коде вообще сложно реализуемыми. В BPMN читаемость и легкость добавления транзакций, таймеров, прерываний такова, что на крупных проектах это сильно выручает.
Еще одна проблема без BPMN — бизнес хочет увидеть документацию по бизнес-процессу. Допустим даже она есть, но может быть что-то пропущено, а что-то забыто, а что-то неясно. В BPMN2.0 это менее вероятно, и когда меняются люди (что в крупных компаниях тоже случается), у бизнеса сохраняется уверенность в том, что понимание бизнес-процессов не ушло вместе с конкретным человеком.
Еще одна проблема монолита — TDD, который значительно более трудоёмкий (а иногда даже настолько трудоёмкий что бессмысленный). А чем больше функционала, тем больше вероятность регрессии.
Речь же не идёт о маленьких проектах — у нашей компании в портфеле таких почти нет.
BPMN позволяет видеть бизнесу то, как проходит бизнес-процесс. Многие сложные операции (вроде таймеров, транзакций) в коде вообще сложно реализуемыми. В BPMN читаемость и легкость добавления транзакций, таймеров, прерываний такова, что на крупных проектах это сильно выручает.
Еще одна проблема без BPMN — бизнес хочет увидеть документацию по бизнес-процессу. Допустим даже она есть, но может быть что-то пропущено, а что-то забыто, а что-то неясно. В BPMN2.0 это менее вероятно, и когда меняются люди (что в крупных компаниях тоже случается), у бизнеса сохраняется уверенность в том, что понимание бизнес-процессов не ушло вместе с конкретным человеком.
Если мы сделаем Pakage вместо микросервиса, то толпа пакаджей сравняется с толпой микросервисов просто один в один. Нужно только кросспакаджные вызовы контролировать. Ну собственно это видимостью делается.
Если мы говорим о использовании покупного ядра — то поддержка обновления кастомизированной группы микросервисов кажется не должна быть радикально проще поддержки кастомизированного монолита.
Если покупное монолитное ядро — куча спагетти, то это ужас в поддержке кастома, но кажется это проблема из другой плоскости.
Если мы говорим о использовании покупного ядра — то поддержка обновления кастомизированной группы микросервисов кажется не должна быть радикально проще поддержки кастомизированного монолита.
Если покупное монолитное ядро — куча спагетти, то это ужас в поддержке кастома, но кажется это проблема из другой плоскости.
История замкнулась, возвращаемся к оркестрации и SOA, вовсю нахваливаем, как это хорошо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микросервисы или модульные системы? Как заказчику выбрать подход к IT-архитектуре продукта