Соер.Клуб | начался курс по микросервисам

Отказываюсь от использования Claude и вот почему. Anthropic делает одни из лучших моделей — это факт. Я в полном восторге от Opus 4.7, новая модель Opus 4.8 на проверочных задачах выглядит ещё лучше. И казалось бы, нужно пользоваться лучшим инструментом, чтобы получать лучший результат. Но нет, на практике всё упирается в «цена/качество». И здесь выясняется самое неприятное: Opus отлично справляется с простыми задачами по разработке, но на сложных задачах его мощности не хватает. Я делаю несколько пет-проектов, которые полностью разрабатывает ИИ, показательны два примера: 1. Простой сайт (soerdev.space) с типовыми веб-элементами, Angular и разделением на модули. Claude разрабатывает модули и делает это на изи. На выходе вполне читаемый код, но требует отдельно создавать модули и отдельно их интегрировать в проект. 2. Самописный оркестратор для команды агентов. Здесь Клод отвечал не только за код, но и за архитектуру проекта (было всего три версии, которые полностью писал ИИ и пробовал реализовать). Итог плачевный — первый месяц активно набираем фичи, обсуждаем, планируем, кажется, что всё хорошо, затем технический долг начинает поджимать, регулярный рефакторинг не спасает и начинаем работать только на устранение тех. долга, при этом приходится самому лезть в код, чтобы понять, в чём проблема. В какой-то момент принимаешь решение: «Стоп! Хватит!», делаем новую версию и учитываем все проблемы в планировании и описании архитектуры. В итоге описание с каждой версией всё лучше, а проект всё так же затыкается через 1–2 месяца разработки. Сначала я списывал неудачи второго варианта на неправильный подход, но после третьей попытки решил отказаться от идеи «ИИ на всех этапах работы». Проблема в том, что ИИ постоянно пытается решить задачу кратчайшим путём, игнорируя абстракции и ограничения. В итоге спустя месяц ты лезешь в код и удивляешься: «Да зачем ты это сюда засунул?». Начинаешь анализировать и видишь, что в проекте есть куча частных решений, нет чётких интерфейсов и непонятно, как это вообще работает. Если ткнуть ИИ в конкретные АДР, то он видит, понимает и даже говорит «сейчас всё исправлю», а в итоге становится только хуже. Последний вариант оркестратора я собрал на своей архитектуре, которую разработал сам (включая структуру проекта). ИИ делает только конкретные небольшие модули, для которых уже созданы и описаны интерфейсы, прописаны ограничения, есть АДР и т.д. Клод справляется с этим на ура... Есть только одно «но» — китайские модели — MiniMax, Kimi, GLM тоже выдают при таком подходе нормальный результат. Сейчас Anthropic в своего «сжигателя токенов» (Claude Code) добавил динамический воркфлоу, который сделал процесс уничтожения токенов ещё быстрее, но описанные выше проблемы это не решает (возможно, если лимиты будут в 100 раз больше, то ситуация исправится, но у меня нет таких денег). Сейчас за пару минут (и это не преувеличение) можно спалить все лимиты подписки и никуда не сдвинуться (вспоминается Алиса: нужно быстро бежать, чтобы просто оставаться на месте). Поэтому я решил переехать на китайские модели + свой оркестратор. Функции оркестратора: подбор LLM, использование ролей (определяет скилы и инструменты), запуск агентов, использование пайплайнов. Результат устраивает более чем: адекватная цена и нормальный результат, без «сюрпризов» в виде скрытого тех. долга. Проблема одна: требует внешнего наблюдателя и продуманной архитектуры, но это и с Клодом так, так что выбора особо нет.

Уооо Горбушка, стоит на месте, всё нормульдик Скоро снова будем тут диски/флешки покупать, будет снова тут центр цифровой движухи, как в 90х-нулевых Накопители с незапиканной музыкой, незаблюренными сериальчиками, с дистрибутивами винды, весами LLM и новыми пакетами с гитхаб «Лучшие Python и Nodejs библиотеки 2026» «Полный набор ИИ май 2026» «Брейкинг Бэд в переводе Гоблина все сезоны» «Гуф золотые шлягеры» Хорошо так, тепло:)

