кто-то вытащил эту идею и пропагандирует ее как нечто "революционно новое"
Это старая модель, он давно разработана и описана
Судя по тому, что вы написали, вы никогда не работали с микросервисами в проде. Тогда странно, что вы убираете десяток лет развития этой темы в IT и утверждаете, что это всё это было. Микросевирсов раньше в принципе не могло быть, потому что не было IaC. Только благодаря развитию этого направления создание архитектуры на микросервисах стало возможно.
Прежде, чем утверждать, что микросервисы – это пропаганда и хайп, рекомендую вам, как инженеру, изучить этот вопрос.
Я упомянул Power10 именно в этом ключе
Я уверен, что это отличная технология, но тут есть вопрос стоимости. Если я могу насоздавать сотни инстансов микросервиса за Х рублей и потерять при этом 10% на увеличении трафика, а на Power10 мне придется заплатить 10Х руб. и потерять только 1%, то это только вопрос бизнес-целей и возможностей. Я согласен, что можно растить вертикально, если для этого есть потребность бизнеса и средства.
я не могу себе представить реализацию enterprise монолита, где одновременно работают тысячи (если не десятки тысяч) достаточно независимых бизнес-процессов
Я с этим работаю ежедневно. Скажите, если я как-то могу вам помочь это представить.
при том, что enterprise давно уже так живет
А "так" это как? Вы про модель акторов, которые соединены шиной?
Спасибо за уточнения. Даже не думал, что описал все слишком радужно. Если у вас есть ссылки на статьи, которые рассказывают об ограничениях, то скиньте сюда. Уверен, что они будут полезны тем, кто изучает тему микросервисов.
А что если мы в компании уже много лет используем микросервисы и бизнес, благодаря этому получает гибкость и зарабатывает больше? Я понимаю, что есть разные люди и часть может просто взять "обертку" микросервисов и делать абы что, но это разве означает, что микросервисы всегда используются для хайпа? Для меня странно, что вы без разбора смыли всех любителей микросервисов выгребную яму.
Спасибо, что поделились опытом из своей области. У меня опыт в основном из ритейла, екома и логистики. Там микросервисы очень активно используются.
Вариант, который вы описали, очень похож на микросервисы. Не могу точно сказать дельту "по фотографии", то выглядит похоже.
для банка это не работает
Речь не именно про облака, а про то, что железо можно наращивать по мере роста нагрузки. Уверен, что у вас внутри банка такая штука должна быть тоже реализована. Плюс от микросервиса в том, что у него четкие границы, вроде ваших акторов. Если одни актор (а он небольшой, судя по описанию) будет перегружен, то только для него вы нарастите железо.
по масштабированию серверов в очень широких пределах
Это вопрос в деньгах. Чем больше и круче вертикально растим, тем дороже это стоит, причем дороже нелинейно. Дешевле купить кучу мелких машин, чем строить и обслуживать супер-крутой компьютер.
запуском каждого нового контейнере будет пропорционально падать производительность всех остальных
Тут связано с моим предыдущим комментарием. Вы смотрите на железо, как на что-то целостное, я смотрю на него, как на сервис. Другими словами, можно докупать дешевые мощности и наших плодить копии микросервисов.
О каких маркетологах речь? Я писал для тех, кто управляет созданием продукта в условиях неопределённости, то есть когда на входе невозможно сделать «четкое ТЗ». О маркетологах, вроде, ничего не писал.
Если вы закончили за 2 часа, то и получили оплату за два часа. В этом плане все делят риски поровну. Либо, за оставшееся время, вы можете еще что-то сделать, что не входило в первоначальный план.
Если он не успевает, то он как можно раньше должен об этом узнать, обсудить какую часть работы можно упростить, чтобы успеть.
А это «контр» к какой из метафор статьи? В них же речь идет о полноценном «прыжке», а не половинчатом. В конце маленького прыжка получаем ценность.
Если мы говорим о прыжках, то точнее будет сказать «нельзя перепрыгнуть гору за один прыжок, делай маленькие и смотри вокруг, чтобы понять куда дальше»
Если на велосипед и самокат смотреть, как на объекты реального мира, то метафора неточная. Если мы говорим про абстракции в IT-продукте, то там вполне одно может перетекать в другое.
Да, разные варианты для разных "состояний" проекта. Если в уже существующей системе надо добавить "кнопку", то нет смысла идти издалека. Надо просто добавить кнопку. С другой стороны, даже в устоявшемся бизнесе и в давно существующих системах надо сделать нечто, чего в них раньше не было. Тогда подходы с "самокатами" отлично применимы. Я бы за основу брал Cynefin framework, чтобы понимать, как лучше двигаться к решению.
Если взять метаформу физического мира, то это правда будет 4 разных продукта. В IT всё-таки код можно сильно проще переиспользовать и трансформировать.
Михаил, да, тут много разных нюансов. Я думаю, что по первой картинке можно написать (точнее уже написано) много разных книг. Я скорее хотел дать общее направление мысли, чтобы были варианты при планировании метода создания продукта.
Почти так, но иллюстрация подразумевает, что наработки переходят от стадии к стадии и переиспользуются. В реальном мире, конечно, это маловероятно, но в IT такое частенько происходит. Если смотреть на схему, как на работу в физическом мире, то было бы точнее назвать, как вы сказали — каждая следующая стадия это пивот
Отчасти да, но это же только метафора. Как я писал, не каждый клиент встанет на самокат и захочет крутить крутить педали велосипеда. Если вынашиваю такого клиента, то это удача. Он правда может обогнать других.
Если этот подход правда может помочь бизнесу, то почему бы об этом не написать?
Судя по тому, что вы написали, вы никогда не работали с микросервисами в проде. Тогда странно, что вы убираете десяток лет развития этой темы в IT и утверждаете, что это всё это было. Микросевирсов раньше в принципе не могло быть, потому что не было IaC. Только благодаря развитию этого направления создание архитектуры на микросервисах стало возможно.
Прежде, чем утверждать, что микросервисы – это пропаганда и хайп, рекомендую вам, как инженеру, изучить этот вопрос.
Я уверен, что это отличная технология, но тут есть вопрос стоимости. Если я могу насоздавать сотни инстансов микросервиса за Х рублей и потерять при этом 10% на увеличении трафика, а на Power10 мне придется заплатить 10Х руб. и потерять только 1%, то это только вопрос бизнес-целей и возможностей. Я согласен, что можно растить вертикально, если для этого есть потребность бизнеса и средства.
Я с этим работаю ежедневно. Скажите, если я как-то могу вам помочь это представить.
А "так" это как? Вы про модель акторов, которые соединены шиной?
Спасибо за уточнения. Даже не думал, что описал все слишком радужно. Если у вас есть ссылки на статьи, которые рассказывают об ограничениях, то скиньте сюда. Уверен, что они будут полезны тем, кто изучает тему микросервисов.
От себя могу добавить вот эту статью «От микросервисного монолита к оркестратору бизнес-сервисов» https://habr.com/ru/articles/496934/
А что если мы в компании уже много лет используем микросервисы и бизнес, благодаря этому получает гибкость и зарабатывает больше? Я понимаю, что есть разные люди и часть может просто взять "обертку" микросервисов и делать абы что, но это разве означает, что микросервисы всегда используются для хайпа? Для меня странно, что вы без разбора смыли всех любителей микросервисов выгребную яму.
Спасибо, что поделились опытом из своей области. У меня опыт в основном из ритейла, екома и логистики. Там микросервисы очень активно используются.
Вариант, который вы описали, очень похож на микросервисы. Не могу точно сказать дельту "по фотографии", то выглядит похоже.
Речь не именно про облака, а про то, что железо можно наращивать по мере роста нагрузки. Уверен, что у вас внутри банка такая штука должна быть тоже реализована. Плюс от микросервиса в том, что у него четкие границы, вроде ваших акторов. Если одни актор (а он небольшой, судя по описанию) будет перегружен, то только для него вы нарастите железо.
Это вопрос в деньгах. Чем больше и круче вертикально растим, тем дороже это стоит, причем дороже нелинейно. Дешевле купить кучу мелких машин, чем строить и обслуживать супер-крутой компьютер.
Тут связано с моим предыдущим комментарием. Вы смотрите на железо, как на что-то целостное, я смотрю на него, как на сервис. Другими словами, можно докупать дешевые мощности и наших плодить копии микросервисов.
О каких маркетологах речь? Я писал для тех, кто управляет созданием продукта в условиях неопределённости, то есть когда на входе невозможно сделать «четкое ТЗ». О маркетологах, вроде, ничего не писал.
Если вы закончили за 2 часа, то и получили оплату за два часа. В этом плане все делят риски поровну. Либо, за оставшееся время, вы можете еще что-то сделать, что не входило в первоначальный план.
Если он не успевает, то он как можно раньше должен об этом узнать, обсудить какую часть работы можно упростить, чтобы успеть.
Понял, спасибо за пояснение. Очень интересные мысли.
А это «контр» к какой из метафор статьи? В них же речь идет о полноценном «прыжке», а не половинчатом. В конце маленького прыжка получаем ценность.
Если мы говорим о прыжках, то точнее будет сказать «нельзя перепрыгнуть гору за один прыжок, делай маленькие и смотри вокруг, чтобы понять куда дальше»
Круто! Всё понял, кроме последнего. Можете, пожалуйста, расписать подробнее вот эту часть?
> самую (на мой взгляд) жестокую ошибку софтверной инженерии: смешение анализа и синтеза (исследований и разработки)
Если на велосипед и самокат смотреть, как на объекты реального мира, то метафора неточная. Если мы говорим про абстракции в IT-продукте, то там вполне одно может перетекать в другое.
Я согласен, что для убеждения надо использовать механизмы "продажи" идеи. А вот для синхронизации подхода к разработке уже подойдут эти картинки
Да, разные варианты для разных "состояний" проекта. Если в уже существующей системе надо добавить "кнопку", то нет смысла идти издалека. Надо просто добавить кнопку. С другой стороны, даже в устоявшемся бизнесе и в давно существующих системах надо сделать нечто, чего в них раньше не было. Тогда подходы с "самокатами" отлично применимы. Я бы за основу брал Cynefin framework, чтобы понимать, как лучше двигаться к решению.
Если взять метаформу физического мира, то это правда будет 4 разных продукта. В IT всё-таки код можно сильно проще переиспользовать и трансформировать.
У вас карма настоящего QA :) А вообще я писал статью в редакторе Хабра, так что, возможно, их визивик шалит.
Михаил, да, тут много разных нюансов. Я думаю, что по первой картинке можно написать (точнее уже написано) много разных книг. Я скорее хотел дать общее направление мысли, чтобы были варианты при планировании метода создания продукта.
Почти так, но иллюстрация подразумевает, что наработки переходят от стадии к стадии и переиспользуются. В реальном мире, конечно, это маловероятно, но в IT такое частенько происходит. Если смотреть на схему, как на работу в физическом мире, то было бы точнее назвать, как вы сказали — каждая следующая стадия это пивот
FFF и правда не про MVP. Мы по нему делаем довольно большие с ложные продукты, которые уже много лет как ушли от стадии MVP.
Отчасти да, но это же только метафора. Как я писал, не каждый клиент встанет на самокат и захочет крутить крутить педали велосипеда. Если вынашиваю такого клиента, то это удача. Он правда может обогнать других.
То есть все проблемы и решения подходят и для 1С?