на мой взгляд time2market напрямую связан со стоимстью внесения изменений. А эта стоимость очень сильно зависит от технического долга и скорости тестирования вносимых изменений. Вклад сложности разработки нового высок, но скорость отладки и скорость "приземления" нового зачастую существенно важнее, если речь не о rocket science и новых направлениях в медицине.

Как вообще кубер влияет на time2market? В общем флоу разработки от идеи до появления фичи в проде 99.9% занимают процессы до кубера. Какой смысл на этом участке концентрироваться, чтобы time2market уменьшить?

еще как влияет. Но не сам кубер, а любой инструмент который упрощает, ускоряет и унифицирует что-то на своем пути.

какую часть времени программист пишет код, а какую отлаживает? Без автотестирования и с отладкой целого монолита при любой правке второе время на порядок больше первого. И для снижения второй части растут все эти микросервисы, ci/cd, infrastructure as a code, для которых kubernetes стал отличным компромиссом.

Лол что
Ну конечно же для написания и выкладывания фичи нужно только написание кода, и никаких других издержек не существует

Мнение, что писать и отлаживать код в монолите сложнее и дольше, чем в микросервисной архитектуре, я не разделяю. Сложнее и дольше как раз в микросервисной. Если вы меняете контракты взамодействия между частями системы, не важно монолит это или микросервисы, то вам это все и отладить и протестировать все равно придется.

А вы не меняйте

Это так. Однако переход на все эти автотесты, ci/cd, iac, без которых не получится справиться с микросервисами, выводит зрелость процесса отладки на совершенно иной уровень. Сама по себе микросервисная архитектура не панацея и при неправильной архитектуре и готовке действительно внесение изменений в ней может превращаться в кошмар. Но может и не превращаться.

Так ci, cd и iac - это не из мира микросервисов.

Однако там без этого не справиться в принципе, спич про это. Так что внедрять придётся. Со всеми вытекающими

Если вы меняете контракты - стоит задуматься над исполнением своих обязанностей как сто

Мы в контексте уменьшения time2market рассматриваем кубер. Как он помогает эту метрику уменьшить?

а если вы не меняете, то внезапно вам для тестирование не надо разворачивать 100 микросервисов, чтобы прогнать интеграционное

тезис был, что кубер помогает уменьшить time2market, я спросил как

Мне лично приходит на ум только тестирование, где кубер (вероятно) помогает развернуть тестовые среды.
Профит только в этом или есть еще какие-то вещи, которые time2market уменьшают?

простите, но я дважды писал, что переход на кубер, iac и ci/cd могут помочь кардинально снизить стоимость отладки, что в свою очередь кратно снижает t2m. Понятно, что к SAP и 1C он неприменим, и таким образом не является серебряной пулей на все случаи жизни. Однако на web-стеке он даёт возможность приблизиться к этой самой пуле, насколько это возможно в сложившихся технологических и HR-условиях

А могут и не помочь и сделать дороже и кратно увеличить t2m.

ну тут уж как справитесь 🙂 "дай дураку стеклянный ..."

Т.е. есть команда дураков А, и t2m большой. Кубер им давать нельзя по определению, не поможет и может получится еще хуже. Тогда надо менять команду на Б, которые могут. Выходит t2m уменьшает не кубер, а внезапно люди. Кстати, они могут и без кубера часто это делать :)

Смотрите глубже: одних только умеющих людей недостаточно. Ушёл у вас такой умеющий и приплыли: никто и не знает чего он там воротил и как. И начинаете на каждое движение перезакладываться. А когда всё как код, то ничья память не нужна, достаточно научиться читать и грамотно развивать этот код. Что опять приводит к движению к правильным процессам поверх правильных людей поверх правильных технологий и далее по кругу.