15 февраля впервые в России (😅) представлю выведенный мной Принцип каскадного снижения связанности! 🚀

Описание и тезисы первой версии доклада (в 🇰🇿) публиковал ранее.

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

Обновлённую версию доклада расскажу 15 февраля в рамках онлайн-конференции Analyst Marathon #12:
https://yangx.top/Analyst_maraphon/323
(кому нужны промокоды и скидочки (их ограниченное количество) — пишите в комментарии или в личку)

🌌🌌🌌🧑‍🚀

Очередное сообщение в корпоративном чатике о том, что "* * * прилёг" и теперь у нас не работает часть систем, застало меня за чтением советского (⭐️!) ГОСТа 27.002-89 "НАДЕЖНОСТЬ В ТЕХНИКЕ".

1.1. Надежность
Reliability, dependability
1.2. Безотказность
Reliability, failure-free operation
1.3. Долговечность
Durability, longevity
1.4. Ремонтопригодность
Maintainability
1.5. Сохраняемость
Storability

ничего не напоминает? 😏

Видимо верно говорят, что сейчас нет ничего нового, а есть только советские разработки на бумаге, до которых сейчас наконец-то дошли руки 😉

ГОСТ предлагает чёткие определения понятий и классификацию состояний объектов и видов отказов, а также конкретные формулы расчета вероятности отказов.
В ГОСТе говорится о сложных технических объектах, которым свойственен износ и срок наработки. В этом плане, наверное нельзя один к одному перенести методики расчета на программные компоненты распределенных систем (наверное вы уже догадались, что я к этому клоню), т.к. те же наши всеми любимые микросервисы падают скорее не из-за временно́го износа, а по причине внесения изменений или внешних факторов (хотя наверное это всё тоже можно как-то наложить на шкалу времени и придумать формулы — было бы интересно попробовать 🤔).

Но всё чаще в публичных постмортемах ⚰️ крупных сбоев первопричиной становится выход из строя как раз физического оборудования (недавно где-то было про выгоревший порт коммутатора), что как раз поддаётся прогнозированию и расчётом по формулам из прошлого тысячелетия 📜

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

Не факт, что на практике это было бы целесообразно для большинства проектов, но если от отказа вашей программно-аппаратной системы много чего критичного зависит.. хотя наверное вы уже и так тогда знакомы с данным ГОСТом (собственно почему я его и изучал 🙃).

В целом, возвращаясь к отказоустойчивости именно софта: если у вас достаточно много статистических данных по различного рода отказам — ради интереса можно попробовать применить ГОСТовские формулы для расчета различных показателей отказоустойчивости (и наложить потом результаты расчетов на реальные факты и время отказов 👩‍🎓).

И в любом случае, независимо от накопленной статистики, я советую всем проводить учения и тесты своих систем на отказоустойчивость и восстановления после сбоев. У меня есть отдельная статья про проектирование отказоустойчивости и её измерении: https://habr.com/ru/articles/764904/

ГОСТ

Всем стабильных систем 🌀, и всех с наступающим 💗!

[пятничный пост]

Вчера в беседе внезапно вывели метрику стабильности и отказоустойчивости систем ))

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

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

Получилась вот такая метрика стабильности наших систем, и хороший показатель этой метрики 🕶

Принял участие в записи аудио-подкаста Цифровые голоса, побеседовали про мою любимую тему — Архитектуру как код 😊
https://rutube.ru/video/a0948a611c85b4f284f8e1695099815c/

Тайминг и этапы беседы по мнению YaGPT 🤖:

