А первый пост будет как раз про микросервисы 😂

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

И это история, которая подходит под не менее 50% случаев всех переходов.

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

И посмотрим теперь на микросервисы в сравнении с монолитом с позиции экономики:

- это распределенная система, а значит более высокие требования к разработчикам, а значит рост ФОТ

- по той же причине, да еще и вследствие более сложной архитектуры - это плюс 1, 2, 3, n devops-инженеров

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

- а если это в облаке - вот вам счет в N раз больше за аренду мощностей и инфраструктурных компонентов в облаке

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

И все это, прошу обратить внимание, про экономику :)

☝️ Коллеги, хотелось бы напомнить, что у канала есть группа: @ru_arc_chat , в которой тонны полезной информации. Добавляйтесь.

Краткое содержание обсуждений
1. Языки программирования и их история
Lisp и его диалекты (Scheme, Common Lisp) — фундамент для многих современных языков (Ruby, Java).
История сборщиков мусора, роль CLU как предтечи ООП.
Анализ решений Билла Джоя с участием Гая Стила.
Ссылки:
https://github.com/robpike/lisp
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
http://www.pmg.lcs.mit.edu/ftp.lcs.mit.edu/pub/pclu/CLU/3.Documents/clu-history.PDF
2. AWS регион us-east-1 сбои и риск SPOF
Обсуждение масштабного сбоя AWS, затрагивающего DynamoDB, Slack и сервисы мониторинга.
Вопросы Single Point of Failure.
Ссылка: https://health.aws.amazon.com/health/status
3. CI/CD инструменты open source и сравнительный анализ
Основные системы: GitLab CI, ArgoCD, Tekton, Jenkins, Concourse, Woodpecker, Drone, Prow, Gitea/Forgejo.
Tekton признан облачным нативным решением CNCF с лучшей архитектурой в сравнении с Jenkins.
GitLab CI тяжеловесен, ArgoCD имеет проблемы с безопасностью и масштабируемостью.
Ссылка:
https://www.redhat.com/en/blog/tekton-vs-jenkins-whats-better-cicd-pipelines-red-hat-openshift
https://docs.prow.k8s.io/docs/overview/
4. Технический долг и архитектура
Технический долг — экспоненциально растущий риск от несоответствия кодовой базы будущим требованиям.
Основные причины: плохой менеджмент, нехватка ресурсов, недостаточная квалификация команды.
Важна правильная классификация долгов и грамотное управление ими для здоровой разработки.
Практические кейсы демонстрируют, что без качественного менеджмента рефакторинг неэффективен.
5. Моделирование бизнес-процессов и трассировка требований
Структурирование базы знаний: бизнес-процессы, требования, сценарии, операции.
Важность автономности процессов и traceability от требований до кода и обратно.
Обсуждение проблем циклических зависимостей и разбиения команд по доменам.
Используются методы DDD, Event Storming, Wardley Mapping.
Ссылки:
https://less.works/ru/less/framework/coordination-and-integration
https://pmc.ncbi.nlm.nih.gov/articles/PMC8918592/
https://www.volere.org/tools/
6. Разработка локального интернет-магазина: архитектура и платформы
Рекомендация для небольшого магазина — монолит или модульный монолит, чтобы избежать оверхеда микросервисов.
Стек: Laravel, Django, Ruby on Rails, Node.js/Express, PostgreSQL/MySQL.
CMS и SaaS платформы как быстрые стартовые решения: Bitrix, InSales, WooCommerce, OpenCart.
Уточняющие факторы: объем каталога, бюджет, команда, способы оплаты и доставки.
7. Когнитивные аспекты и командная коммуникация
Ограничения восприятия у разработчиков, важность разделения знаний по Bounded Context.
Обмен знаниями через tech talks, репозитории знаний, общие области ответственности по Less.
8. Искусственный интеллект: ошибки, риски, влияние на качество кода
Кейсы ошибок ИИ в медицине, HR, судебных решениях, распознавании лиц.
Рост багов в коде, сгенерированном ИИ, падение стабильности релизов с GitHub Copilot.
9. API-first, контрактное тестирование и архитектурные паттерны
Эволюция представления Use Cases, CQRS, хексагональной архитектуры.
Различия событий и команд в DDD и event-driven системах — дискуссии о владении сообщениями, степенях связанности.
Возможности и ограничения API-first подхода.
10. Телеком и безопасность
Введение «периода охлаждения» для SIM-карт в России.
Обсуждение доступности Telegram и альтернативных платформ (Mattermost, Rocket.Chat, VK).
Идеи децентрализованных мессенджеров и мультипротокольных клиентов (Pidgin, Keet).
11. Инфраструктура и DevOps практики
Выгрузка данных из БД в оперативную память для ускорения гео- и маршрутизационных сервисов (taxi).
Использование CDC (Change Data Capture) с PostgreSQL для синхронизации с низкой задержкой.
Обсуждение рисков SPOF (Single Point Of Failure) в Cloudflare, AWS и уроки их отказоустойчивости.

