Архив рубрики ‘микросервисы’

C4 для системного аналитика: как навести порядок в микросервисном хаосе

Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java/Kotlin‑разработки в FinTech и E‑commerce, а ещё преподаю на курсах разработки и архитектуры в OTUS. Представьте: вам как системному аналитику выдали задачу — внедрить новый механизм кэширования в высоконагруженный API‑шлюз. Вокруг 12 микросервисов, три команды разработки, бизнес‑спонсор, который хочет «просто ускорить всё», и Confluence, где документация умерла год назад. С чего начать? […]

Backstage — управление микросервисным ландшафтом без хаоса

Представьте: в вашей компании уже не десятки, а сотни микросервисов. Новый разработчик приходит в команду и первую неделю тратит не на код, а на поиски. «Где лежит этот API?», «Как запустить этот сервис локально?», «Кому писать, если он падает?». Каждая команда изобретает свои велосипеды для документации, а общие инструменты превращаются в разрозненную коллекцию закладок в […]

Гайд: как системному аналитику построить доменную модель для Java-микросервисов

Всем привет, меня зовут Сергей Прощаев. Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce, преподаю на курсах разработки и архитектуры в OTUS. В этой статье разбираю системный подход: как системному аналитику спроектировать доменную модель, которая прямо ложится в код Java-микросервисов, и избежать ситуации, когда архитектор после передачи требований перекраивает всё […]

Почему проекты превращаются в спагетти даже у хороших программистов

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код. А потом проходит несколько лет. И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения. Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку […]

Философия автотестов: управление, поддержка и флаки

Хроники Облачного княжества: как я приручал монолит‑дракона: Орден SLO и игла Кощея

Часть 3. Самая опасная магия в IT — это магия целей. Потому что цель легко обещает, а потом требует процентами отчёта. Есть особый вид страха, который появляется у инженера, когда два календаря совпадают. Первый календарь — релизный.Второй — организационный. И когда в один и тот же день на вас назначают «большую миграцию» и «большую презентацию […]

10% на LLM и 90% на инженерию: как российские компании используют ИИ

Привет, Хабр! Продолжаю делиться материалами живых дискуссий, которые идут на телеграм-канале Dev Q&A. На этот раз тема — выбор между open source и коммерческими LLM для корпоративных задач. Получилось собрать практиков, которые каждый день решают эту дилемму: Андрея Кувалдина («Транссеть»), Сергея Олькова («Диасофт»), Максима Семёнкина (CodeInside), Артема Панькова (Secret Agents), Владислава Кудинова (Veai), Константина Глазкова […]

ИИ в разработке: почему иногда «в три раза быстрее» не означает «проект раньше»

Привет, Хабр! Недавно собрались с коллегами в эфире ТГ канала для разработчиков обсудить то, что сейчас волнует, кажется, каждого в индустрии — ИИ-инструменты в разработке. Не абстрактно «что думаете про ChatGPT», а конкретно: что реально работает, что нет, и почему при всём хайпе проекты не стали выходить быстрее. Получилась хорошая дискуссия с Алексеем Цыкаревым (Spectr), […]

Архитектурный выбор: Монолит против микросервисов без технического диплома

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

Оркестрация на BPMN: взгляд изнутри

Современные подходы к разработке программного обеспечения диктуют необходимость быстрого внедрения и изменения бизнес-сценариев прямо в продакшене. Особенно это критично для систем, где логика процессов часто корректируется — например, в финансовых, маркетинговых

123