00:00:05 — Введение в архитектуру как код
00:00:39 — Что такое архитектура как код
00:02:49 — Преимущества архитектуры как код
00:04:48 — Инструменты для архитектуры как код
00:06:07 — Тестирование архитектуры
00:08:06 — Документирование и создание новых архитектур
00:09:15 — Примеры тестов
00:11:10 — Проектирование нового проекта
00:12:09 — Архитектуры и итерации
00:12:59 — Повторное использование элементов
00:15:29 — Нотации и инструменты
00:17:03 — Языки и инструменты
00:20:31 — Применение AaC в проектах
00:22:59 — Проблемы с асинхронной связью
00:23:58 — Внедрение автоматизации
00:25:09 — Рекомендации для начинающих
00:25:47 — Тестирование архитектуры
00:26:47 — Заключение

🎧🎧🎧

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

В целом, термин "метадокс" уже хорошо гуглится, к примеру краткое видео с его определением от одного из авторов: https://www.youtube.com/watch?v=b9Nt_Ipo230

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

Думаю, всё будет ясно на примере.

В вершины базового метадокса (треугольника) поместим 3 основных разных подхода к программированию на текущий момент (всё сугубо только на мой субъективный взгляд):
Классическое программирование — Искусственный Интеллект (ИИ) — Low Code.

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

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

🔼Классическое программирование с оттенком ИИ — имхо, это таблицы решений, которые с одной стороны максимально чёткие в плане классического программистского если-то, с другой — чуть приближены к математической магии машинного обучения (к примеру, к тем же деревьям решений)

Идём дальше.

🔼Классическое программирование с оттенком Low Code — это различные DSL, т.е. языки программирования приближенные и заточенные под конкретную доменную область. Этакий промежуток между универсальным языком программирования и LowCode'ом )

🔼И наконец, классическое программирование с оттенком классического программирования — на мой взгляд, это функциональщина ) Оргазм любого тру хардкор олдскул программиста )
〰️〰️〰️〰️

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

🔼ИИ с оттенком ИИ — это наш всеми ожидаемый AGI: сильный (или общий) ИИ. Технологическая сингулярность, точка невозврата и вот это вот всё 👁

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

🔼ИИ с оттенком Low Code — тут пока сложно, возможно соответствующих ярких представителей категории пока ещё и не изобрели (как и рядом стоящих Low Code с оттенком ИИ).. Я бы сюда отнёс в целом программирование с помощью LLM-моделей (всякие копилоты): ты ей промт на белковом человечьем, а она тебе в ответ код. В таком подходе программировать можно и не уметь, но чуть-чуть (Low) придётся.
〰️〰️〰️〰️

И последний треугольник второго уровня (коих может быть сколько угодно) — Low Code.

🔼Начнём с трудного: Low Code с оттенком ИИ — как и писал выше, с одной стороны я не вижу тут одного яркого представителя или технологии (возможно это значит что ниша ещё не до конца сформирована). С другой — в свои Low Code платформы не пытается встроить ИИ сейчас только ленивый: мы установили одну хайповую технологию в другую хайповую технологию 🏎. Пусть тут будут эти многочисленные ИИ-конструкторы, якобы создающие прототипы CRM-систем по экспорту задач из трелло.

🔼Low Code с оттенком Low Code — ещё одна недостижимая точка, мечта всех маркетологов — No Code 🤤

🔼Low Code с оттенком классического программирования — различные BPMN-движки, прокидывающие мостик между наглядностью визуализации и суровыми энтерпрайзными json'о-перекладывателями микросервисами.
〰️〰️〰️〰️

Вывода не будет (пока). Предлагаю вместе порассуждать над вариантами вершин всех треугольников, покидать альтернативы.

Прежде чем продать понять что-то ненужное сложное, нужно сначала купить описать что-то сложное
🧠

