Микросервисы *

Всем привет! Это Денис Сметнев. Последние пару месяцев я плотно сижу на вайбкодинге. Поднял свой сервер, запилил базу лидов из Телеграма и карту знаний, хотя последний раз кодил в 9 классе на Pascal. Вижу, что у многих появилась мысль: если я могу сам сделать себе любой софт под задачу, зачем тогда вообще нужны SaaS-продукты? Неужели они умрут? В этой статье хочу порассуждать, как на самом деле изменится рынок и почему хоронить софт пока рано.

Мажорное обновление редко ломает сервис сразу и красиво. Чаще оно оставляет тихую регрессию в сериализации, безопасности, тестах или рантайме — и всплывает уже после релиза.

В этой статье разбираем, как перейти со Spring Boot 3.x на 4.0 и с Java 21 на Java 25 не одним рискованным прыжком, а как управляемой инженерной процедурой: с промежуточной остановкой, проверками, канарейкой и понятным планом отката.

На старте проекта у нас не было ни одного автотеста. При этом продукт уже представлял собой полноценную платформу контейнеризации на базе Kubernetes с большим количеством управляемых сервисов и единой консолью управления. Любое изменение могло затронуть базы данных, брокеры сообщений, системы хранения данных или внутренние управляющие компоненты платформы.

При большом масштабе компании требования к стабильности и скорости разработки становятся критичными. Долгое время бэкенд платформы Flowwow оставался монолитным, и в какой-то момент это начало серьезно тормозить развитие продукта. В этой статье я расскажу, как мы пришли к модернизации, как поменяли архитектуру и что получилось в итоге.

Лиз Райс — вице-президент по open source в Aqua Security, мейнтейнер eBPF и автор первого издания. Первые пять лет после выхода книга реально была настольной у инженеров, которые расследовали инциденты в контейнерных средах.

Второе издание серьёзно переработано. Угрозы изменились, Kubernetes получил новые механизмы безопасности, eBPF вышел из стадии экспериментов, а supply chain-атаки стали обыденностью.

Если читали первое — здесь обновлённые модели угроз, разбор реальных CVE и конкретные рекомендации, а не просто теории.

Год назад доступ к зарубежным LLM из России превратился в квест. OpenAI и Anthropic не принимают российские карты и блокируют запросы по гео. Обходные пути — VPN, иностранная карта, прокладка через знакомых за рубежом — годятся для пет-проекта, но не для продакшена, где нужен стабильный аккаунт, предсказуемый счёт и возможность объяснить бухгалтерии, за что платим.

Мы сделали apiglue — шлюз, который закрывает эту боль: один OpenAI-совместимый endpoint, за которым прячутся десятки провайдеров, оплата рублёвой картой и баланс в рублях. А заодно — управляемый хостинг n8n, чтобы не только дёргать модели через API, но и собирать на них автоматизации без своего сервера.

Ниже — как это устроено внутри и какие решения оказались неочевидными. Без маркетинга: где замерили — пишу замеры, где спроектировали на запас — так и говорю.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Последние два года я изучаю российский рынок ESB и интеграционных платформ, делаю обзоры на продукты. Есть интересная закономерность: многие компании, которые выбирают ESB, готовят собственный опросник. В прошлом году вместе с вендорами, мы решили составить единый опросный лист. Рассказываю и показываю, что из этого получилось.

Третья, заключительная статья из цикла.

Часть 1 — где LLM теряет межсервисный контекст и почему локальных спек недостаточно.

Часть 2 — archspec как контракт вместо свободного Markdown.

Часть 3 — archspec investigate: исследование фичи, обновление контрактов и реализация.

В части 1 я показал, что spec-driven development с LLM начинает ошибаться, когда фича проходит через несколько микросервисов: по отдельности каждый сервис выглядит аккуратно, а вместе система работает не так, как нужно. Модель теряет межсервисный контекст — правила, которые живут на границах между сервисами, не записаны в одном месте, и LLM их пропускает. В части 2 я собрал archspec: на каждый сервис генерируется машиночитаемый контракт SERVICE_MAP.yaml, который делает эти правила явными.

В этой части я беру ту же фичу — автоматическое переназначение задачи после отказа фрилансера — и прогоняю её заново через /archspec:investigate, но уже поверх контрактов. Тот же промпт, та же модель (Claude Sonnet 4.6). Вопрос один: поймает ли план те межсервисные ошибки, на которых в первый раз фича не сошлась, ещё до написания кода — и где спотыкается уже сам инструмент.

Разберемся, как на самом деле устроена интеграция Flyway в Spring Boot 4: что изменилось с появлением отдельного starter’а, как Boot прокидывает настройки и почему в связке с PostgreSQL одна неочевидная опция может намертво зависнуть миграцию

