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

Я Олег Одинцов, платформенный инженер App.Farm. App.Farm — собственная разработка Россельхозбанка, которая используется для стандартизации процессов разработки программного обеспечения и предоставления высокоуровневого интерфейса пользователям для автоматизации их задач. Можно сказать, что App.Farm — это автоматизация «под ключ». Пользователь получает полный цикл управления разработкой от размещения кода до деплоя приложений. Более «смузийное»  название — IDP платформа.

Разработка сервисов с интеграцией в AWS быстро упирается в компромиссы: либо работать с реальным облаком и платить за каждый эксперимент, либо замокать инфраструктуру и надеяться, что в продакшене всё «взлетит». В статье показано, как с помощью .NET Aspire и LocalStack выстроить полноценное локальное AWS-окружение — с S3, CDK и реальной оркестрацией — так, чтобы один и тот же код без условностей работал и локально, и в проде.

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

Мы решили провести «хирургическую операцию»: за один месяц силами выделенной команды из 10 человек полностью расчистить сервис, вынести из него 40 процессов и вернуть архитектуре прозрачность. В этой статье я расскажу, как мы поставили диагноз, спланировали операцию и справились с самыми болезненными моментами — от войны с конфигами до разрыва общих DTO.

Главный спойлер: результат превзошёл ожидания. Сервис стал быстрее, команды — автономнее, а система наконец-то обрела масштабируемость.

За две недели я собрал бесплатный веб-сервис, который генерирует диаграммы по текстовому описанию — без ручного рисования и без мучений с кривыми картинками от ИИ. Ключевая идея: вместо генерации изображений — генерация PlantUML-кода, затем серверный рендеринг в PNG и выдача пользователю. В статье рассказываю, как я проектировал сущности и сервисы, строил микросервисную архитектуру с очередями, поднимал PlantUML-server и MinIO, настраивал мониторинг и деплой, а также танцы с бубнами вокруг локальной LLM — и как меня спас старый ноутбук с GPU. Отдельно — про боль вайбкодинга: где ИИ-агенты помогают, а где требуют жёсткого микроменеджмента и шаблонов промптов.

От монолита к модулям: строим масштабируемую архитектуру AI-агентов с FastMCP и LangChain

Год бума AI-агентов показал: самая большая проблема — не галлюцинации, а архитектура. Когда инструментов много, а агенты распухают, копипаста и сложность тестирования убивают скорость разработки.

Привет, Хабр!

Продолжаю делиться материалами живых дискуссий, которые идут на телеграм-канале Dev Q&A. На этот раз тема — выбор между open source и коммерческими LLM для корпоративных задач. Обсудили главные болевые точки: почему почти все корпоративные заказчики требуют он-прем, как узкоспециализированные модели обходят универсальные решения, насколько реален GPU-дефицит для практических задач.

Привет, Хабр!

Продолжаю делиться дискуссиями из нашего телеграм-канала Dev Q&A. На этот раз собрались поговорить о том, почему при всём богатстве инструментов — Kubernetes, CI/CD, low-code, AI-ассистенты — разработка не становится ни быстрее, ни дешевле.  Собрал ключевые мысли в статью. Получилось про три столпа эффективности, про хаос который понятнее порядка, и про то, почему скрам по книжке остановил компанию на две недели, а Waterfall принёс миллиард. 

Привет, Хабр!

Недавно собрались с коллегами в эфире ТГ канала для разработчиков обсудить то, что сейчас волнует, кажется, каждого в индустрии — ИИ-инструменты в разработке. Не абстрактно «что думаете про ChatGPT», а конкретно: что реально работает, что нет, и почему при всём хайпе проекты не стали выходить быстрее. Вообщем, собрал ключевые мысли — дальше от третьего лица, включая свои реплики как участника.

15 декабря в МГТУ им. Н.Э. Баумана (в питчинг-формате) прошел финальный Демо-день акселерационных программ «Умный город» и «Робототехника и беспилотные авиационные системы» (БАС). В течение трех месяцев студенческие команды под руководством опытных наставников последовательно работали над своими проектами. На мероприятии в МГТУ они представляли свои разработки бизнес-сообществу, инвестиционным фондам, институтам развития и другим заинтересованным сторонам, которые способствуют укреплению технологического суверенитета.

Привет, Хаброжители! «Паттерны Kubernetes» — это не очередной справочник по настройке кластеров или описанию API. Это фундаментальный труд, который отвечает на самый главный вопрос: как эффективно проектировать и строить приложения, предназначенные для работы в Kubernetes? Авторы систематизировали лучшие практики, преобразовав их в паттерны. Книга учит не просто использовать Kubernetes, а мыслить категориями платформы, комбинируя примитивы для создания отказоустойчивых, масштабируемых и удобных в эксплуатации систем. Это must-read для любого разработчика, который хочет выйти за рамки простого деплоя контейнеров и овладеть всеми возможностями Kubernetes.

