Микросервисы на самом деле самый сложный архитектурный подход для изучения. Основная проблема в том, что этот подход не изучается в соло режиме. Тут либо нужно учиться делать архитектуру в команде, либо не делать вовсе. Иначе вместо микросервисов можно научиться делать распределенный монолит и потом искренне не понимать почему профи смеются над вашим "дизайном".

Проблема в том, что согласно закона Конвея ваша система будет копировать структуру команды, а если вся команда - это "я", то вы просто не сможете понять в чем суть микросервисов. Пока у вас одна голова - связность будет в вашей голове, а не в API

По итогу в своей "микросервисной" системе будете ловить вот такие штуки:

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

- упал один микросервис - потеряли всю функциональность, это нарушение основного принципа "все микросервисы должны быть независимы";

- сервисы шарят общие данные - совсем детская ошибка, когда люди нарушают принцип "database per service";

- сервисов много, а НФТ одинаковые, возникает вопрос почему не монолит?

- учебная система на практике не держит нагрузку. Это самая больная боль, когда люди не понимают сути своих данных и не умеют считать нагрузку, делают систему по наитию.


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

Антон, если ты взялся играть роль правдоруба, то добивай до конца. Какие конкретно у тебя претензии к нетворкингу?

И да, нужно объяснять! Потому что "поркомендую на закрытые вакансии" это не про нетворкинг, а про не очень хороший маркетинг.

Сегодня нетворкинг - 35-40% найма и если ты намекаешь, что этот подход не работает (может он только у тебя в сообществе не работает, не думал об этом?), то расскажи почему, иначе в чем смысл накидывать на вентилятор?

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

Все больше причин становиться software engineer (соером) 👇👇👇

Новая идея к модели «программист vs инженер»

Что я не сказал в эфире про переход «программист → инженер»

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

«ОК, я понял, что нужно стать инженером. А как это сделать на практике?»

В эфире я говорил больше о том, кем нужно быть, чем о том, как туда дойти. Закрою этот пробел сейчас.

Главный сдвиг — не в инструментах. В привычках.

Программист берёт задачу, открывает IDE, начинает писать. Инженер берёт задачу, открывает текстовый файл и пишет: что должно получиться, для какого пользователя, какой критерий «готово».

Это банально. Но 90% разработчиков этого шага не делают. Идут сразу в код. И потом полдня крутят решение, потому что само решение размытое.

Один простой эксперимент. Возьми ближайшую задачу из бэклога. Не садись за код. Открой текстовый файл и напиши три абзаца:

Что конкретно должно получиться?

«Форма регистрации, валидирующая email, имя и пароль, отправляющая на бэкенд POST-запросом» — это ответ.
«Сделать форму» — не ответ.

Для кого. Какие у пользователя ограничения, какой контекст.
Что я считаю «готово». Какие крайние случаи покрыты, какие не покрыты сознательно, какой минимум интерфейса считается приемлемым.

После этого иди в код. И заметь, насколько быстрее закроешь задачу. Мозг уже распаковал её до того, как ты сел печатать.

Самый простой переход. Без новых фреймворков. С одной новой привычкой.

В записи эфира разбираю остальные практики и конкретные промпты под каждую. Закрываю доступ 11 мая.

https://result-ai.tech/rec_web_aideveloper?utm_source=tg_channel&utm_medium=post&utm_campaign=result_ai

Никита, могу тебе подогнать приглашение на наш созвон по архитектуре микросервисов. Напиши в личку, без иронии.

Послушаешь, реально может отзыв дашь, а не ту ебань что ты постоянно пишешь. 👇👇👇

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

P.S. Все пути ведут в соерклуб.

Хорошо, что у нас есть ИИ, который умеет определять полемические приемы:

ты реально из всего текста докопался только до слова "нетворкинг" в конце? Проигнорировав контекст полностью.
и серьезно думаешь, что кто-то пойдет на дебаты после этого?

1. Риторический вопрос
«ты реально из всего текста докопался только до слова "нетворкинг" в конце?»
Это не запрос информации, а выражение негодования и указание на избирательность внимания оппонента.

