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