Текст какой-то мне показался самбурный, как будто вырвали из середины,мы ведь не кино смотрим. Хотелось бы с самого начала без погружения в дебри, желательно перед выпуском выводить bash -x .sh ))
Согласен, наиболее показательный был бы сквозной тест end-to-end - он выявляет узкие места в реальном сценарии. Времени и желания доказывать нет. Вопрос по существу понятен
Во-первых, можно стать тем самым универсальным продуктовым разработчиком и попытаться выиграть в этих голодных играх. Брать задачу от начала до конца, работать на разных стеках, использовать нейросети, быстро разбираться в незнакомом коде и закрывать то, что раньше делала небольшая команда. Таких людей компаниям тоже, судя по всему, будет требоваться все меньше.
Второй путь кажется мне более перспективным. Это стать человеком, который строит внутри компании весь AI-пайплайн. Внедрять процессы, в которых значительная часть работы выполняется автоматически. Например, делать автоматизацию, где баг заводится, исправляется, а в конце как раз остается один апрув от того самого выжившего продуктового разработчика.
Из первого легко попасть во второй, не вижу каких-то барьеров. То, что вы пилите свой «велосипед» — здорово. Главное, чтобы он был востребован, а для этого нужно приложить много усилий.
Рынок сейчас тяжёлый, но год — это довольно много для поиска. Иногда стоит убавить аппетиты или пересмотреть в целом свои подходы, возможно — кардинально сменить сферу. Увы, везде сейчас требуют огромный опыт и чтобы ты умел всё и сразу. Знаю примеры, когда люди из IT уходили в стройку (но опять же, по знакомству).
Не всегда стремление только лишь заработать приводит к успеху. Иногда достаточно показать миру, что не всё измеряется деньгами — отличный тому пример VLC Media Player.
С вами приятно общаться. Как бы мы ни хотели, Postgres всё же медлительный. У него есть свои минусы с мертвыми данными, которые приходится чистить либо на автомате (когда система позволяет сделать это без блокировок, например, со стороны каких-нибудь отчетов), либо вручную, запуская вакуумирование или реиндексацию. Сценарий “кривых рук”, как вы написали. Я с таким сталкивался: архитектору или администратору БД проще закрывать на это глаза — не они же тратят по несколько часов в неделю на ручную рутину. Впрочем, это касается и других сфер ИТ. Цифровой век требует беспрецедентной скорости, мощности и современности. Для этого необходимы принципиально другие инструменты, способные работать молниеносно. Такие механизмы уже существуют, и сегодня проще внедрить новое технологическое решение с нуля, чем пытаться переделать устаревающее. Возвращаясь к Kafka: она останется актуальной и сегодня, и завтра. Пока нет смысла её убирать (разве что в вашей схеме) — со своими задачами она справляется лучше всех. p.s. без примеров ИИ
Справедливо, «предел универсальности» благодаря железу и расширениям действительно отодвинулся, и для условных 80% средних проектов Postgres сегодня — это отличная «серебряная пуля».
Но когда проект и организация растут, монополия Pg начинает мешать не потому, что он «не тянет» железно, а из-за смешения контекстов и нагрузок на уровне движка. Дьявол кроется в двух плоскостях: эксплуатационной и архитектурной.
1. Эксплуатационные боли (Day-2 Operations):
Проблемы с MVCC и VACUUM: Использование Pg в качестве очереди/WAL-брокера порождает колоссальный объем UPDATE и DELETE. Автовакуум часто не успевает за очисткой мертвых строк (dead tuples), что приводит к раздуванию (bloat) таблиц, индексов и деградации дискового IO.
Конкуренция за Shared Buffers: Когда в одной БД живут OLTP, аналитика и Vector DB, они вымывают кэш друг друга. Один тяжелый запрос или построение векторного индекса (HNSW) гарантированно выкинут «горячие» транзакционные данные из shared_buffers.
Раздувание Blast Radius: Если из-за утечки памяти в условном расширении или кривого json-индекса упадет инстанс Pg, то «приляжет» вообще всё — и кор-транзакции, и очереди, и витрины. Специализированные решения изолируют эти риски.
Обслуживание: Делать бэкапы, репликацию и накатывать миграции на терабайтную «свалку всего» кратно сложнее, чем администрировать изолированные легковесные сервисы.
2. Архитектурные ограничения:
Размытие контрактов и связанность (Tight Coupling): Кафка ценна не пропускной способностью, а тем, что она выступает в роли изолирующего слоя (Decoupled Layer) со своей экосистемой (Schema Registry). Чтение WAL напрямую или через Debezium завязывает другие команды на внутреннюю структуру ваших таблиц. Изменили схему ради оптимизации своего сервиса — сломали контракты потребителям.
Проблема распределенного состояния (In-Memory кэш): Идея заменить Redis синхронизированным кэшем внутри приложения за счет репликации хорошо звучит только для монолита. В микросервисах это масштабируется плохо: мы либо дублируем гигабайты кэша в памяти каждого пода, либо вынуждены городить свою распределенную систему инвалидации, заново изобретая Redis, но сбоку.
Утилизация соединений (Connection Pooling): Архитектура Postgres «один клиент = один процесс» делает его крайне чувствительным к количеству соединений. Когда десятки микросервисов идут в одну БД за кэшем, очередями и транзакцииями, менеджмент сессий начинает отъедать слишком много ресурсов.
Так что тут вопрос скорее не в том, может ли Postgres выполнять все эти функции (может, и делает это круто), а в том, какую цену команда платит за эту универсальность на долгой дистанции.
Статья наглядно показывает, что Postgres сейчас пытаются закрыть вообще все дыры — и хранилище, и транзакции, и очереди через WAL. Но у такой универсальности есть предел. Рано или поздно Postgres придется подвинуться, уступая специализированным распределенным решениям, а останутся связки под конкретные задачи.
Как по мне, баланс сил в будущем будет выглядеть примерно так:
Apache Kafka: Никуда не уйдет. Она нужна не как очередь для одного сервиса, а как сквозная шина для интеграции десятков независимых команд.
Redis / Valkey: Сверхбыстрый In-Memory кеш, когда дисковая БД (даже Postgres) начинает захлебываться на чтении.
Apache Ignite: Распределенная In-Memory БД для тяжелых вычислений «на лету» над большими данными.
NewSQL (CockroachDB, TiDB): Замена классическому Postgres, когда проект вырастает из одного сервера и упирается в шардирование.
Vector DB (Qdrant, Milvus): Специфичная ниша для ИИ и работы с эмбеддингами.
Так что Кафка останется на своем месте (в enterprise-интеграции), а вот монополия Postgres точно пошатнется в пользу распределенной памяти (Ignite/Redis) и NewSQL.
Из-за оверквалифай-требований на собесах стресс такой, что начинаешь заваливать даже элементарную базу. Физическая нагрузка помогает «пересобрать» голову перед созвоном, но проблема глубже. В 2026 году собеседования окончательно превратились в оторванный от реальности экзамен. Ты можешь идеально ответить по всем чек-листам, но это вообще ничего не гарантирует — дальше просто не зовут.
Отличный материал, который приземляет тему ИИ с небес на землю. Полностью согласен с тезисом о сложности интеграции. Сейчас на рынке затихает первый хайп, когда все радовались простым чат-ботам, и начинается суровая реальность.
Одно дело — крутить LLM в изолированной «песочнице», и совсем другое — превратить её в автономного агента, встроив в реальный production. Мало написать промпты, нужно связать модель с кучей legacy-сервисов, настроить логику и обработку ошибок, когда ИИ начинает «галлюцинировать». В итоге на поддержку и оркестрацию этого агента уходит едва ли не больше ресурсов, чем на классическую автоматизацию.
Ну и вопрос ИБ здесь встает в полный рост. Давать агенту доступ к внутренним базам данных, корпоративному коду или, тем более, право совершать действия в системе (например, деплоить или менять настройки) — это пока огромный риск. Изолировать контекст, защитить модель от prompt injection и гарантировать, что ИИ случайно не «слил» или не удалил лишнего, сейчас невероятно сложно. Пока эти две проблемы — контролируемая интеграция и безопасность — не будут решены на уровне стандартов, ИИ-агенты так и останутся дорогими игрушками для локальных задач.
Примите мои искренние соболезнования в связи с потерей отца. Родители и семья — это самые близкие и дорогие нам люди.
Ваша история во многом отозвалась во мне. Я, как и вы, получил права в 2016 году. Водить я умел и раньше: у моего отца была легендарная Toyota Crown 1985 года выпуска, которая на ходу до сих пор. На ней я и учился ездить по деревенскому бездорожью, где асфальт был большой редкостью. Сразу после получения прав я сел за руль дедовского УАЗа. Это было мое главное разочарование в отечественном автопроме, хотя проходимость и два топливных бака, конечно, впечатляли.
В автошколе я очень ответственно подошел к теории: не пропускал занятия, ведь понимал, что это нужно мне самому. Нам повезло с преподавателем — опытным автовладельцем, у которого были даже японские права (а получить их невероятно сложно). Он делился бесценным житейским опытом: от простых лайфхаков (например, как по стрелке на приборной панели понять, с какой стороны лючок бензобака) до разбора аварийных ситуаций, нюансов обслуживания и дорожных приключений. Практику я откатывал на механике hyundai хэтчбек 2013 каждый вечер после работы. Как ни странно, самым сложным оказалось ездить именно с инструктором, а вот экзамен в ГИБДД я сдал легко и с первого раза.
Были и тонкости, о которых не предупреждали заранее. Например, новые на тот момент правила парковки на автобусных остановках. Помня об этом, я до сих пор злюсь, когда вижу «мастеров» вождения, бросающих машины прямо в начале кармана для автобусов. Про не включенные поворотники я вообще молчу. В прошлом году во время автопутешествия по Золотому кольцу России я лишний раз убедился, что таких чудаков везде хватает. Чего стоил один только «Крузак», который сразу за Ростовом Великим пошел на обгон прямо по обочине.
Прошло уже 10 лет. За это время я сменил машину, обновил права и накопил огромный ежедневный опыт. Я успел поездить по самым разным уголкам страны — от Горного Алтая до Сахалина, Находки и Владивостока, но до сих пор помню, с чего всё начиналось.
Поздравляю с открытием Grafana! Статья — классический пример того, как мы, инженеры, героически изобретаем велосипед с квадратными колесами (ООП-горшками), прежде чем просто изучить стандартный индустриальный стек. Рассуждения про ООП в контексте интерфейса горшков улыбнули.
Это штатная фича, где можно загрузить фото вашего балкона (или схему квартиры) в качестве подложки, расставить поверх интерактивные элементы и привязать к ним живые метрики. А в свежих версиях кнопки на Canvas умеют еще и API-запросы слать (GET/POST) — то есть прямо оттуда можно было бы и помпу полива включать, не городя свой лагающий фронтенд.
Но за docker-compose и симуляцию датчика на Python спасибо, для Песочницы — отличный старт!
Добиться "экрана смерти"в Windows 2000 было безумно сложно, но наш информатик умел «ронять» систему быстрее. Стоило нам увлечься сетевым матчем в Quake III
и проигнорировать звонок, как учитель одним движением руки гасил автомат в щитке. Спорить было бесполезно — мы молча слушали лекцию. Чуть позже началось освоение Turbo Basic,
Тот случай, когда оверинжиниринг победил здравый смысл. Вместо написания ТЗ для нейросети, съемок и генерации HTML-кода, можно было использовать старый добрый метод «натаскайся мебели до боли в спине». И фитнес, и пространственное воображение прокачивается на лету. Мозг начинает идеально высчитывать сантиметры до розетки сразу после того, как вы в третий раз перетащите комод не туда.
Текст какой-то мне показался самбурный, как будто вырвали из середины,мы ведь не кино смотрим. Хотелось бы с самого начала без погружения в дебри, желательно перед выпуском выводить bash -x .sh ))
Согласен, наиболее показательный был бы сквозной тест end-to-end - он выявляет узкие места в реальном сценарии. Времени и желания доказывать нет. Вопрос по существу понятен
Из первого легко попасть во второй, не вижу каких-то барьеров.
То, что вы пилите свой «велосипед» — здорово. Главное, чтобы он был востребован, а для этого нужно приложить много усилий.
Рынок сейчас тяжёлый, но год — это довольно много для поиска. Иногда стоит убавить аппетиты или пересмотреть в целом свои подходы, возможно — кардинально сменить сферу. Увы, везде сейчас требуют огромный опыт и чтобы ты умел всё и сразу. Знаю примеры, когда люди из IT уходили в стройку (но опять же, по знакомству).
Не всегда стремление только лишь заработать приводит к успеху. Иногда достаточно показать миру, что не всё измеряется деньгами — отличный тому пример VLC Media Player.
С вами приятно общаться. Как бы мы ни хотели, Postgres всё же медлительный. У него есть свои минусы с мертвыми данными, которые приходится чистить либо на автомате (когда система позволяет сделать это без блокировок, например, со стороны каких-нибудь отчетов), либо вручную, запуская вакуумирование или реиндексацию. Сценарий “кривых рук”, как вы написали. Я с таким сталкивался: архитектору или администратору БД проще закрывать на это глаза — не они же тратят по несколько часов в неделю на ручную рутину. Впрочем, это касается и других сфер ИТ. Цифровой век требует беспрецедентной скорости, мощности и современности. Для этого необходимы принципиально другие инструменты, способные работать молниеносно. Такие механизмы уже существуют, и сегодня проще внедрить новое технологическое решение с нуля, чем пытаться переделать устаревающее.
Возвращаясь к Kafka: она останется актуальной и сегодня, и завтра. Пока нет смысла её убирать (разве что в вашей схеме) — со своими задачами она справляется лучше всех.
p.s. без примеров ИИ
Справедливо, «предел универсальности» благодаря железу и расширениям действительно отодвинулся, и для условных 80% средних проектов Postgres сегодня — это отличная «серебряная пуля».
Но когда проект и организация растут, монополия Pg начинает мешать не потому, что он «не тянет» железно, а из-за смешения контекстов и нагрузок на уровне движка. Дьявол кроется в двух плоскостях: эксплуатационной и архитектурной.
1. Эксплуатационные боли (Day-2 Operations):
Проблемы с MVCC и VACUUM: Использование Pg в качестве очереди/WAL-брокера порождает колоссальный объем
UPDATEиDELETE. Автовакуум часто не успевает за очисткой мертвых строк (dead tuples), что приводит к раздуванию (bloat) таблиц, индексов и деградации дискового IO.Конкуренция за Shared Buffers: Когда в одной БД живут OLTP, аналитика и Vector DB, они вымывают кэш друг друга. Один тяжелый запрос или построение векторного индекса (HNSW) гарантированно выкинут «горячие» транзакционные данные из
shared_buffers.Раздувание Blast Radius: Если из-за утечки памяти в условном расширении или кривого json-индекса упадет инстанс Pg, то «приляжет» вообще всё — и кор-транзакции, и очереди, и витрины. Специализированные решения изолируют эти риски.
Обслуживание: Делать бэкапы, репликацию и накатывать миграции на терабайтную «свалку всего» кратно сложнее, чем администрировать изолированные легковесные сервисы.
2. Архитектурные ограничения:
Размытие контрактов и связанность (Tight Coupling): Кафка ценна не пропускной способностью, а тем, что она выступает в роли изолирующего слоя (Decoupled Layer) со своей экосистемой (Schema Registry). Чтение WAL напрямую или через Debezium завязывает другие команды на внутреннюю структуру ваших таблиц. Изменили схему ради оптимизации своего сервиса — сломали контракты потребителям.
Проблема распределенного состояния (In-Memory кэш): Идея заменить Redis синхронизированным кэшем внутри приложения за счет репликации хорошо звучит только для монолита. В микросервисах это масштабируется плохо: мы либо дублируем гигабайты кэша в памяти каждого пода, либо вынуждены городить свою распределенную систему инвалидации, заново изобретая Redis, но сбоку.
Утилизация соединений (Connection Pooling): Архитектура Postgres «один клиент = один процесс» делает его крайне чувствительным к количеству соединений. Когда десятки микросервисов идут в одну БД за кэшем, очередями и транзакцииями, менеджмент сессий начинает отъедать слишком много ресурсов.
Так что тут вопрос скорее не в том, может ли Postgres выполнять все эти функции (может, и делает это круто), а в том, какую цену команда платит за эту универсальность на долгой дистанции.
Статья наглядно показывает, что Postgres сейчас пытаются закрыть вообще все дыры — и хранилище, и транзакции, и очереди через WAL. Но у такой универсальности есть предел. Рано или поздно Postgres придется подвинуться, уступая специализированным распределенным решениям, а останутся связки под конкретные задачи.
Как по мне, баланс сил в будущем будет выглядеть примерно так:
Apache Kafka: Никуда не уйдет. Она нужна не как очередь для одного сервиса, а как сквозная шина для интеграции десятков независимых команд.
Redis / Valkey: Сверхбыстрый In-Memory кеш, когда дисковая БД (даже Postgres) начинает захлебываться на чтении.
Apache Ignite: Распределенная In-Memory БД для тяжелых вычислений «на лету» над большими данными.
NewSQL (CockroachDB, TiDB): Замена классическому Postgres, когда проект вырастает из одного сервера и упирается в шардирование.
Vector DB (Qdrant, Milvus): Специфичная ниша для ИИ и работы с эмбеддингами.
Так что Кафка останется на своем месте (в enterprise-интеграции), а вот монополия Postgres точно пошатнется в пользу распределенной памяти (Ignite/Redis) и NewSQL.
Остановитесь)
Cursor один из тех,кто сделает так,как захочешь именно ты,по сравнению с другими ИИ.
ИИ‑психологтакого нельзя допуститьИз-за оверквалифай-требований на собесах стресс такой, что начинаешь заваливать даже элементарную базу. Физическая нагрузка помогает «пересобрать» голову перед созвоном, но проблема глубже. В 2026 году собеседования окончательно превратились в оторванный от реальности экзамен. Ты можешь идеально ответить по всем чек-листам, но это вообще ничего не гарантирует — дальше просто не зовут.
За неделю второй пост про Kafka ui от VK. Видимо действительно проблема в компании с этим?🤔
Хорош!
Отличный материал, который приземляет тему ИИ с небес на землю. Полностью согласен с тезисом о сложности интеграции. Сейчас на рынке затихает первый хайп, когда все радовались простым чат-ботам, и начинается суровая реальность.
Одно дело — крутить LLM в изолированной «песочнице», и совсем другое — превратить её в автономного агента, встроив в реальный production. Мало написать промпты, нужно связать модель с кучей legacy-сервисов, настроить логику и обработку ошибок, когда ИИ начинает «галлюцинировать». В итоге на поддержку и оркестрацию этого агента уходит едва ли не больше ресурсов, чем на классическую автоматизацию.
Ну и вопрос ИБ здесь встает в полный рост. Давать агенту доступ к внутренним базам данных, корпоративному коду или, тем более, право совершать действия в системе (например, деплоить или менять настройки) — это пока огромный риск. Изолировать контекст, защитить модель от prompt injection и гарантировать, что ИИ случайно не «слил» или не удалил лишнего, сейчас невероятно сложно. Пока эти две проблемы — контролируемая интеграция и безопасность — не будут решены на уровне стандартов, ИИ-агенты так и останутся дорогими игрушками для локальных задач.
Совсем забыл добавить в этот список Москву, Санкт-Петербург, Выборг и Золотое кольцо — там тоже успел прилично накатать!)
А как же наш друг из поднебесной DeepSeek?)
Примите мои искренние соболезнования в связи с потерей отца. Родители и семья — это самые близкие и дорогие нам люди.
Ваша история во многом отозвалась во мне. Я, как и вы, получил права в 2016 году. Водить я умел и раньше: у моего отца была легендарная Toyota Crown 1985 года выпуска, которая на ходу до сих пор. На ней я и учился ездить по деревенскому бездорожью, где асфальт был большой редкостью. Сразу после получения прав я сел за руль дедовского УАЗа. Это было мое главное разочарование в отечественном автопроме, хотя проходимость и два топливных бака, конечно, впечатляли.
В автошколе я очень ответственно подошел к теории: не пропускал занятия, ведь понимал, что это нужно мне самому. Нам повезло с преподавателем — опытным автовладельцем, у которого были даже японские права (а получить их невероятно сложно). Он делился бесценным житейским опытом: от простых лайфхаков (например, как по стрелке на приборной панели понять, с какой стороны лючок бензобака) до разбора аварийных ситуаций, нюансов обслуживания и дорожных приключений. Практику я откатывал на механике hyundai хэтчбек 2013 каждый вечер после работы. Как ни странно, самым сложным оказалось ездить именно с инструктором, а вот экзамен в ГИБДД я сдал легко и с первого раза.
Были и тонкости, о которых не предупреждали заранее. Например, новые на тот момент правила парковки на автобусных остановках. Помня об этом, я до сих пор злюсь, когда вижу «мастеров» вождения, бросающих машины прямо в начале кармана для автобусов. Про не включенные поворотники я вообще молчу. В прошлом году во время автопутешествия по Золотому кольцу России я лишний раз убедился, что таких чудаков везде хватает. Чего стоил один только «Крузак», который сразу за Ростовом Великим пошел на обгон прямо по обочине.
Прошло уже 10 лет. За это время я сменил машину, обновил права и накопил огромный ежедневный опыт. Я успел поездить по самым разным уголкам страны — от Горного Алтая до Сахалина, Находки и Владивостока, но до сих пор помню, с чего всё начиналось.
Поздравляю с открытием Grafana! Статья — классический пример того, как мы, инженеры, героически изобретаем велосипед с квадратными колесами (ООП-горшками), прежде чем просто изучить стандартный индустриальный стек. Рассуждения про ООП в контексте интерфейса горшков улыбнули.
Вы сетуете, что в Grafana нельзя сделать красивую карту датчиков на фоне реального подоконника и «в Grafana таких чудес нет». Автор, а вы про встроенный инструмент Canvas panel слышали? https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/visualizations/canvas/
Это штатная фича, где можно загрузить фото вашего балкона (или схему квартиры) в качестве подложки, расставить поверх интерактивные элементы и привязать к ним живые метрики. А в свежих версиях кнопки на Canvas умеют еще и API-запросы слать (GET/POST) — то есть прямо оттуда можно было бы и помпу полива включать, не городя свой лагающий фронтенд.
Но за docker-compose и симуляцию датчика на Python спасибо, для Песочницы — отличный старт!
Так надо было с жены и начать))
Добиться "экрана смерти"в Windows 2000 было безумно сложно, но наш информатик умел «ронять» систему быстрее. Стоило нам увлечься сетевым матчем в Quake III
и проигнорировать звонок, как учитель одним движением руки гасил автомат в щитке. Спорить было бесполезно — мы молча слушали лекцию. Чуть позже началось освоение Turbo Basic,
а на смену шутерам пришел Carmageddon
Не убиваемый!)
Тот случай, когда оверинжиниринг победил здравый смысл. Вместо написания ТЗ для нейросети, съемок и генерации HTML-кода, можно было использовать старый добрый метод «натаскайся мебели до боли в спине». И фитнес, и пространственное воображение прокачивается на лету. Мозг начинает идеально высчитывать сантиметры до розетки сразу после того, как вы в третий раз перетащите комод не туда.