Ранее писал о нашем процессе или фреймворке, которым подходим к проектированию ИТ-продуктов и социо-технических систем (https://yangx.top/rsa_enc/359), ➕ и в прошлом посте про академию (⬆️) есть материалы по всем этапам процесса.

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

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

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

Технология «Карта гипотез» для создания стратегий бизнеса и личностного роста. Метод позволяет связать цели бизнеса и конкретные задачи исполнителей через гипотезы-идеи.
Аспекты:
• как преодолеть разрыв между потребностью качественной стратегии и рамками возможностей руководителей создавать гениальные стратегии
• специфика и возможности технологии «карта гипотез»
• примеры разработки стратегий на реальных кейсах

Полную программу конференции прикреплю комментарием, также она доступна по ссылке:
Лучшие бизнес-практики для адаптации и устойчивости бизнеса в текущих реалиях

Участие бесплатное по предварительной регистрации.

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

👍

Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎

Теперь и в виде статьи на Хабре! Встречайте, выведенный и сформулированный мной Принцип каскадного снижения связанности: https://habr.com/ru/articles/894766/

Если понравится статья — буду рад вашим ➕⬆️ , это позволит увеличить охват читателей статьи ☺️

Весенний сезон оффлайн и онлайн выступлений выдаётся очень насыщенным 🍃

Сегодня я выступил в Торгово-промышленной палате. А уже завтра на next conf расскажу чуть адаптированный для системных аналитиков свой доклад про тестирование архитектуры as Code:
Переведём архитектуру в as code и проверим её качество тестами!

В апреле на конференции Systems Design сделаю по этой же теме уже более подробный мастер-класс с написанием кода тестов на архитектурные принципы:
Тестирование архитектуры программного обеспечения

И в Екатеринбурге на Dump расскажу об инструментах для измерения архитектурных метрик на примере проверки своего принципа проектирования:
Принцип каскадного снижения связанности и его проверка измерением архитектурных метрик

Буду рад всех видеть и со всеми пообщаться ❤️☺️

🥳 Сегодня нам исполнилось 13 лет!

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

Мы хотели успеть оформить результаты сделанного нами на странице Академии и успели https://byndyusoft.com/academy. Собрали в одном месте две книги и методы, которые выводят на новый уровень создание стратегии, анализ и проектирование социотехнических систем. Впереди еще много планов, например, вторая книга про Антихрупкость в IT, которая объединит знания трех основателей компании https://yangx.top/byndyufeed/451.

Мы благодарны сообществу инженеров, аналитиков, управленцев за поддержку! И, конечно, благодарны нашим заказчикам за желание создавать сильные решения, что дает нам возможность делать великолепные инженерные конструкции в IT.

Всем спасибо и нас с праздником 🥳

Всем привет! За последний месяц я слетал в отпуск (на турнир по шахматам с кубиками 🎲) и выступил на четырёх конференциях 😅☺️

Как уже неоднократно писал и говорил — на это дело меня заряжают и драйвят ваши отзывы! Отзывы читателей и слушателей 💕. Всё чаще и чаще ко мне подходят незнакомые (а отходят уже знакомыми) люди, говорят что слушали/читали мои доклады/статьи, благодарят и рассказывают что у них удалось и не удалось внедрить у себя на проектах из моих материалов. Кто-то просто подходит пожать руку и сказать спасибо — это невероятно приятно 🤝🥰

Приведу пару отзывов с одной из конференций:

Это был самый отличный доклад. Сохранила все ссылки. Динамичный, интересный, полезный. Обаятельнецшмй автор. Актуальные задачи. Короткое время разраьотки. Не перегружено, в тоже время есть ссылки на гит и статьи. Респект! Используем и Кубернетес, и схемы в виде кода. Прямо очень понравилось. Спасибо вам, вы сделали мой день :)

Чувствуется высокий уровень экспертизы докладчика. Очень понравилось

Бывает, конечно, и такое — куда без этого (иначе было бы подозрительно 😅):

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

Особенно хочу отметить Максима Цепкова — он выступает сам и публикует конспекты лучших докладов конференций. И уже не впервые мне приятно у Максима читать про свой доклад ☺️