Какая же жизаааа 👇👇👇

ИИ база Ну что, дожили до того светлого будущего, когда все больше работодателей интересуются, умеет ли соискатель работать с ИИ. Сразу успокою, пока — это далеко ни каждый первый и даже ни каждый второй, поэтому есть время подготовиться и понять, что вообще могут спросить и как отвечать. Почему стали проверять знания ИИ? Тут все просто — строили, строили и наконец построили процессы, которые включают работу агентов как дополнительный инструмент для решения рабочих задач. Раньше джун мог выехать на одном языке и фреймворке, а теперь даже на старте ждут, что ты не просто пишешь код, а понимаешь, как подключить к этому делу LLM. Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии. Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу. Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь: Теория: - промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д. - контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д. - обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»); - архитектура агентов (включая команды агентов) Практика Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно: - построить структуру проекта c учетом spec-driven development, ADR и т.д.; - подобрать набор инструментов (в том числе MCP) и скиллов; - разбить задачу на этапы (планирование, проектирование, реализация, контроль); - решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен). И для общей статистики предлагаю поставить 💡 если в твоей компании уже просят использовать ИИ или на собесах задают вопросы по ИИ.

По пабликам гуляет новость, что Mythos нашел за месяц более 10к багов. Нюанс в том, что новостей о таком же количестве багфиксов от ИИ как-то не наблюдается. Проблема в том, что искать баги - это одно, а исправлять их - совсем другое. Казалось бы, что мешает тому же Mythos направить MR в открыте проекты и помочь закрыть проблемы? Ответ простой: ИИ этого пока не может. Сам поиск анамалий - это довольно простой процесс, если сравнивать его с процессами разработки, сопровождения и развертывания. Допустим нашел баг? Теперь нужно найти причину, выработать решение, унифицировать решение, проверить на соответствие требованиям и ограничениям, провести тестирование, выпустить релиз. Получается, что без инженеров опять никуда, даже самые мощны модели пока не способны рулить процессами (по необходимости создавая их на лету), чтобы быстро устранять баги. Известная проблема "щита и меча", меч сейчас сильно опережает щит, так что, господа инженеры, у вас, кажется, намечается много работы.

Попросил клода посмотреть на мой сайт soerdev.space глазами дизайнера, он сказал, что использовать темную тему для чтения текстов - издевательство над пользователями и переделал все нафиг. А потом я посмотрел на все это дело и заодно попросил его докрутить отображение memrmaidjs диаграмм, перекроить кое-какие блоки. И знаете, что? Мне понравилось как получилось!

Есть один момент, который, кажется, неправильно воспринимают. Если у вас есть идея, что "я сейчас научусь промптить и вайбкодить, а бизнес снова меня наймет", то это очень сомнительный вариант. Бизнесу не нужны вайбкодеры, можете послушать Корпатого, он прямо говорит, что будущее за системами, которые будут сами создавать проекты, а работа человека будет заключаться только в построении архитектуры этих систем. Причем не факт, что эти системы будут создавать код, вполне могут быть иные промежуточные представления, для решения поставленных задач. Кажется, что это далекое будущее, но если посмореть на скорость последних лет, то это горизонт 2-3 лет. Проще говоря, если вы планируете работать в АйТи, то забудьте о том, что вы найдете какой-то новый хитрый способ перекладывать код, полученный от LLM в рабочую систему. Все простые задачи будет делать LLM, человеку останутся только сложные высокоуровневые вещи.