2. Прием «приписывание намерения» (straw man с натяжкой, скорее обличение)
Собеседник утверждает, что вы «проигнорировали контекст полностью» — это интерпретация вашего действия, которая выставляет вас в невыгодном свете.

3. Сарказм / насмешка
Интонационно фраза «Проигнорировав контекст полностью» звучит как обличительная насмешка над поверхностностью вашего разбора.

4. Аргумент к последствиям (argumentum ad consequentiam)
«и серьезно думаешь, что кто-то пойдет на дебаты после этого?» — утверждается, что ваше поведение (вырывание слова из контекста) приводит к тому, что с вами никто не захочет дебатировать. Тем самым ваша позиция объявляется неэффективной/ошибочной из-за её негативных последствий.

5. Отказ от предметного спора в пользу оценки стиля
Вместо того чтобы продолжить дискуссию по сути вашего исходного текста, оппонент сосредотачивается на том, *как* вы прочитали текст (одно слово vs контекст) — это переход на метауровень, часто используемый для уклонения от содержательных возражений.

6. Эмоциональная атака (близкая к ad hominem, но мягче)
Фраза строится как упрек лично к вам («ты реально докопался…», «ты думаешь…»), что снижает дистанцию и переводит обсуждение в личностную плоскость.

Что не использовано в этой реплике:
- Приведение контрпримеров.
- Цитирование вашего текста.
- Логическое опровержение вашего тезиса (поскольку ваш тезис вообще не обсуждается — обсуждается лишь ваш метод чтения).

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

Оппоненты продолжают меня давить "интеллектом". Ниже дам ответ

Давайте раскидаем по фактам:

1) "Изменения в одном почти всегда влекут изменения в соседних" и "как ты будешь добавлять новый функционал".

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

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

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

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

2) "То что у тебя все еще открывается интерфейс или страница логина, но в сам сервис ты не можешь зайти, потому-что, например отлетела авторизация - как бы не особо делает весь твой сервис рабочим."

Если вы думали, что неумение проектировать это единственный недостаток моих оппонентов, то вот вам еще один - неумение анализировать.

У автора комментария все смещалось в кучу, он выделил систему, как отдельный сервис, который неожиданно упал. Естественно такое возможно только в учебных проектах, где система авторизации и аутентификации может быть представлена одним сервисом. Но в реальных проектах авторизация - это целый набор сервисов (SSO, сервис токенов, сервис доступов/политик), в реальности эти сервисы задублированы и используются автоматические способы переключения между ними (Circuit Breaker).

Исходя из представления "авторизация - это один сервис", можно легко сделать вывод о уровне подготовки наших оппонентов.

Хочется еще раз сказать, ребята, давайте каждый будет заниматься тем делом, которым умеет? Потому что пока вы поражаете своей дремучей безграмотностью.

На курсе по Микросервисам начали рассматривать построение API, сейчас вышла классная лекция в которой рассмотрели вопросы проектирования и документирования API на базе REST.

Часто бывает так, что вроде понимаешь какую-то концепцию, а когда нужно рассказать начинаешь путаться и ошибаться. Это как раз про REST, есть четыре вопроса, которые легко покажут насколько хорошо человек понимает концепцию:

- Что такое "рерсурс" в концепции REST?
- О каком "состоянии" идет речь в REST?
- Для чего нужны представления в REST?

И мой любимый:

- Что такое HATEOAS и какой уровень Richardson Maturity Model с практической точки зрения самый оптимальный?

Последний вопрос дискуссионный и хорошо показывает насколько человек на практике понял архитектуру REST.

* для доступа к лекции нужна подписка №1, приобрести можно на сайте soer.pro

Ресурс - это абстрактное понятие, которое у Филдинга указано как "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, а про практическую необходимость показать, как именно будет представлен ресурс в реальной системе.

А что с позиции практики?

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

В лекции сделан упор на практические решения, используемые при построении API, которые нормально живут на 3 уровне модели зрелости Ричардсона и по сути не являются чистым REST.

Для меня наша команада внутри сообщества - самая крутая, но всегда интересно услышать мнение людей, которые посмотрят на ситуацию непредвзято.

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

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

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

Коммуникация микросервисов