На конференциях я рассказывал про наши продвижения в понимании принципа каскадного снижения связанности (КСС) (ссылка на статью) и обновлениях в репозитории AaCT.
Пока совсем кратко:
💡 выпустили первую версию анализатора архитектур, который строит отчёт и выдаёт архитектурные метрики (пока совсем базовые):
https://github.com/Byndyusoft/aact/blob/main/src/analyzer.ts
💡 пример его использования можно посмотреть в новом переработанном и более глубоком тесте на соблюдение принципа КСС: https://github.com/Byndyusoft/aact/blob/main/test/ccr.test.ts

Обязательно напишу отдельно про обновления подробнее и выложу видео с выступлений, когда они появятся. А пока можно полистать слайды — закину файл комментарием к посту (про метрики и тест — с 39го слайда).

И пару слов про дальнейшие планы:
🎤 24 мая выступлю в Челябинске на UWDC
🎤 6 июня — на МТС True Tech Day в Москве
А между этими датами буду как организатор на CodeFest, TechLeadConf и CTO Conf в Новосибирске и Москве.
Если доберётесь — буду очень рад всех увидеть 😘🥰!

Всем весны! 🍀

После одного из выступлений мне задали очень хороший вопрос — применим ли мой принцип каскадного снижения связанности только в софте (микросервисах и монолитах) или в целом и в других сферах жизни?

Скажу честно — к такому вопросу я готов не был 😅. Сходу на ум пришёл пример с организацией разделения компании на отделы. Представим, что в некоем офисе сотруднике разделены на отделы и у каждого отдела свой этаж (или комната). При этом предполагается, что коммуникаций между сотрудниками отдела будет больше, чем с коллегами из соседних отделов — что логично, проще спросить у Васи, который за соседним столом, чем идти в другой отдел по лестнице. Ничего не напоминает? 🙂 Те же связанность (coupling) и прочность (cohesion). Прочные и частые коммуникации внутри отдела, при более редких внешних.
При этом, если приходится постоянно бегать между этажами, а взаимодействий с соседом по кабинету почти нет — явно эффективность процессов страдает (связанность выше прочности), и это скорее всего сигнализирует о неправильном распределение сотрудников по отделам (и/или процессов и ответственности между отделами).

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

На мой взгляд, получился неплохой пример из жизни 😌

А сегодня хочу ещё порассуждать о химии, в которой я вообще ни разу не специалист 😅.
Как будто бы при объединении атомов в молекулы, а молекул в более сложные структуры — работает всё тот же принцип, что наверное логично 🙂
С массивными атомами всё вроде понятно — у них сильная внутренняя прочность (упрощая — большое количество протонов и электронов), поэтому они легко объединяются в сложные молекулы с множеством связей с другими атомами (связей с другими атомами всё равно меньше, чем связей частиц внутри).
Посмотрим на лёгкие атомы — водород (упрощая — 1 внутренняя связь) и бериллий (4 внутренние). Атом водорода в молекулах имеет всегда только одну внешнюю связь (в молекулы воды каждый из двух атомов водорода связан с единственной молекулой кислорода, в спирте — единожды с углеродом или кислородом). Т.е. внешних связей не больше чем внутренних.

Для атома бериллия я тоже не смог найти нарушения принципа — даже в органической молекуле оксид-гексаацетата бериллия у каждого атома тоже связей не больше четырёх (см. картинку 🙂).

В химии и физике нам намного проще — соблюдение законов контролирует сама природа (ну или движок матрицы 📺). Жаль, что в ИТ при проектировании сложных систем нам приходится делать это самостоятельно. Или не жаль 💚

Продолжим рассуждения предыдущего поста, в котором я перекладывал каскадное снижение связанности на организационную структуру компаний и даже на молекулярную химию 🤓