Вот я постоянно рекламирую наше сообщество "наш клуб дает то", "наш клуб делает это", а чем он так хорошо этот "наш клуб"? Для меня это вопрос ответ на который дает мотивацию и силы для дальнейшего движения вперед. Ну правда, клуб ради чего? Чтобы денег заработать? Какой-то сомнительный стимул, есть другие способы заработать, реализовать которые проще (например, консультации). Мне важно показать как я вижу мир разработки, продвинуть свою "вселенную", если хотите. Мне интересно заниматься клубом потому что он приносит нематериальные результаты - клуб как работающая система, помогающая развиваться его участникам. Очень кайфово видеть результаты и отзывы на проделанную работу. Обычный подход в подобного рода объединениях - это обучение. Сделал курс, собрал людей, курс закончился и все. Мне же нравится идея "совместного развития", т.е. клуб для меня - способ найти единомышленников и развиваться с ним вместе. Мы уходим от идеи "обучения" к идеи "просветительской деятельности" (это в законе такой термин, так что извиняйте, если сильно пафосно звучит). Постоянный обмен опытом не по принципу "я даю тебе знания", а по принципу "разбираемся с тем, что можно использовать на практике и делимся опытом". Поэтому для меня клуб - это достойное продолжение канала SOER + попытка собрать все в работающую систему, которая помогает участникам развиваться, а не просто накапливать знания.

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

У многих разработчиков появилось беспокойство за свое будущее. Это связано с тем, что сейчас люди выполняют роль конвейера между LLM и реальным проектом. Типичный цикл: получил таск, скопировал в LLM, результат скопировал в проект. Закономерно, что ценности в таком труде нет, и бизнес хочет автоматизировать эти процессы, передав «перекладывание кода» ИИ-агентам. Бизнесу интересно нанимать людей для задач, которые ИИ пока не решает. В ближайшем будущем такие задачи будут связаны не со способностью генерировать код (LLM неплохо справляется с изолированными фрагментами уже сейчас), а с умением анализировать и понимать проект, корректно выполнять декомпозицию, разбивать задачи для ИИ, владеть технологическим стеком, работать с инфраструктурой и проводить границы между компонентами. Это коротко называют «инженерный стек». Отсюда появился термин «ИИ-инжиниринг» — направление, в рамках которого инженеры-программисты ведут разработку проекта, используя LLM и агентские системы. Процессы автоматизируются с помощью оркестрируемых агентов, а люди выполняют роль валидаторов результатов и аналитиков требований. Разрыв между навыками написания кода и полноценными инженерными навыками оказался огромным. Проблема даже не в знаниях, которые нужны для ИИ-инжиниринга, а в неумении декомпозировать задачу до уровня, где LLM не теряет контекст, составлять проверяемые требования, исключать противоречия. Сложно менять привычки, уходить от I-shape подходов, переставать ждать от LLM архитектурных решений. Так как наш клуб изначально заточен на инженерный стек, нам немного проще объяснить и помочь разработчикам скорректировать навыки. Что нужно делать: 1. Нарабатывать архитектурные паттерны — то есть видеть задачу с позиции требований, разделения ответственности и проведения границ, определять способы коммуникации между компонентами, убирать зацепление и увеличивать когезию. Есть много книг на эту тему, но главное — практика. Набивая шишки на проектах, созданных с помощью LLM, и продумывая архитектуру до первого промпта, можно прокачаться быстрее, чем на обычных задачах. 2. Работать с требованиями и контрактами. С позиции хронологии этот этап должен идти до архитектуры, но я поставил его вторым, так как считаю важнее сначала наработать архитектурное мышление. Требования — вторая задача, которая помогает выделить главное, найти противоречия и компромиссы. Тут можно оттолкнуться от готовой теории: взять DDD за основу, посмотреть в сторону пользовательских историй и сценариев использования, а также использовать OpenAPI как исполняемый контракт между компонентами. 3. Работать с инфраструктурой. Это ещё одна важная деталь, которая подразумевает уход от узкой специализации к более широкому взгляду. Инженер должен видеть «общую картину» и понимать, как проект работает на всех этапах — от локального запуска до продакшна. База здесь: виртуализация, контейнеризация, СУБД, очереди сообщений, брокеры событий. Без этого LLM будет генерировать код, который работает в изоляции и ломается в реальной среде. 4. Работать с безопасностью. Это вопрос, который, на мой взгляд, останется узкой специализацией ещё надолго. LLM вряд ли доверят принимать решения по разграничению доступа или аудиту. Но базовые принципы знать обязательно: минимальные привилегии, контроль доступа, аудит действий, валидация входных данных на границах контекстов. Чтобы советы не звучали абстрактно, расскажу, как мы строим работу в нашем клубе. Год назад мы запустили три курса — монолиты, сервисы и микросервисы. Это три кита любой современной архитектуры, поэтому сосредоточились на них. В рамках курсов рассматриваем архитектурные подходы: принципы построения софта в современных реалиях, коммуникацию и декомпозицию. Для закрепления теории проводим регулярные семинары, где учимся выражать мысли, критикуем решения друг друга, формируем инженерную базу. Практическая часть каждого курса — мини-проект. Практика помогает прояснить проблемные места в теории, подсвечивает ошибки и способы их устранения.

