существуют с 84-ого года

или 88-ого... хм... забыл,..

сага - не ответ, это название проблемы, а не решения. А решений там много, и оркестрацией и хореографией и все плохие

но я понимаю, почему при таком подходе нужны сотни и тысячи программистов для простых задач

ну смотря какие задачи считать простыми. В любом случае, на структуру организации количество деплой юнитов не сильно влияет. В том плане что раз уж ты решил дробить систему, скорее всего захочешь сделать так что бы каждая команда сама решала когда и чего ей деплоить. Как стратегия управления рисками и минимизация зависимостей организационных (иначе зачем тебе это все?). В этом случае нет разницы один деплой юнит на команду или 100 (лямбды).

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

еще как влияет, закон конвея же

>пусть сложность будет перетекать куда-то еще
где карту получали - туди и идите.

а ваще о каком уменьшении когнитивной нагрузки вообще может идти речь?

закон конвея то да, но ты команды выстраиваешь так что бы принятие решений и коммуникации были так как тебе надо. А то что внутри команды у них пара десятков лямбд - какая разница если "наружу" есть четкий контракт?

основная идея обычно в фокусе внимания. Перетекание сложности нужно что бы команды которые думы думают над тем как пользователям хорошо было не отвлекались на вопросы платформы. Тебе вот челики из команд которые платформу делают сказали "просто запусти скриптик этот и все будет хорошо" и все. Ты как решатель бизнес задач не хочешь голову себе забивать какими-то тупыми штуками типа регулярные секрьюрити сканинги и апдейты. Ты хочешь депендабота и автотесты.

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

а кто тебе говорит о разных схемах деплоя? наоборот же

Ох, к какому ужасу такой подход обычно приводит.  А хоть один удачный пример есть?

лямбды и сервисы - это разный деплой, очень разный.

в этом же смысл - ты выделяешь все эти вещи в отдельное направление (platform teams в teams topology) именно для унификации всех этих вещей и что бы хипстеры продолжали пить смузи

чето кажется, что создали проблемы, а потомы еще платформенные команды для их решения?

разный, в основном потому что для сервисов оно все прописано сильно лучше. Но тебе никто не мешает организовать "чет похожее" для сервисов

тоже самое хорошо и с монолитами работает. В том плане что какое-то понятие платформы есть. Скажем хочешь ты в компании сделать DSM и uikit какой. Как ты будешь этим делом управлять? Какая команда будет этим заниматься? Будешь ли ты делать новую команду чисто под это дело или будешь пытаться организовать процесс в рамках которого надо согласовывать когда кто чем занимается и кто что может трогать?

пример специально беру не связанный с деплоями и инфраструктурой (хотя в чем-то похоже). Сделать сходу крутой uikit который экономит время не выйдет. всех кейсов ты не знаешь. И тебе надо что бы кто-то парился о dev expirience

ну, проще выгнать хипстеров и просто сделать нормально. Чистые platform teams скорее антипаттерн (по крайней мере всюду, где это было - оно приводило к плохим платформам и потере компетенций в продуктовых командах)

мы недавно вот с проблемой сталкнулись - accessibility. Вроде простая штука, но надо как-то заставить 10 команд начать это дело внедрять и включать в definition of done. Как ты будешь это организовывать?