За полгода я уже достаточно много где рассказал про предлагаемый мой принцип — и много где после доклада мне говорили, что мои идеи являются следствием (или даже просто копией) постулатов всем известных (😉) теории систем и теории графов. Это обсуждали и в Алматы, и в Екатеринбурге, и в Новосибирске, и в Челябинске (чувак признался, что был на моём докладе в КЗ и пришёл на его продолжение в Че ☺️ ), и в Москве, и в интернете (в том числе по мотивам предыдущего поста).
Пользуясь случаем, выражаю огромную благодарность всем, кто задаёт вопросы, комментирует и подходит/пишет обсудить ❤️.

Сразу скажу честно — ранее, я весьма поверхностно был знаком именно с "теорией" теории систем. Хотя с переложением её на практику, как оказалось, сталкивался достаточно часто — и в материалах по системному подходу, и в различных статьях по Coupling & Cohesion в ИТ.

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

Но сейчас хочу порассуждать не только об этом.
Постепенно (нет 🙃) подведу к теме концептуального будущего ИТ-архитектуры.

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

Я вот всё время пишу и говорю, что мы как архитекторы должны бороться со сложностью, т.к. она убивает проекты и т.д. Но не ограничивают ли наши методы борьбы с ней прогресс развития ИТ?
Заметьте (❗️), не сама борьба тормозит прогресс, а несоответствующие текущему этапу развития методы борьбы со сложностью.

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

Что это вообще такое ❓

Мне очень нравится краткие формулировки описания этих терминов у С.Б. Переслегина, которые и процитирую:

В чём суть средового подхода — вы имеете дело с системой, в которой обязаны учитывать бесконечное количество элементов связи...
Базовое движение в средах — это волновые процессы. Если когда вы воздействуете на систему — она реагирует на вас принципом Ле Шателье (обратной связью — прим. моё), то когда вы воздействуете на среду — она рассеивает ваше воздействие через генерацию волн.

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

Среда — это система с бесконечным количеством степеней свободы.

Видео Сергея Борисовича про системный, средовой и сферный подходы: https://www.youtube.com/watch?v=Rn50DfXpATs

А вот до ИТ-сферы и соответствующего сферного подхода в ИТ, на мой взгляд, нам ещё далеко )

Интересно, как скоро придётся менять название канала на "Архитектура распределённых сред"? 🙃
Хотя думаю, что прилагательные "распределённые" неприменимо к средам. Скорее назову канал примерно так: "Архитектура по средам" 😀

Наверное один из самых задаваемых мне вопросов — с чего начать при проектировании архитектуры нового проекта, какие мне вводные нужны и как, и с помощью каких инструментов, я их собираю?

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

Я уже писал о том, что при старте нового проекта или проектировании следующего большого релиза существующего, мы в обязательном порядке используем наш фреймворк проектирования социотехнических систем, четвёртым шагом которого как раз и является создание ИТ-архитектуры. Архитектура — именно 4й шаг в последовательности анализа, и она всегда основывается на результатах и артефактах трёх предыдущих шагов — карт, выявляющих бизнес-цели и пути их достижения, собирающих целостное видение и описание смыслов будущего продукта.

В рамках своего курса в ИТМО я преподаю как проектировать и спроектировать архитектуру, почему именно так и что это даёт. Но в рамках курса мы не обсуждаем шаги, которые должны предшествовать проектированию архитектуры.

И наконец-то эта брешь будет закрыта! 🥳
Мои партнёры по Бындюсофт, авторы методов нашего фреймворка проектирования, Александр Бындю и Андрей Шапиро на базе ИТМО так же запускают курс «Анализ и проектирование социотехнических систем»!

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

Старт курса — уже в июле! Кликайте на ➡️ Подробности!

Таким образом мы начинаем преподавать все наши изобретения и новшества уже на уровне официального образования и с дипломами гос.образца 😎👨‍🎓

В своей стране продвигать и развивать отрасль, в которой работаешь и чувствуешь себя экспертом — лично для меня дорогого стоит 😄

А очередной запуск моего курса по проектированию ИТ-архитектуры я планирую на осень 🍁.
Не переключайтесь 📺