При проектировании микросервисов нужно научиться выделять две вещи: обязанности сервиса (по сути определяют границы) и принципы коммуникации микросервисов друг с другом.

На последнем семинаре мы подробно обсудили, как строить требования к сервису, чтобы сохранять высокую связность внутри сервиса. Следующий шаг - выстроить грамотную коммуникацию. Подробно этот вопрос разобран в лекции Основы коммуникации микросервисов (нужна подписка №1 на soer.pro).

Некоторые вещи из лекции, которые будут полезны:

- Высокая когезия (high cohesion) - реализуется через проведение границ сервисов;
- Низкое зацепление (low coupling) - реализуется с помощью асинхронной коммуникации или промежуточных абстракций (например, сервисов-координаторов).

Аспекты проектирования, которые нужно рассмотреть:

1. Границы сервиса - не по командам, а по бизнес-задачам (bounded context). При этом команды должны распределяться по контекстам.

2. Использовать SRP при определении границ сервиса, так чтобы у сервиса была только "одна причина" меняться.

Здесь есть сложность - понятие "одна причина" имеет несколько трактовок:

- одна причина - это когда у сервиса один владелец, которые принимает решение о изменения (или "один актор");

- одна причина - это когда есть бизнес задача и причина связана с этой задачей;

- одна причина - это только те изменения, которые сохраняют высокую когезию.

Обычно споры возникают из-за того, что пытаются учесть сразу все три варианта. Поэтому нужно договориться, что считать "одной причиной". Я обычно предлагаю отталкиваться от актора.

3. Выбор между: Синхронная коммуникация vs асинхронная коммуникация.
Тут довольно сложный вопрос. Который зависит от того насколько сложные транзакции нужно реализовывать в системе, а так же насколько важна атомарность. Для сложных (длинных) транзакций часто выбирают асинхронные решения, для простой коммуникации, где нужна скорость берут синхронный вариант (например, через gRPC).

Синхронными транзакциями проще управлять, их легко строить, но они более "хрупкие" и склонны повышать зацепление. Но дают способ обеспечить атомарность операций через блокировку ресурсов (наприме, 2PC), высокую скорость и стриминг (через gRPC).

Асинхронные транзакции сложнее с технической точки зрения (требуют инфраструктуру), осложняют поиск корневой причины в случае сбоя, создают дополнительные "точки отказа", но при этом повышают "жизнеспособность" системы, уменьшают зацепление. Часто используются с SAGA или Outbox паттернами.

Поэтому для простой и быстрой коммуникации я бы выбрал синхронный вариант, с координаторами (это позволяет управлять зависимостями, а значит зацеплением). Для больших проектов, где много команд, скорее всего взял бы гибрид синхронно там где важна скорость + асинхронно там где сложные распределенные транзакции (тут главное не проморгать распределенный монолит).

4. Идемпотентность - нужна в большинстве случаев, чтобы реализовывать стратегии с повторными вызовами.
Про проектировании требуется отдельно посмотреть на метод POST, он не идемпотентен от слова "совсем", поэтому требуется предусмотреть ключ идемпотентности (обучно в заголовке).

Идемпотентность обязательна для финансовых и необратимых операций. Для остальных - оцените, оправдывает ли риск повторного вызова, стоимость реализации.

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

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

Стал часто встречать подобные комментарии: "В эру AI будущее за хардскиллами, лол"

Я много занимаюсь созданием оркестрируемых агентских систем, есть опыт использования ИИ в разных задачах. И чем дальше, тем больше убеждаюсь, что Human in the loop пока единственный способ поднять качество работы ИИ до нужного уровня.

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

Особенно слабость ИИ заметна при отклонении от типовых задач, пока делаешь лендинг или очередную веб-форму все ок, делаешь шаг в сторону (например, пытаешься сделать драйвер для какой-нибудь железки) и начинаются пляски с бубном. Поэтому храдскиллы не просто нужны, а нужны очень сильные инженеры с мощными хардами, иначе скорость работы системы будет падать на этапе принятия решений

Удивляет, что многие воспринимают ИИ как конкурента и потенциальную угрозу для своего трудоустройства.

На мой взгляд ИИ наоборот — огромное окно возможностей, которое возвращает нас во времена, когда можно было в соло создавать крутые проекты.

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

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

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

