Экономика микросервисного хайпа: как архитектура съедает 40% вашего IT-бюджета

[ohrenet]

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

[MrTheFirst]

И мечты бьются о суровую выборку... Рынок так долго премировал за знание «модно-молодёжных» технологий, что найти того, кто понимает, почему один JOIN лучше десяти сетевых вызовов, сегодня труднее, чем архитектора с сертификатом AWS.

[akod67]

У микросервисов может появиться второй шанс, так как ЛЛМам проще с мелким контекстом. Но это не точно.

[MrTheFirst]

Да, написать изолированный кусок кода для одной функции — это сейчас идеальная задача для любой LLM.

Но тут есть пара нюансов:

1. Проблема микросервисов никогда не была в написании кода одного сервиса. Главная боль — это распределенные транзакции, разрыв сети, консистентность данных и распределенный трейсинг. LLM еще очень плохо понимают архитектуру всей системы целиком и то, как эти 50 «идеально написанных» кусочков будут общаться между собой в проде под нагрузкой.

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

3. Учитывая, что у новых моделей окна контекста уже пробивают 1-2 миллиона токенов, ограничение «маленького контекста» — это временно (хочется в это верить). Скоро скормить LLM-ке хорошо структурированный модульный монолит будет даже выгоднее: она будет видеть всю предметную область разом, а не пытаться угадать контракты соседнего сервиса.

Так что, с точки зрения написания — да, проще. А вот с точки зрения поддержки всей инфраструктуры — LLM могут этот «налог на микросервисы» только увеличить, генерируя их десятками там, где хватило бы одного модуля.

[akod67]

Думаю для мониторинга состояния архитектуры всё что требуется от “архитектурного видения” - это чёткое описание data flow и прочих флоу, а уж логи LLMы по tracking id копают на много лучше кожанных. Т.е. опять же, инструментарий стал лучше и он может порешать некоторые проблемы, с которыми людьми не справлялись. А окна в миллион не решают проблему галлюцинаций при распухшем контексте, наоборот, только делают эти проблемы более вероятными, так как перестаёшь следить за контекстом, не напарываясь на компрессию.

[Cringeon]

So far наблюдается обратное: пока весь код в одной репе и иишка может найти все нужные референсы условно в "1 grep" - она с задачами справляется на ура, а если ей при этом надо помнить про какие-то внешние связи или констрейнты, то начинает что-то придумывать поверх каждый раз

[Dhwtj]

Несколько я в курсе, до сих пор использует микросервисы массово Озон. Они сели на них и слезать не собираются. И там они не для производительности и не чтобы устранить противоречия команд. Они чтобы быстрее писались маркетинговые свистоперделки (рейтинги, рекомендации, аналитика …), которые если лягут или будут отдавать устаревшие данные то и фиг с ними. Главное, чтобы основой процесс не положили. Не будем их переубеждать, им норм.

PS Маркетинг любит микросервисы. Где микросервисы там почти всегда это маркетинг

[JustMoose]

Хм. Никогда не был бекендером, скорее пробовал туда вкатиться... У нас был Docker. Чтобы в нём было удобно собирать какой-то кусок кода для бекенда. Маленький кусок плюсового кода. Но есть один нюанс: я много лет ковырял другой (правда, десктопный) крупный проект (гигабайты плюсового кода), который без проблем собирался одним bat файлом. Мне кажется, overengineering всё ещё слишком популярен :(((

[akod67]

ну CI и докеризация нынче - это база, а не overengineering. Даже странно будет, если придётся объяснять, для чего это нужно.

[JustMoose]

Там чуть выше есть целая статья про то, что нужно это не всегда :)

[akod67]

Это нужно всегда хотя бы с точки зрения гигиены.

[JustMoose]

О какой вообще гигиене может идти речь, когда фигачишь самодельный софт на специально купленной для этого тачке?