В выходные выступил на Pro IT FEST в секции Стендап с полушуточным докладом "Зодиакальные знаки микросервисной архитектуры" 😅🌛

О чем?
Вы слышали про 12-факторное приложение — но готовы ли вы к зодиакальной интерпретации этого манифеста? Руслан Сафин докажет, что микросервисы тоже рождены под звёздами: каждый из 12 факторов — это отражение астрологических архетипов. А значит, вы сможете заранее предсказать сильные и слабые стороны вашего приложения, просто зная дату его “рождения”.

Что вас ждет?
— Краткий, но ёмкий обзор 12 факторов
— Астрологическая метафора для каждого из них (да, это серьёзно, но и нет)
— Немного вовлечения зала и атмосфера лёгкой пятничной лекции под напитки
— Доля иронии и фана, за которой прячется неплохой инженерный смысл

Кто такой Руслан Сафин?
Инженер с бэкграундом архитектора, мыслитель с нестандартным углом обзора, и по совместительству — человек, который рискнул соединить DevOps и астрологию.
Иногда шутит, но всегда по делу.

Если бы я просто сказал, что буду рассказывать про отчасти уже очевидные, а местами чуть спорные 12 факторов cloud-ready приложения — уверен, публики было бы меньше 😏

Полную презентацию закину комментарием, а пока, не подсматривая туда, попробуйте угадать какому знаку зодиака соответствует описание фактора "Конфигурация" (сохранение конфигурации в среде выполнения (env)):

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

Переменные окружения, отделённые от кода, — это как надёжный дом для личных данных. Кому свойственно интуитивно понимать важность конфиденциальности и защищённости?

Какой же это знак? ⭐️🙂

На моё удивление — публика легко угадала все знаки зодиака всех 12ти факторов ) Можете попробовать разгадать и остальные знаки листая презентацию и не подсматривая следующие слайды: сначала идёт 2 слайда описания фактора, а на третьем — правильный ответ со знаком зодиака.

Вращайте барабан! 🥁🙂

Всегда приятно, когда твои материалы упоминают в профильных статьях и постах. Александр Межов в своём канале в ходе рассуждений над одной из тем рекомендует мой принцип каскадного снижения связанности: https://yangx.top/arch_and_dev/83 😊

Позволю себе несколько комментариев к контексту рекомендации и к исходному посту в целом. Сам исходный пост является комментарием к статье "Microservices antipatterns and pitfalls" Марка Ричардса, то есть у меня будут комментарии на комментарий 😂

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

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

💡 Интересная мысль! Конкретно в разрезе определения правильности оптимальности декомпозиции микросервисов, о принципе снижения связанности я ещё не думал 🙂 Но в целом — да, в конечном счёте именно внешние проявления существования микросервиса (его использование другими и его собственные зависимости от других) определяют и характеризуют все его смыслы и качества, в том числе и эффективность его границ. Без внешних проявлений микросервис бессмыслен (микросервис не монолит — как вещь в себе, он невозможен).

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

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

И вновь отличный комментарий! Появление "микросервисных монолитов" зачастую оправдывают транзакционностью обработки данных, которую никто не хочет делать распределённой. При этом, зачастую не видят проблем в самом способе получения, хранения и обработки данных — говоря об архитектуре микросервисов, иногда забывают об архитектуре принадлежности данных, их потоков и их разделения.
На эту тему могу так же посоветовать статью: Управление мастер-данными в микросервисной архитектуре

3️⃣Степень общительности сервисов
Насколько много внешних сервисов задействованы при выполнении операций целевого? Это в какой-то степени допустимо для API-шлюзов и workflow-оркестраторов, но в иных случаях это "черная метка". Каждое обращение к внешнему сервису снижает пропускную способность и надёжность.

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