Так что одна дверь закрылась, но взамен открылась тысяча других

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

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

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

У многих разработчиков появилось беспокойство за свое будущее. Это связано с тем, что сейчас люди выполняют роль конвейера между LLM и реальным проектом. Типичный цикл: получил таск, скопировал в LLM, результат скопировал в проект. Закономерно, что ценности в таком труде нет, и бизнес хочет автоматизировать эти процессы, передав «перекладывание кода» ИИ-агентам.

Бизнесу интересно нанимать людей для задач, которые ИИ пока не решает. В ближайшем будущем такие задачи будут связаны не со способностью генерировать код (LLM неплохо справляется с изолированными фрагментами уже сейчас), а с умением анализировать и понимать проект, корректно выполнять декомпозицию, разбивать задачи для ИИ, владеть технологическим стеком, работать с инфраструктурой и проводить границы между компонентами. Это коротко называют «инженерный стек».

Отсюда появился термин «ИИ-инжиниринг» — направление, в рамках которого инженеры-программисты ведут разработку проекта, используя LLM и агентские системы. Процессы автоматизируются с помощью оркестрируемых агентов, а люди выполняют роль валидаторов результатов и аналитиков требований.

Разрыв между навыками написания кода и полноценными инженерными навыками оказался огромным. Проблема даже не в знаниях, которые нужны для ИИ-инжиниринга, а в неумении декомпозировать задачу до уровня, где LLM не теряет контекст, составлять проверяемые требования, исключать противоречия. Сложно менять привычки, уходить от I-shape подходов, перестать ждать от LLM архитектурных решений.

Так как наш клуб изначально заточен на инженерный стек, нам немного проще объяснить и помочь разработчикам скорректировать навыки.

Что нужно делать:

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

2. Работать с требованиями и контрактами. С позиции хронологии этот этап должен идти до архитектуры, но я поставил его вторым, так как считаю важнее сначала наработать архитектурное мышление. Требования — вторая задача, которая помогает выделить главное, найти противоречия и компромиссы. Тут можно оттолкнуться от готовой теории: взять DDD за основу, посмотреть в сторону пользовательских историй и сценариев использования, а также использовать OpenAPI как исполняемый контракт между компонентами.

3. Работать с инфраструктурой. Это ещё одна важная деталь, которая подразумевает уход от узкой специализации к более широкому взгляду. Инженер должен видеть «общую картину» и понимать, как проект работает на всех этапах — от локального запуска до продакшна. База здесь: виртуализация, контейнеризация, СУБД, очереди сообщений, брокеры событий. Без этого LLM будет генерировать код, который работает в изоляции и ломается в реальной среде.

4. Работать с безопасностью. Это вопрос, который, на мой взгляд, останется узкой специализацией ещё надолго. LLM вряд ли доверят принимать решения по разграничению доступа или аудиту. Но базовые принципы знать обязательно: минимальные привилегии, контроль доступа, аудит действий, валидация входных данных на границах контекстов.

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

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

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

Стратегия ближайших лет: кодинг как основная специализация не спасёт от ИИ-агентов. Архитектура, работа с требованиями и умение проектировать систему — вот наша новая «валюта».

Вот я постоянно рекламирую наше сообщество "наш клуб дает то", "наш клуб делает это", а чем он так хорошо этот "наш клуб"?

Для меня это вопрос ответ на который дает мотивацию и силы для дальнейшего движения вперед. Ну правда, клуб ради чего? Чтобы денег заработать? Какой-то сомнительный стимул, есть другие способы заработать, реализовать которые проще (например, консультации).

Мне важно показать как я вижу мир разработки, продвинуть свою "вселенную", если хотите. Мне интересно заниматься клубом потому что он приносит нематериальные результаты - клуб как работающая система, помогающая развиваться его участникам. Очень кайфово видеть результаты и отзывы на проделанную работу.

Обычный подход в подобного рода объединениях - это обучение. Сделал курс, собрал людей, курс закончился и все.

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

Поэтому для меня клуб - это достойное продолжение канала SOER + попытка собрать все в работающую систему, которая помогает участникам развиваться, а не просто накапливать знания.