Инженеры которых мы заслужили:

Масштабирование как процесс включает в себя процесс деплоя

Навсякий случай напомню, что согласно Вики: "Software deployment is all of the activities that make a software system available for use"

Удивляет, что многие воспринимают ИИ как конкурента и потенциальную угрозу для своего трудоустройства. На мой взгляд ИИ наоборот — огромное окно возможностей, которое возвращает нас во времена, когда можно было в соло создавать крутые проекты. Если у вас есть пара друзей и свободный гараж, то сегодня вы снова можете создавать продукты, о которых заговорит весь мир. И это не преувеличение. Например, самый «звёздный» репозиторий на GitHub — OpenClaw, его создал один человек и получил огромный успех. Ещё пример — Hermes, который создан Nous Research, которая в свою очередь началась с небольшой группы энтузиастов в онлайн-дискорд-сообществе. Да, ИИ скорее всего изменит фронтенд как самостоятельную отрасль и заставит фронтендеров уходить в «fullstack разработчиков» или даже в «инженеров-разработчиков». Но это та цена, которую придётся заплатить за новые задачи — непаханые поля для новых решений. Особо я благодарен ИИ за то, что он вдохнул жизнь в робототехнику. Думаю, скоро мы увидим огромное количество стартапов, которые будут менять нашу реальную, а не виртуальную жизнь. Так что одна дверь закрылась, но взамен открылась тысяча других

Стал часто встречать подобные комментарии: "В эру AI будущее за хардскиллами, лол" Я много занимаюсь созданием оркестрируемых агентских систем, есть опыт использования ИИ в разных задачах. И чем дальше, тем больше убеждаюсь, что Human in the loop пока единственный способ поднять качество работы ИИ до нужного уровня. Человек нужен, чтобы принять решение по какому из множества вариантов нужно двигаться системе дальше, поставить задание, проверить что выдали агенты и т.д. А для этого напрямую используются технические знания и навыки: нужно быстро читать код, учиться собирать и анализрровать требования, выделять абстракции, строить архитектуру и т.д. Особенно слабость ИИ заметна при отклонении от типовых задач, пока делаешь лендинг или очередную веб-форму все ок, делаешь шаг в сторону (например, пытаешься сделать драйвер для какой-нибудь железки) и начинаются пляски с бубном. Поэтому храдскиллы не просто нужны, а нужны очень сильные инженеры с мощными хардами, иначе скорость работы системы будет падать на этапе принятия решений

Помните в детстве была шутка "А ты купи слона...", вот сейчас точно такой же перфоман наблюдается в мире АйТи, только идея немного другая "А ты пройди собес...", люди пытаются донести простую информацию - не работает такой подход. А им опять "Ты посмотри новую порцию того как проходить собес и пройди собес".