4️⃣Соответствие целям бизнеса
Для чего делается сервис? Какую проблему бизнеса он решает? Ответы на эти вопросы могут существенным образом повлиять на итоговое решение. 👔 Например, если в основе требований бизнеса — уменьшение TTM (Time-To-Market), то будет стремление к множеству мелких сервисов; если повышение надёжности, то будет стремление к укрупнению сервисов.

А вот с последним доводом я скорее не соглашусь. Всё же чем крупнее сервис, тем больше шансов, что он упадёт, будет тормозить или в нём будут баги. Про проектирование отказоустойчивости у меня естественно тоже есть статья 😅

Получился не совсем самостоятельный пост, а больше обсуждение или даже кусочек асинхронной беседы, вынесенный на публике. Но, имхо, как раз в беседах и рождаются новые идеи и развиваются старые! И кажется будет не лишним в лишний раз (🙂) собрать ссылочки на статьи по теме.

☀️

Несколько ночей я провёл в вайбе за совместным с ИИ программированием (в платной IDE — то есть в нормальном режиме парного программирования, а не копи‑паста в чатбот).

В целом, я уже лет 5 как не пишу код (кроме изредка опенсорса).. И вот что хочу сказать — такого азарта я не ощущал уже лет 20! Помню, как после универа садишься «на пару часов» за комп... и обнаруживаешь себя в 5 утра не отходившим от тогда ещё совсем неплоского монитора 🤓

Конечно, всё зависит от задачи. Азарт быстро садится, когда первый этап pet‑проекта пройден, и начинается рутина: загрузки, парсеры, сериализация, кэширование, инфраструктура… всё нужное, но скучное. Уже не пишешь самую мякотку — алгоритм, визуал или физику идеи. А лепишь обвязку.

Так вот! С ИИ, как я уже много раз говорил, человеку остаются только человечные задачи — задачи, требующие искры идеи, мысли, озарения! А всю остальную обвязку на себя возьмёт ИИ. Скорость разработки взлетает, азарт возвращается с новой силой, ведь теперь ты воплощаешь более смелые и сложные идеи , проверяешь гипотезы и получаешь фидбек, можешь быстро в одного реализовать гораздо более масштабный проект! Переходить к следующим белковым человеческим задачам своей мега идеи!

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

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

Так вот. С помощником в виде ИИ я могу лишь генерировать идеи, направлять, думать и смотреть результаты! Больше не нужно самому писать движок доски, I/O, тесты.. и даже больше — я лишь формулирую идеи алгоритмов, прошу добавить кэш уже оценённых позиций, просчитать ходы вперёд! И даже более сложные вещи — например, я пишу: "добавь альфа-бета отсечение для ускорения оценки позиции", и ИИ меня понимает и правильно реализует этот алгоритм применительно ко всему остальному имеющемуся коду!

Азарт только нарастает, двигаться удаётся семимильными шагами, и вчера ночью я впервые проиграл своему детищу! 🤩

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

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

P.S. Один умный мужик в твиттере еще до мейнстрима (года два назад) сказал, что "лучший язык программирования — английский!" (читай — человечий). Всё именно так — я общаюсь с ИИ на русском, редко что-то дописываю сам на C#. Но есть ощущение, что понимая структуры данных, мне уже сложно на русском формулировать чего хочу. В уме абстрактно я понимаю как оптимизировать сложную структуру нескольких вложенных массивов и хэшсетов и примерно написать это на LINQ.. я уверен, что ИИ меня бы понял с его уровнем владения и русским, и C#.. Но вот выразить это в виде промпта на русском иногда бывает достаточно сложно.
Думаю, в ближайшее время я точно перейду на некую смесь русского с LINQ ))

P.P.S. Все эксперименты и рассуждения проводились на основе не очень большого pet-проекта (~8K строк кода), для которого нестрашно, что код будет отправляться на забугорные сервера

ИИ не убивает программирование, он делает его великим и интересным снова, возвращает его ностальгический вайб! 😃
Делает его снова нашим!