У меня окончательно оформилось предложение по точечному аудиту/исследованию микросервисного архитектурного решения :)
Аудит затрагивает:
- степень соответствия выбранного стиля бизнес-модели и потребностям рынка
- степень соответствия орг. структуры микросервисному архитектурному стилю
- степень соответствия компетенций
- степень соответствия процессов горизонтального и вертикального взаимодействия
- степень соответствия процессов управления архитектурной целостности и развития архитектуры
- степень соответствия процессов управления тех долгом
- степень удовлетворения требованиям и атрибутам качества
А по итогу идет перечень дисфункций/ и стратегия их устранения.
«это была славная охота» :)
Скоро предложение будет опубликовано, пока все собирал и систематизировал получилось материала на книгу, более 200 страниц только текста :)
Этот аудит я уже проводил много-много раз в рамках корпоративных контрактов, многие выводы есть в моем курсе по микросервисам и там чего только не было, что только не называют микросервисами.
Огромный монолит просто положили в докер - микросервис, компоненты с сильнейшими зависимостями, множество пустых компонентов, которые работают с единой базой и вся логика на общих для всех хранимках, тотальное смешение сущностей предметный областей. Общее регрессионное ручное тестирование на несколько недель. Отсутствие атрибутов качества как таковых, что приводит к постоянному пожаротушению, некорректное определение атрибутов качества. Стратегия, которая затрагивает только орг дизайн и не затрагивает архитектуру вообще (да-да и такое бывает).
Версию лайт для самопроверки думаю выложить в паблик, но она еще не готова для публичного доступа.
Что побудило?
Некоторый застой в практиках архитектурного ассесмента. Если погуглить, то толком кроме ATAM ничего и не находится, причем статьи 15-летней давности. А индустрия не стоит на месте.
Еще планирую собрать рабочую группу из активистов для проработки деталей.
Все это будет, периодически буду публиковать новости на эту тему, всем хорошего дня :)
Аудит затрагивает:
- степень соответствия выбранного стиля бизнес-модели и потребностям рынка
- степень соответствия орг. структуры микросервисному архитектурному стилю
- степень соответствия компетенций
- степень соответствия процессов горизонтального и вертикального взаимодействия
- степень соответствия процессов управления архитектурной целостности и развития архитектуры
- степень соответствия процессов управления тех долгом
- степень удовлетворения требованиям и атрибутам качества
А по итогу идет перечень дисфункций/ и стратегия их устранения.
«это была славная охота» :)
Скоро предложение будет опубликовано, пока все собирал и систематизировал получилось материала на книгу, более 200 страниц только текста :)
Этот аудит я уже проводил много-много раз в рамках корпоративных контрактов, многие выводы есть в моем курсе по микросервисам и там чего только не было, что только не называют микросервисами.
Огромный монолит просто положили в докер - микросервис, компоненты с сильнейшими зависимостями, множество пустых компонентов, которые работают с единой базой и вся логика на общих для всех хранимках, тотальное смешение сущностей предметный областей. Общее регрессионное ручное тестирование на несколько недель. Отсутствие атрибутов качества как таковых, что приводит к постоянному пожаротушению, некорректное определение атрибутов качества. Стратегия, которая затрагивает только орг дизайн и не затрагивает архитектуру вообще (да-да и такое бывает).
Версию лайт для самопроверки думаю выложить в паблик, но она еще не готова для публичного доступа.
Что побудило?
Некоторый застой в практиках архитектурного ассесмента. Если погуглить, то толком кроме ATAM ничего и не находится, причем статьи 15-летней давности. А индустрия не стоит на месте.
Еще планирую собрать рабочую группу из активистов для проработки деталей.
Все это будет, периодически буду публиковать новости на эту тему, всем хорошего дня :)
1 августа в 19:00 пройдет митап ArchDays: «Проектирование БД: От NF к денормализации данных»
Спикер: Антон Цитульский — Старший разработчик в Тинькофф.
На митапе Антон расскажет:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес-домена.
А в конце встречи обсудим тему вместе с участниками митапа.
💎 Регистрируйтесь: https://archconf.ru/meetup-010823
Спикер: Антон Цитульский — Старший разработчик в Тинькофф.
На митапе Антон расскажет:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес-домена.
А в конце встречи обсудим тему вместе с участниками митапа.
💎 Регистрируйтесь: https://archconf.ru/meetup-010823
Микросервисы / распределенные системы
1 августа в 19:00 пройдет митап ArchDays: «Проектирование БД: От NF к денормализации данных» Спикер: Антон Цитульский — Старший разработчик в Тинькофф. На митапе Антон расскажет: — о плюсах и минусах нормальных форм (NF); — когда пора денормализовывать схему…
Очень много регистраций, так что настроили параллельно трансляцию в ютуб, кому так удобнее можно туда сразу идти 🙂
https://youtube.com/live/mCpguC88Amk?feature=share
https://youtube.com/live/mCpguC88Amk?feature=share
YouTube
Проектирование БД: От NF к денормализации данных. Антон Цитульский
Выступление в рамках конференции ARCHDAYS: https://archconf.ru/arch
На митапе Антон рассказал:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес…
На митапе Антон рассказал:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес…
Хочу выступить сам, выбирайте тему (множественный выбор):
Anonymous Poll
15%
Отличительные особенности EA в agile/не agile
38%
Организация базового арх. процесса для поддержки самоорганизации
20%
История возникновения микросервисов, отличие от SOA
38%
Связь бизнеса, процессов и архитектуры в микросервисах
52%
Общий процесс проектирования микросервисов
46%
Быстрое восстановление основных знаний об архитектуре
3%
Предложу тему в комментариях
Тема следующего митапа - «Общий процесс проектирования микросервисов».
Дату и время анонсируем позже. А пока…
Напишите ваши вопросы или проблемы с проектированием заранее в комментариях к этому посту, мне это поможет лучше попасть в ожидания 🎯
Дату и время анонсируем позже. А пока…
Напишите ваши вопросы или проблемы с проектированием заранее в комментариях к этому посту, мне это поможет лучше попасть в ожидания 🎯
Статья про надежный обмен данными между сервисами при использовании стриминговой базы данных.
(В посте есть ссылка на статью с описанием стриминговых баз данных и зачем они нужны).
https://www.iambobur.com/post/reliable-microservices-data-exchange-with-streaming-database
Меня эта тема заинтересовала, потому что как минимум в одном текущем проекте увидел явную потребность. Кто использует/использовал, напишите в комментарии или в личку какую базу используете и в каком контексте, можно устроить митап на тему стриминговых баз данных и их применения.
(В посте есть ссылка на статью с описанием стриминговых баз данных и зачем они нужны).
https://www.iambobur.com/post/reliable-microservices-data-exchange-with-streaming-database
Меня эта тема заинтересовала, потому что как минимум в одном текущем проекте увидел явную потребность. Кто использует/использовал, напишите в комментарии или в личку какую базу используете и в каком контексте, можно устроить митап на тему стриминговых баз данных и их применения.
Название: "Код Зла"
Сценарий:
Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.
Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".
Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.
Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.
Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.
Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.
Конец
Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.
Титры.
(с) ChatGPT
Сценарий:
Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.
Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".
Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.
Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.
Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.
Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.
Конец
Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.
Титры.
(с) ChatGPT
Опрос, касается только статей, не книг и только архитектуры/дизайна.
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Anonymous Poll
24%
Быстро находите ответ
36%
Долго и упорно ищите и в итоге находите ответ
22%
Чаще не находите ответ
2%
Ни разу не смогли найти ответ
16%
Посмотреть результаты
Микросервисы / распределенные системы
Опрос, касается только статей, не книг и только архитектуры/дизайна.
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Интересно посмотреть на результат вот с какой точки зрения: в сумме второй и третий ответы дают больше половины. То есть, вообще-то, несмотря на бесчисленное множество и бесконечное обилие материалов, найти что-то конкретное достаточно сложно, а если возможно, то затратно по времени.
В таких условиях выглядит так, что лучше тактикой будет стараться сократить необходимость использования поисковых систем, тут подходов много и все они затратные, но все же:
1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее
Поделитесь своими идеями в комментариях, какие еще видите подходы?
Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
В таких условиях выглядит так, что лучше тактикой будет стараться сократить необходимость использования поисковых систем, тут подходов много и все они затратные, но все же:
1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее
Поделитесь своими идеями в комментариях, какие еще видите подходы?
Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
Традиционно для подписчиков канала скидка на archdays.ru 20% и на онлайн и на оффлайн по промокоду microservices_arch
В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂
В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂
On the Definition of Microservice Bad Smells.pdf
312.1 KB
Список Microservices Bad Smells. Смотрим в статью, смотрим на свое решение, думаем.
Microservices_Migration_of_a_Mission_Critical_Syst.pdf
1.1 MB
Миграция на микросервисы Mission Critical системы.
Анонс ArchDays MeetUp
12 сентября в 19:00 Илья Смирнов, руководитель практики ML/AI в ГК Юзтех расскажет об архитектуре системы моделирования на базе цифровых двойников производства.
На многих отечественных производствах полным ходом идет цифровизация, практически все технологические параметры уже измеряют с помощью тех или иных датчиков. При этом важно не только быть наблюдателем процесса, но и иметь возможность его моделировать, и тут на помощь приходят цифровые двойники – математические модели, корректно описывающие поведение конкретного объекта, оборудования.
Подробнее и регистрация тут:
https://meetup.archdays.ru/meetup-12092023
Ждем всех, будет интересно!
12 сентября в 19:00 Илья Смирнов, руководитель практики ML/AI в ГК Юзтех расскажет об архитектуре системы моделирования на базе цифровых двойников производства.
На многих отечественных производствах полным ходом идет цифровизация, практически все технологические параметры уже измеряют с помощью тех или иных датчиков. При этом важно не только быть наблюдателем процесса, но и иметь возможность его моделировать, и тут на помощь приходят цифровые двойники – математические модели, корректно описывающие поведение конкретного объекта, оборудования.
Подробнее и регистрация тут:
https://meetup.archdays.ru/meetup-12092023
Ждем всех, будет интересно!
Forwarded from Event Storming (Sergey Baranov)
Нужно ли разработчикам/тестировщикам/админам знать бизнес-модель компании/продукта в которой они работают? (напишите в комментариях чем это, на ваш взгляд, помогает или почему в этом нет смысла).
Позже напишу причем тут бизнес-модель :)
Позже напишу причем тут бизнес-модель :)
Anonymous Poll
94%
Да
6%
Нет
Микросервисы / распределенные системы
У меня окончательно оформилось предложение по точечному аудиту/исследованию микросервисного архитектурного решения :) Аудит затрагивает: - степень соответствия выбранного стиля бизнес-модели и потребностям рынка - степень соответствия орг. структуры микросервисному…
Первый публичный заход.
Сегодня на it-picnic.ru расскажу о быстром восстановлении архитектурных знаний.
Выступление построил практико-ориентированным, то есть буквально, что делать по дням, чтобы быстро получить широкий спектр архитектурных знаний, когда скорость важнее точности и полноты.
После пикника подготовлю небольшую методичку, по плану к ArchDays будет готова.
И с первыми артефактами уже можно будет с желающими поучаствовать объединяться в группу :)
Сегодня на it-picnic.ru расскажу о быстром восстановлении архитектурных знаний.
Выступление построил практико-ориентированным, то есть буквально, что делать по дням, чтобы быстро получить широкий спектр архитектурных знаний, когда скорость важнее точности и полноты.
После пикника подготовлю небольшую методичку, по плану к ArchDays будет готова.
И с первыми артефактами уже можно будет с желающими поучаствовать объединяться в группу :)
IT_Пикник.pdf
9.1 MB
Презентация с выступления.
В компании три команды, все три проводят дискавери.
Все проверяют гипотезы, у кого-то срабатывает.
Означает ли это, что другие ошиблись? Нет. Это же гипотезы. Они на выходе имеют два легитимных состояния – подтверждена или опровергнута.
А вот те, чьи гипотезы не подтвердились, внесли точно такой же вклад, ведь если бы их не было, то эти гипотезы, скорее всего, все равно кто-то в итоге проверял. Если в описанном выше кейсе одна команда проверяла бы все гипотезы, то существует вероятность, что такая команда вообще дошла бы до подтвержденной гипотезы, остановившись где-то в середине пути.
Если какая-то гипотеза не подтвердилась, то нужно сделать формальные выводы, а результатом будет увеличение объема знаний об объекте исследования и сужение мощности множества доступных вариантов для последующей проверки.
Это касается как продуктовых гипотез, так и технических экспериментов.
Спроектированные по всем канонам микросервисы позволяют проверять в единицу времени множество гипотез, как касающихся продукта, так и технических характеристик решения, что так же косвенно сильно приближает точку достижения успешности решения в целом.
Все проверяют гипотезы, у кого-то срабатывает.
Означает ли это, что другие ошиблись? Нет. Это же гипотезы. Они на выходе имеют два легитимных состояния – подтверждена или опровергнута.
А вот те, чьи гипотезы не подтвердились, внесли точно такой же вклад, ведь если бы их не было, то эти гипотезы, скорее всего, все равно кто-то в итоге проверял. Если в описанном выше кейсе одна команда проверяла бы все гипотезы, то существует вероятность, что такая команда вообще дошла бы до подтвержденной гипотезы, остановившись где-то в середине пути.
Если какая-то гипотеза не подтвердилась, то нужно сделать формальные выводы, а результатом будет увеличение объема знаний об объекте исследования и сужение мощности множества доступных вариантов для последующей проверки.
Это касается как продуктовых гипотез, так и технических экспериментов.
Спроектированные по всем канонам микросервисы позволяют проверять в единицу времени множество гипотез, как касающихся продукта, так и технических характеристик решения, что так же косвенно сильно приближает точку достижения успешности решения в целом.