Коммуникация микросервисов При проектировании микросервисов нужно научиться выделять две вещи: обязанности сервиса (по сути определяют границы) и принципы коммуникации микросервисов друг с другом. На последнем семинаре мы подробно обсудили, как строить требования к сервису, чтобы сохранять высокую связность внутри сервиса. Следующий шаг - выстроить грамотную коммуникацию. Подробно этот вопрос разобран в лекции Основы коммуникации микросервисов (нужна подписка №1 на soer.pro). Некоторые вещи из лекции, которые будут полезны: - Высокая когезия (high cohesion) - реализуется через проведение границ сервисов; - Низкое зацепление (low coupling) - реализуется с помощью асинхронной коммуникации или промежуточных абстракций (например, сервисов-координаторов). Аспекты проектирования, которые нужно рассмотреть: 1. Границы сервиса - не по командам, а по бизнес-задачам (bounded context). При этом команды должны распределяться по контекстам. 2. Использовать SRP при определении границ сервиса, так чтобы у сервиса была только "одна причина" меняться. Здесь есть сложность - понятие "одна причина" имеет несколько трактовок: - одна причина - это когда у сервиса один владелец, которые принимает решение о изменения (или "один актор"); - одна причина - это когда есть бизнес задача и причина связана с этой задачей; - одна причина - это только те изменения, которые сохраняют высокую когезию. Обычно споры возникают из-за того, что пытаются учесть сразу все три варианта. Поэтому нужно договориться, что считать "одной причиной". Я обычно предлагаю отталкиваться от актора. 3. Выбор между: Синхронная коммуникация vs асинхронная коммуникация. Тут довольно сложный вопрос. Который зависит от того насколько сложные транзакции нужно реализовывать в системе, а так же насколько важна атомарность. Для сложных (длинных) транзакций часто выбирают асинхронные решения, для простой коммуникации, где нужна скорость берут синхронный вариант (например, через gRPC). Синхронными транзакциями проще управлять, их легко строить, но они более "хрупкие" и склонны повышать зацепление. Но дают способ обеспечить атомарность операций через блокировку ресурсов (наприме, 2PC), высокую скорость и стриминг (через gRPC). Асинхронные транзакции сложнее с технической точки зрения (требуют инфраструктуру), осложняют поиск корневой причины в случае сбоя, создают дополнительные "точки отказа", но при этом повышают "жизнеспособность" системы, уменьшают зацепление. Часто используются с SAGA или Outbox паттернами. Поэтому для простой и быстрой коммуникации я бы выбрал синхронный вариант, с координаторами (это позволяет управлять зависимостями, а значит зацеплением). Для больших проектов, где много команд, скорее всего взял бы гибрид синхронно там где важна скорость + асинхронно там где сложные распределенные транзакции (тут главное не проморгать распределенный монолит). 4. Идемпотентность - нужна в большинстве случаев, чтобы реализовывать стратегии с повторными вызовами. Про проектировании требуется отдельно посмотреть на метод POST, он не идемпотентен от слова "совсем", поэтому требуется предусмотреть ключ идемпотентности (обучно в заголовке). Идемпотентность обязательна для финансовых и необратимых операций. Для остальных - оцените, оправдывает ли риск повторного вызова стоимость реализации.

Для меня наша команада внутри сообщества - самая крутая, но всегда интересно услышать мнение людей, которые посмотрят на ситуацию непредвзято. Недавно я предлагал Декабристу, который критикует Соер Клуб, прийти и посмотреть своими глазами как проходят созвоны, насколько хороший технический уровень у ребят, оценить какая атмосфера в сообществе. Декабрист отказался, но приглашением воспользовался один из подписчиков моего канала - Григорий. Его отзыв привожу ниже:

Полный отзыв о прошедшей групповой встрече. Созвон оказался супер интересным. Больше всего поразило, как люди дискутировали, максимально уважительно, без токсичности, даже когда мнения по архитектуре расходились полярно. Прикольно слушать было, как с Булатом спорили про отделение модерации от контента - это как по мне очень хорошая практика(по крайней мере меня так учили, дай людям направление, а дальше пусть сами постигают в процессе изучения и споров). Но ИМХО, слишком долго сидели на защите первого участника, он объяснял свою схему минут тридцать, я просто привык в вузе к жесткому таймингу(преподаватель ставит таймер обычно) - не успел изложить суть за отведенное время - сам виноват, идем дальше. С другой стороны, из-за отсутствия лимита, решение тех кто хотел, удавалось разобрать со всеми нюансами. В целом атмосфера очень заряженная, вовремя модерируется и вносится умная мысль, и выбор лучшего решения голосованием в конце я вообще обалдел, то есть нужно всех убедить, а там люди оказались самые разные, и все очень заряженые. Хотя ощутил очень знакомый вайб когда всплыло что кто-то не так сделал ДЗ и делал его срочно во время голоса других участников 🤣. Мой вердикт, своих денег  стоит учитывая что я застал лишь малую часть, а ведь там теория и сам процесс решения дз.

