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

Если вы запускаете 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+ инженеров, и сегодня я расскажу, как мы к этому пришли — с какими сложностями столкнулись, какой фреймворк выработали и как адаптировали его под реальные потребности продуктовых команд.

Микросервисы обещают масштабирование и независимость команд, но чаще ломают систему медленнее монолита. Почему?

В статье разбираем семь архитектурных ошибок, которые можно встретить в реальных системах: выбор по моде, shared database, игнорирование network latency, операционная сложность на потом, слишком мелкая декомпозиция, отсутствие стратегии consistency, недооценка сроков миграции.

Привет, я Даниил, DevOps-инженер в KTS.

Я работаю над инфраструктурой одной крупной сети. В ее штате несколько команд разработки, которые делят между собой больше 40 микросервисов, составляющих одну систему. Ожидаемо, со временем их dev-стенд сильно отстал от продакшена, и разные команды с трудом протаскивали новые фичи до релиза.

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

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

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

В этой статье я постараюсь ответить, что происходит с объектом от его рождения до смерти. И отдельно поговорим про другое измерение — эволюцию его API-схемы.

Существует продуктовый паттерн, который я редко вижу разобранным в технических статьях на русском: бот в групповом чате, который реагирует не на команды, а на содержимое обычных сообщений участников. Юзер кидает в чат ссылку на Instagram Reels — бот молча присылает видео файлом под этой ссылкой. Никаких /download, никаких упоминаний @bot, никаких inline-режимов.

Звучит просто. На практике — десяток подводных камней: Telegram Bot API в группах работает иначе, чем в личках; privacy mode ломает половину очевидных решений; flood-control прибьёт наивную реализацию на третьем активном чате; и есть отдельная проблема — как не превратить бота в спам-машину, которая реагирует на каждый https-ссылку в чате и раздражает участников.

Эту статью пишу как разработчик такого бота. Цифры из моего прода маленькие — 31 групповой чат, 380 пользователей в личке за месяц жизни — но проблемы в коде ровно те же, что были бы и при 31000 чатов. Хочу разобрать архитектурные решения, к которым пришёл, и услышать, как делали бы вы.

C# я до сих пор считаю одним из самых удобных языков для backend разработки. В нём много вещей к которым быстро привыкаешь: свойства, LINQ, async/await, generics без type erasure, хороший tooling и понятная модель разработки.

Но банковский enterprise редко выбирает стек только по удобству языка. На практике важны не только синтаксис и экосистема, но и инфраструктура, сопровождение, безопасность, регламенты, legacy, найм, CI/CD, требования к платформам и долгосрочная стратегия организации.

Так я оказался в ситуации где C# мне субъективно нравится больше, но Java объективно стала полезнее в конкретном банковском контуре.

Эта статья не про холивар C# vs Java. Это попытка спокойно разобрать почему backend разработчику в enterprise иногда приходится расширять стек, даже если текущий язык его полностью устраивает.

В первой части я разбирал, почему spec-driven development начинает ошибаться, когда фича проходит через несколько микросервисов. Проблема не в том, что LLM плохо читает код или не умеет писать спеку. На уровне отдельных сервисов всё может выглядеть аккуратно: есть описание, план, реализация и тесты. Но правила, которые связывают сервисы между собой, часто не записаны в одном месте. Часть таких правил спрятана в реализации, часть известна только команде, а часть всплывает уже на ревью. Обычный Markdown не решает эту проблему: его легко написать неполным, сложно проверить автоматически и почти невозможно ревьюить как структурный контракт.

Отсюда родилась идея: нужен машиночитаемый контракт на каждый сервис, который фиксирует межсервисные правила, проверяется на коммите и даёт LLM структурный контекст вместо набора Markdown-файлов. Для этого я собрал open source плагин для Claude Code — archspec.

В этой части я покажу, как работает /archspec:init на одном сервисе из демо-проекта freelance-marketplace, разберу сгенерированные артефакты и объясню, как archspec поддерживает их в актуальном состоянии. Напомню, это Go-проект с 12 микросервисами для поиска фрилансеров. Вот схема сервисов, которую я использую на протяжении всего цикла:

Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime, informer’ы, Reflector, DeltaFIFO, почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись.

Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально. На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply. Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает.

Сегодня будем разбираться, какие механизмы в Kubernetes позволяют разным компонентам делить ответственность за части одного и того же объекта, не превращая запись в гонку — и как ими правильно пользоваться, когда оператор пишете вы сами. Добро пожаловать под кат.

В этой статье мы разберём реальную задачу на проектирование Maven Multi‑Module: от циклических зависимостей и неправильного использования spring‑boot‑maven‑plugin до смешения ролей агрегатора и родителя. Затем соберём эталонную структуру по лучшим практикам Spring Cloud и Netflix, добавим CI/CD‑диаграмму и научимся запускать сервис локально без Eureka и RabbitMQ.

Когда мы пытаемся в одном бэкенде совместить и строгую бизнес-логику, и все «рюшечки» для фронта — получается монстр Франкенштейна. Это потому, что стабильная по своей природе бизнес-логика начинает дёргаться от каждой «косметической» правки в интерфейсе.

А если у нас не один, а несколько фронтендов: веб-сайт для клиентов, админка для сотрудников, мобильное приложение... А далее, у каждого свои пользователи, свои сценарии и свои «хотелки». Чтобы угодить всем, бэкенд-разработчикам приходится плодить десятки почти одинаковых методов, которые раздувают кодовую базу и усложняют тестирование.

Рассказываю о том, что делать со всем этим безобразием...