12. Дискуссии по микросервисам и монолитам
Для команд до ~200 человек вполне эффективен модульный монолит.
Микросервисы оправданы лишь для больших распределенных команд с высокой сложностью.
Ключевые полезные ссылки
AWS инциденты: https://health.aws.amazon.com/health/status
Rob Pike о Lisp: https://github.com/robpike/lisp
История CLU — прототип ООП: http://www.pmg.lcs.mit.edu/ftp.lcs.mit.edu/pub/pclu/CLU/3.Documents/clu-history.PDF
RedHat о Tekton vs Jenkins: https://www.redhat.com/en/blog/tekton-vs-jenkins-whats-better-cicd-pipelines-red-hat-openshift
Prow — CI/CD для Kubernetes: https://docs.prow.k8s.io/docs/overview/
Модель управления рисками (CMU): https://www.sei.cmu.edu/documents/5836/Continuous_Risk_Management_Guidebook.pdf
Feature Flags на Go: https://github.com/thomaspoignant/go-feature-flag
Toggly — блог по feature flags: https://toggly.io/
Less Framework (coordination and knowledge sharing): https://less.works/ru/less/framework/coordination-and-integration
Clean Architecture (Uncle Bob): https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
DDD и Use Cases: https://habr.com/ru/articles/960060/
Архитектурные опции и паттерны: https://architectelevator.com/architecture/architecture-options/
LangFlow (No-code LLM пайплайны): https://github.com/langflow/langflow
Семинар о «грязных проблемах»: https://pmc.ncbi.nlm.nih.gov/articles/PMC8918592/
Влияние AI на HR (arXiv): https://arxiv.org/pdf/2407.20371
Обзор микросервисных интеграций Sam Newman: https://martinfowler.com/bliki/IntegrationDatabase.html
Telegram API шифрование и безопасность: https://core.telegram.org/api/end-to-end
Децентрализованные мессенджеры: https://keet.io/
Open source traffic DB: https://github.com/OpenTransitTools/trafficdb
Канал архитекторов с обсуждениями: https://t.me/ru_arc_chat

Подскажите в комментариях, пожалуйста, какие вам известны коммерчески успешные продукты, созданные ИИ?

Игры, приложения, что угодно, доступное публично и коммерчески успешное (или хотя бы просто публично).

Краткое исследование не позволило мне пока найти ни одного, но, возможно, я не там или не то искал.

Новый кейс в архитектурных этюдах и… это случилось!

Тема «Архитектура управления проектированием в гражданском строительстве»

Буквально, alma mater 🙂

Подключаемся, автор кейса в канале, ответит на любые вопросы, кейс выглядит очень интересным и масштабным, так что не исключаю возможность проведения очного митапа 🙂

https://t.me/archicases/1/8326

Запрос:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.

Сам чатгпт говорит:

Чистый код (поддерживаемый, понятный, реализующий чистую архитектуру и Domain model) код будет нужен, и, более того, ценность «богатой» доменной модели и чистой архитектуры в ближайшие годы, скорее всего, вырастет, а не исчезнет. Изменится не сама идея, а инструменты вокруг неё: как модель описывается, проверяется и как из неё генерируется документация и вспомогательный код.

Spec‑driven / doc‑driven подходы становятся популярными именно потому, что спека становится тем, что «ест» ИИ для генерации кода и тестов.

Одновременно развивается и обратный вектор: инструменты, которые строят спеку и документацию поверх уже существующего domain model (код‑first), чтобы разные команды могли понимать и использовать модель.

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

По мере роста роли ИИ именно строгий и чистый доменный слой становится «опорой» для генерации A/B‑тестов, сценариев, спецификаций API и прочих текстов: модели проще учиться и проверяться на базе кода с явными инвариантами, чем на «грязном» скриптовом зоопарке.

Если упростить: вкладываться в чистый, выразительный доменный код сейчас рационально; горизонт 5–10 лет выглядит как мир, в котором хороший доменный слой — это главный актив, на который уже «навешиваются» ИИ‑спеки, генерация документации и экспериментов, а не наоборот.

Катастрофа была неизбежна | GEO
https://www.youtube.com/watch?v=l_QcNZqUyN4

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

Здесь и:
- Тема урезания скоупа для mission critical
- Придуманные цифры для оценки вероятности отказа
- Бюджетные войны
- Политика
- Пренебрежение безопасностью

В общем, я гарантирую, что будет интересно.

Эпистемическая диверсификация в мультиагентных системах

Некоторое время уже обсуждаю такую мысль в некоторых кругах.

Чтобы использовать курсор нужно забыть как писать код и использовать спек дривен вообще не глядя в код.

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

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

При этом компилируется, работает, все в порядке…

Оно даже часто набор докер-файлов сгенерить не может так, чтобы специалист по делу не придрался.
Все работает, но специалист видит, в каком случае упадет и вероятность этих случаев стремится к 100% по мере эксплуатации.

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

Я где-то месяц размышлял на эту тему, - ну мы же видим, мы же знаем, мы же можем.

И сегодня, кажется, понял. В мультагентной системе разработки агенты должны обучаться до достижения требуемого уровня (senior, middle, junior) разработчика, но на немного разных источниках. Так, как обучаются люди. У людей разная траектория развития и разный опыт. Это делает живую команду устойчивой и сильной.

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

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

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

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

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

Почему микросервисы – это сложно?

Это диаграмма 2018-го года. Обратите внимание на прямоугольники ближе к центру и дальше от него.

Чем дальше – тем конкретнее, лепестки – конкретные технологии. И с 2018-го года часть из них изменилась. Но то, что ближе к центру – остается стабильным.

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

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

Почему agile-это сложно?

Презентация 2017-го года, разъясняющая принципы agile-манифеста. Публично в первый раз выкладываю, менять не стал ничего, все по-прежнему актуально, хоть мы и продвинулись вперед.

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

В чем ценность этой презентации?

Agile не любят не за сами принципы, а за «операции под чужим флагом», когда называя что-то agile устраивали разработчикам потогонку, просто сократив 1 месяц до 2 недель, не меняя толком процессы, инженерию.

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

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