Если вы запускаете GPU-нагрузки (графические ускорители) на Kubernetes — vLLM, Triton, обучающие задачи или более новые стеки агентного инференса, — вы наверняка сталкивались со знакомой проблемой: стандартный автоскейлинг по-прежнему мыслит в категориях CPU и памяти, а GPU, который реально делает работу, остается невидимым. Из-за этого простаивает дорогая емкость ускорителей, растет задержка инференса и расходуется лишняя энергия — ровно там, где компании пытаются ответственно масштабировать LLM и Agentic Ops (подходы к эксплуатации Agentic-систем).

VK Cloud перевела статью автора, который хотел бы, чтобы KEDA масштабировался по сигналам, которые важны для GPU-нагрузок: утилизации, памяти, температуре и энергопотреблению. На практике это не только вопрос стоимости. Это еще и вопрос GreenOps (экологичный подход к эксплуатации с минимизацией углеродного следа): впустую потраченные GPU-циклы напрямую превращаются в потраченную энергию и более высокие выбросы категории Scope 3 (косвенные выбросы в цепочке создания стоимости).

Оказалось, что это сложнее, чем кажется. Дальше повествование идет от его лица

DLQ — это просто топик. Сложное — всё, что вокруг него.

Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API.

Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Два года я изучаю российский рынок шин данных. За это время удалось связаться с более 40 вендорами, с половиной из них мы встретились, чтобы написать обзор. Каждый такой материал — это вопросы разработчикам, демонстрация решения, изучение документации. Недавно я объединил все обзоры в один большой, чтобы было удобнее знакомиться с разными продуктами. Рассказываю, в чем идея и что у меня получилось сделать за 2 года.

Анализ, архитектура, вайбкодинг и даже комиксы — всё это здесь.

Цели статьи: 1) проверить жизнеспособность концепции максимально простого и дешевого интернет-банкинга и заодно 2) протестировать возможности ИИ в качестве инструмента прототипирования.

Привет, Хабр! В этой статье разбираем плюсы и минусы VictoriaLogs как решения для логирования в облачной платформе.

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

Несколько человек отписались: «Если говорить о нашем отделе — результат высокий. Но если выйти за пределы отдела — там для меня начинается настоящий ад».

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

Долго воспринимал Python как язык из соседнего мира. Где то там data science, pandas, ноутбуки, модели, эксперименты. А у меня обычный backend: API, микросервисы, Kafka, БД, CI/CD и продакшен.

C# и Java для этого хватало.

Но когда начал разбираться с LLM быстро понял, вызвать модель можно из любого языка, а вот руками потрогать RAG, embeddings, локальные модели, чанкинг и evaluation проще всего через Python.

И ещё быстрее стало понятно другое, LLM это не просто «отправить prompt и получить ответ». Как только речь заходит о реальной системе появляются привычные backend вопросы «доступы, логи, стоимость, latency, качество ответа, безопасность данных и сопровождение».

Поэтому для меня Python стал не заменой C# или Java, а инструментом который помогает быстрее зайти в новый слой backend задач.

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами, и про то, как именно этот слой убивает ИИ-проекты, я уже подробно разбирал в предыдущей статье на Хабре. 

Интеграция - это только одно из пяти узких мест, на которых ломается реальное ИИ-внедрение. Дальше идут атаки на агентов, регуляторика, разрыв стоимости разработки и сценарий, которого нет в голове у заказчика. Со мной в этом разборе еще трое: ИИ-архитектор Андрей Носов, Team Lead пентестер Сергей Зыбнев и директор по информационной безопасности компании Вебмониторэкс Лев Палей. 

Представьте: сотни микросервисов, неделя на поиски API, устаревшая документация. Backstage от Spotify превращает хаос в порядок — и возвращает контроль над масштабом.

Все мы любим envsubst за простоту, но он примитивен. Переходить на Python с Jinja2 ради шаблонизации конфигов в CI/CD — всё равно что стрелять из пушки по воробьям, да и тащить рантайм ради пары переменных не хочется. В мире Go есть неплохие аналоги, но их вес в 100 МБ вгоняет в тоску, когда стремишься к минимализму в Docker-образах.

Теперь всё изменилось так как появился muenvsubst — замена стандартной утилите, написанная на C++17, заточенная под хардкорную шаблонизацию в инфраструктуре. В этой статье я расскажу, как уместить мощь, близкую к Jinja2 (включая циклы, условия, макросы и вызов shell), в статический бинарник весом менее 400 КБ.

Привет, Хабр! Меня зовут Сергей Зиновьев, я бизнес-партнёр по информационной безопасности в Авито. Если какие-то сканы на безопасность кода легко автоматизировать, то с уязвимостями на этапе проектирования всё обстоит сложнее. Для превентивного выявления подобных проблем организации и сообщества вроде NIST и OWASP рекомендуют использовать моделирование угроз в рамках своих гайдлайнов и фреймворков. В нашей практике это довольно творческий процесс, требующий понимания как продуктовой, так и технической стороны.

В Авито мы масштабировали этот процесс на 2500+ инженеров, и сегодня я расскажу, как мы к этому пришли — с какими сложностями столкнулись, какой фреймворк выработали и как адаптировали его под реальные потребности продуктовых команд.