А что с позиции практики? Пример выше показывает, что "правильные" (с позиции абстрактной теории) ответы не очень важны, в реальных задачах куда важнее ответить на вопрос: "А что это нам дает?" и вот здесь я разделяю мнение, что нужно делать не RESTful, а RESTlike решения, взяв лучшее от REST, но без фанатизма. В лекции сделан упор на практические решения, используемые при построении API, которые нормально живут на 3 уровне модели зрелости Ричардсона и по сути не являются чистым REST.

Ресурс - это абстрактное понятие, которое у Филдинга указано как "Any information that can be named can be a resource", т.е. он помогает связать произвольную информацию с именем ресурса. Оригинальный текст диссертации:

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g., a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

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

На курсе по Микросервисам начали рассматривать построение API, сейчас вышла классная лекция в которой рассмотрели вопросы проектирования и документирования API на базе REST. Часто бывает так, что вроде понимаешь какую-то концепцию, а когда нужно рассказать начинаешь путаться и ошибаться в мелочах. Это как раз про REST, есть четыре вопроса, которые легко покажут насколько хорошо человек понимает концепцию: - Что такое "рерсурс" в концепции REST? - О каком "состоянии" идет речь в REST? - Для чего нужны представления в REST? И мой любимый: - Что такое HATEOAS и какой уровень Richardson Maturity Model с практической точки зрения самый оптимальный? Последний вопрос дискуссионный и хорошо показывает насколько человек на практике понял архитектуру REST.

Давайте раскидаем по фактам: 1) "Изменения в одном почти всегда влекут изменения в соседних" и "как ты будешь добавлять новый функционал". Это, пожалуй, редфлаг номер один, этот аргумент в разных вариациях встречается настолько часто, что у меня давно заготовлен типовой ответ: никак. Если вы хотя бы раз использовали сторонние сервисы (оплата, авторзация, видео и т.д.), то знаете, что их интерфейс строится по принципу "конструктора", т.е. сложное поведение достигается не через добавление новых методов , а через построение композиции вызовов (это и есть основная задача проектирования), если бы автор комментария был прав, то мы бы не смогли разрабатывать никакие новые фичи, если используем внешние сервисы. Идея о том, что меняются только "близкие" сервисы - это признак очень кривой декомпозиции, значит автор проводит границу сервиса игнорируя когезию. В противном случае у него бы получилась нормальная декомпозиция сервисов, которые через свои интерфейсы позволяют составлять сложные композиции. Я регулярно встречаю команды, где буквально на каждый чих создается новый метод, или меняются существующие, всем плевать на версионирование, раздельную публикацию сервисов, изолированне тестирование и т.д. Все тестируется одним скопом, разворачивается так же все вместе, и конечено же это распределенный монолит. 2) "То что у тебя все еще открывается интерфейс или страница логина, но в сам сервис ты не можешь зайти, потому-что, например отлетела авторизация - как бы не особо делает весь твой сервис рабочим." Если вы думали, что неумение проектировать это единственный недостаток моих оппонентов, то вот вам еще один - неумение анализировать. У автора комментария все смещалось в кучу, он выделил систему, как отдельный сервис, который неожиданно упал. Естественно такое возможно только в учебных проектах, где система авторизации и аутентификации может быть представлена одним сервисом. Но в реальных проектах авторизация - это целый набор сервисов (SSO, сервис токенов, сервис доступов/политик), в реальности эти сервисы задублированы и используются автоматические способы переключения между ними (Circuit Breaker). Исходя из представления "авторизация - это один сервис", можно легко сделать вывод о уровне подготовки наших оппонентов. Хочется еще раз сказать, ребята, давайте каждый будет заниматься тем делом, которым умеет? Потому что пока вы поражаете своей дремучей безграмотностью.