Сегодня потребности бизнеса растут так стремительно, что решения для унифицированных коммуникаций (UC) просто не успевают за ними. Аплайнсы — выделенные «железки» под конкретную задачу — очевидно устарели: масштабировать их сложно, обновлять страшно, а добавление новых функций напоминает скорее тест на выносливость. Я Владимир Сергеев, руководитель практики UC и ПО для совместной работы в К2Тех. Регулярно я сталкиваюсь с тем, как очередной апдейт превращается в персональную головную боль для ИT-отдела.

Решением, которое буквально спасло UC-инфраструктуру, стал Kubernetes. Теперь вместо тяжелых проприетарных коробок — легкие микросервисы. Вместо многочасовых простоев — обновления за минуты. Вместо страха перед будущим — быстрая реакция на любые бизнес-задачи. И никакого даунтайма для всей компании.

Давайте погрузимся в детали этого перехода: от неповоротливых «кирпичей» к динамичным контейнерам. Разберемся, почему страдать от обновлений больше не нужно. И посмотрим, так ли все радужно на самом деле.

Как работать с оффсетами в Kafka на практике, используя Spring Boot?
Разбираем проблемы и их решения на примере интернет-магазина.

Простым языком и с примерами кода о режимах коммитов, проблемах с транзакциями и надёжных паттернах.

Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.

Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».

Привет! На связи Read IT Club — сообщество рецензентов и переводчиков ИТ-литературы. Мы делимся проверенными книгами, которые помогают не просто читать про ИТ, а по-настоящему понимать, как все устроено внутри. На этот раз — три издания о том, как проектировать надежные системы, создавать архитектуры, способные к изменениям, и выстраивать понятные API без избыточной сложности.

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

Мы в Ситидрайве строим микросервисную архитектуру. Сегодня у нас 200+ сервисов, за которыми стоят свыше 20 автономных команд — всего больше 150 инженеров. Казалось бы, идеальная модель: каждая команда быстро выкатывает свои фичи без лишней бюрократии. Но была и обратная сторона — нет единого понимания, какие сервисы действительно критичны, как они связаны друг с другом и куда развивать систему дальше.

Но нам удалось с этим справиться — мы привели сотни микросервисов в порядок и сделали систему предсказуемой. В этой статье я расскажу про путь команды к внедрению тир-листа, модели зрелости, управлению зависимостями и приоритетами инцидентов.

Привет, Хабр!

Я двадцать лет работал в руководстве ИТ в банках и страховых компаниях. За это время через меня прошли десятки проектов заказной разработки. Некоторые из них я вспоминаю с гордостью. Некоторые — с содроганием.

Protobuf как контракт: spec‑first валидация с protoc‑gen‑validate

Первая статья из мини‑серии про валидацию на базе Protobuf. В этой части — концепция spec‑first и protoc‑gen‑validate. В следующей поговорим про protovalidate и то, почему его вообще имеет смысл рассматривать как «следующее поколение» (или же как очередная эволюция в обратную сторону?)

Также, чтобы не пропустить следующую часть, очень рекомендую подписаться на мой телеграмм канал :-)

Serverless — это не отсутствие серверов. Это состояние, когда вы перестаете о них думать. Вы не патчите ядра Linux, не настраиваете Nginx и не мониторите свободное место на дисках. Вы пишете функцию, загружаете код в облако, и платформа сама решает, где и как это запустить.

Звучит идеально. Но на практике Serverless — это сделка. Вы отдаете контроль над инфраструктурой в обмен на удобство. И часто цена этой свободы — новые, совершенно неочевидные архитектурные проблемы.

Вы проектируете масштабируемую систему на System Design интервью в BigTech. Всё идёт хорошо, пока вам не задают неожиданный вопрос. От ответа на который зависит ваше прохождение.

Разберём 10 популярных вопросов, ответы со схемами и примерами в ультимативном чеклисте. И закроем для себя этот важный аспект интервью.

Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.

Чтобы это знание обрести, мы привезли в нашу инженерную савану SLO'на — неповоротливое, но умное существо. Он наводит порядок в хаосе метрик и алёртов, и отличает реальную проблему от мнимой. А ещё он требует внимания, точных чисел и ясных целей. Поначалу мы его боялись, но позже поняли: если его приручить, он защитит нас от ночных звонков и научит бизнес говорить на языке надёжности.

Сегодня мы расскажем, как приручили своего SLO'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.