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

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

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

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

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

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

Недавно собрались с коллегами в эфире ТГ канала для разработчиков обсудить то, что сейчас волнует, кажется, каждого в индустрии — ИИ-инструменты в разработке. Не абстрактно «что думаете про 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'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.

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

Привет, Хабр! Меня зовут Владимир, я SDET-специалист в компании SimbirSoft. В этой статье хочу рассказать, как мы решали проблемы тестирования не традиционным написанием автотестов, а созданием собственных REST-сервисов: сервиса генерации данных и сервиса, ассистирующего тестам.

Мне всегда была интересна тема антихрупкости и работы Нассима Талеба — особенно в контексте их применения в IT.

Книга «Антихрупкость в IT» попала в мой список рекомендаций больше года назад, после одной конференций в Казахстане.

Книга показалась мне интересно, по этому ниже обзор основных тем, и в каком случае вам стоит ее прочесть.

А так же ответим на вопросы: как продать микросервисы бизнесу? Почему у книги такая обложка? А есть ли что-то от антихрупкости Талеба в книги с таким название?

Это схема, которая описывает типы объектов в вашей системе и возможные отношения между пользователями и этими объектами (ролями, функциями защиты и привилегиями).

Классическая ситуация:

«Я данные отправил!»

«А я не получил!»

«А они зависли где-то, потому что формат не тот!»

Пример из практики: комплексный проект по рефакторингу системы управления доступами. Интеграция приложения по управлению доступами на основе ролей и привилегий (это наша Новая система) с другими информационными системами (ИС) в контуре предприятия (например, управление учетными записями, авторизация пользователей и прочие).

В данной статье я хочу поделиться опытом и рассказать о том, как системным аналитикам улучшить Sequence-диаграммы (диаграммы последовательностей) с помощью лучших практик.

Я покажу, как некоторые подходы из мира программирования (те самые best practices и идеи из Clean Code) помогают рисовать sequence-диаграммы чище и понятнее. 

Приложение тормозит. Это жалоба номер один, которую слышат разработчики и архитекторы. Но "тормозит" — это не диагноз. Это симптом. За этим простым словом может скрываться что угодно: от плохо написанного SQL-запроса до "шумного соседа" в облаке или неправильной настройки сборщика мусора.

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