redb 3.3.0: решение уровня энтерпрайз на .NET — своя БД, свой Apache Camel и рантайм с дашбордом (и всё это бесплатно)

[Granulex]

Зоопарк из разных вендоров энтерпрайз держит не из любви к боли, а потому что звери болеют по отдельности: слегла шина – база и рантайм живут дальше, и откатывать нужно один слой, а не три. "Синхронный бамп всей экосистемы" звучит красиво ровно до первой регрессии, когда ради исправления в шине придётся перевыпускать и хранилище. Клей, который чинишь по ночам, хотя бы чинится локально.

[grelikt]

Согласен с самим принципом: изоляция отказов реальна, и если бы обновление шины насильно тянуло за собой перевыпуск хранилища — это был бы антипаттерн. Но здесь смешаны две ортогональные вещи: изоляция в рантайме и связность версий на сборке.

В рантайме изоляция никуда не делась. Шина, БД и рантайм — по-прежнему отдельные процессы (и отдельные NuGet-пакеты). Регрессия в шине не роняет хранилище: откатываете один пакет/образ шины, база живёт дальше. Ровно ваш сценарий «слегла шина — база живёт» работает как есть, откат — один слой.

«Единый бамп» — это рекомендация, а не жёсткая связность. Пакеты версионируются независимо и совместимы по API внутри 3.x: redb.Route 3.3.0 спокойно едет с коннектором 3.2.x — просто без свежих фиксов конкурентности. То есть «чтобы починить шину, придётся перевыпускать хранилище» фактически не так — бампаете только тот пакет, который трогали. Единая линия версий нужна тем, кому удобно ехать всем стеком разом, а не обязаловка.

А главный плюс синхронного выпуска — он гоняется тестами комплексно. Вся линия 3.3.0 проходит сквозную матрицу: БД, шина, коннекторы, рантайм проверяются в связке, на одном прогоне. В зоопарке такого прогона нет в принципе — каждый вендор тестирует себя у себя, а стык между ними (та самая интеграция версий) не тестирует никто, кроме вас, в проде. Синхронный релиз ровно эту дыру и закрывает: совместимость слоёв — гарантия линии, а не ваша ночная проверка.

И про «клей, который чинишь по ночам». В зоопарке по ночам обычно чинится не вендорский компонент, а именно клей между ними — адаптеры, контракты сериализации, мосты транзакций. Это ваш код: без вендора, без тестов, без SemVer. Здесь этот клей — тестированные версионированные примитивы одной линии с общей CI-матрицей. Регрессию ловит один прогон по всему стеку, а не «а совместим ли драйвер vX с шиной vY».

И ещё про «болеют по отдельности». Так они и лечатся по отдельности — разным стеком, разными людьми. Kafka чинит один спец, Postgres — DBA, Redis — третий, шину — четвёртый. Изоляция отказов оплачивается фрагментацией экспертизы: держать надо не один навык, а зоопарк компетенций, и в 3 ночи нужный человек не всегда на смене. Единая экосистема — это один стек знаний на всё, и правит его один человек, а не эстафета из четырёх дежурных. ну и вся эта история открытый исходный код.

Где вы правы по-настоящему: реальный компромисс не в изоляции отказов (она сохранена), а в концентрации вендора. Один поставщик на весь стек — это единый источник и багов, и рисков (заброшенность, вектор supply chain). Это честная цена за отсутствие интеграционного клея и за один стек компетенций, и держать её в голове стоит. Но это уже другой аргумент, чем «синхронный бамп ломает откат».

но опят же открытый исходный код в век нейронок прошерстить не составляет труда.

[grelikt]

Дополню про концентрацию вендора — она тут слабее, чем кажется. Ядро, движок, коннекторы и рантайм открыты: заброшенность лечится форком, supply chain — аудитом (а в век LLM прошерстить всё дерево это вечер, а не неделя). Pro-слой закрыт бинарём, но, во-первых, раздаётся бесплатно и без лицензионного сервера на всей линии 3.x — «рубильника» у вендора нет; во-вторых, компаниям, которым нужен исходник, я отдаю его по запросу. Так что и тут это не lock-in, а обычный риск «поставщик может остановиться» — с открытым ядром и доступным по запросу Pro это не тупик, а форк.