При́нцип Ле Шателье́ — Бра́уна (1884 г.) — если на систему, находящуюся в устойчивом равновесии, воздействовать извне, изменяя какое-либо из условий равновесия, то в системе усиливаются процессы, направленные в сторону противодействия изменениям.
Еще раз к вопросу почему переписать систему сложнее чем создать новую.
Еще раз к вопросу почему переписать систему сложнее чем создать новую.
👍1
#ТРАЗ: Ситуация и задача
С точки зрения #ТРИЗ важно различать ситуацию и задачу.
Большинство (~100%) людей пытаются разрешить ситуацию не поставив задачу.
Это же нам рекомендуют во всяких методологиях (например ADD)
Конкретно в ADD поэтапно выявляются архитектурно значимые требования (драйвера) и по ним предлагается решение.
Пример:
Драйвера:
1. Система должна поддерживать доступность 99.99%
2. Время отклика в 99% процентах случаев должно быть ниже 1 сек. при нагрузке 10krps
- Это описание ситуации а не задачи
Решать подобное можно только по инерции (инерция мышления).
Например:
В прошлый раз у нас была такая же задача, мы ее решили используя Кафку.
Решение: используем Кафку
Это решение без постановки задачи, и без определения противоречий.
#ТРИЗ предлагает преодолевать инерцию мышления и первым делом сформулировать задачу.
Например так:
1. Сервис должен поддерживать RTO=0.1 сек для поддержания доступности в 99.99 %
2. Сервис поддерживает RTO=1 сек (по результату моделирования/прототипирования)
Это уже можно решать !
Цитаты в тему
1. Ситуация это еще не задача (ТРИЗ)
2. Нельзя лечить больного по жалобам
С точки зрения #ТРИЗ важно различать ситуацию и задачу.
Большинство (~100%) людей пытаются разрешить ситуацию не поставив задачу.
Это же нам рекомендуют во всяких методологиях (например ADD)
Конкретно в ADD поэтапно выявляются архитектурно значимые требования (драйвера) и по ним предлагается решение.
Пример:
Драйвера:
1. Система должна поддерживать доступность 99.99%
2. Время отклика в 99% процентах случаев должно быть ниже 1 сек. при нагрузке 10krps
- Это описание ситуации а не задачи
Решать подобное можно только по инерции (инерция мышления).
Например:
В прошлый раз у нас была такая же задача, мы ее решили используя Кафку.
Решение: используем Кафку
Это решение без постановки задачи, и без определения противоречий.
#ТРИЗ предлагает преодолевать инерцию мышления и первым делом сформулировать задачу.
Например так:
1. Сервис должен поддерживать RTO=0.1 сек для поддержания доступности в 99.99 %
2. Сервис поддерживает RTO=1 сек (по результату моделирования/прототипирования)
Это уже можно решать !
Цитаты в тему
1. Ситуация это еще не задача (ТРИЗ)
2. Нельзя лечить больного по жалобам
Говорим по-русски
Solution architect - зодчий-решала
Solution architect - зодчий-решала
😁4
Еще два класса
“Ninja architect”: Disappears at the same speed as it appeared.
“Master of wizards”: It has the noscript but disappears in the most critical moments.
отсюда - https://dzone.com/articles/defining-architecture-decision-record
“Ninja architect”: Disappears at the same speed as it appeared.
“Master of wizards”: It has the noscript but disappears in the most critical moments.
отсюда - https://dzone.com/articles/defining-architecture-decision-record
DZone
Defining Architecture Decision Record (ADR)
Find out what ADR is and how this document supports software architecture decision-making in addition to making your architecture more scalable in this article.
👍2
Добрые люди поделились книжкой "Mastering ArchiMate"
https://libgen.is/book/index.php?md5=449A2BF7488A69C830BD06027E58FD16
https://libgen.is/book/index.php?md5=449A2BF7488A69C830BD06027E58FD16
libgen.is
Library Genesis: Gerben Wierda - Mastering ArchiMate Edition III: A serious introduction to the ArchiMate® enterprise architecture…
Library Genesis is a scientific community targeting collection of books on natural science disciplines and engineering.
👍3
Методы принятия арх. решений v1.pdf
1.1 MB
Презентация выступления на Сообществе архитекторов IT-One
Тема: Методы принятия архитектурных решений
Тема: Методы принятия архитектурных решений
👍2
Messaging
Сейчас при построении архитектур на базе служб и распределенных бизнес процессов все завязываются на обмен сообщениями.
Архитектура старая и хорошо описанная (в частности в EIP Грегора Хопа).
Если при этом нужна производительность - берем мощный инструмент обмена сообщениями.
Благо арсенал огромен от старого Кролика до свежей Панды
С другой стороны, читаем у того же Хопа (EIP, Введение):
"Системы обмена сообщениями вносят дополнительные издержки в процесс взаимодействия между приложениями. На создание, отправку, получение и обработку сообщения уходят время и ресурсы. К тому же передача большого объема данных может повлечь за собой создание несметного числа сообщений."
и далее
"Если бы настроить готовые приложения на использование одного и того же формата данных было так легко, нам вообще не понадобился бы обмен сообщениями (Messaging); вместо него было бы гораздо практичнее использовать общую базу данных (Shared Database)"
В мире, где во всю правит NoSQL, озвученная выше проблема форматов выглядит как нечто очень неактуальное.
Зачем нам все эти издержки, муки с балансировкой и чанками от messaging ?
Следующую систему строю на Shared Database :)
#messaging #performance #производительность #эффективность #Архитектурные_стили
Сейчас при построении архитектур на базе служб и распределенных бизнес процессов все завязываются на обмен сообщениями.
Архитектура старая и хорошо описанная (в частности в EIP Грегора Хопа).
Если при этом нужна производительность - берем мощный инструмент обмена сообщениями.
Благо арсенал огромен от старого Кролика до свежей Панды
С другой стороны, читаем у того же Хопа (EIP, Введение):
"Системы обмена сообщениями вносят дополнительные издержки в процесс взаимодействия между приложениями. На создание, отправку, получение и обработку сообщения уходят время и ресурсы. К тому же передача большого объема данных может повлечь за собой создание несметного числа сообщений."
и далее
"Если бы настроить готовые приложения на использование одного и того же формата данных было так легко, нам вообще не понадобился бы обмен сообщениями (Messaging); вместо него было бы гораздо практичнее использовать общую базу данных (Shared Database)"
В мире, где во всю правит NoSQL, озвученная выше проблема форматов выглядит как нечто очень неактуальное.
Зачем нам все эти издержки, муки с балансировкой и чанками от messaging ?
Следующую систему строю на Shared Database :)
#messaging #performance #производительность #эффективность #Архитектурные_стили
👍3😁1
Messaging.Topic
Возвращаясь к теме обмена сообщениями👆
Чем топик хуже нетипизированого набора данных в БД:
1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное.
Тем более со всей этой распределёнкой порядок сообщений в топике все равно случайный.
Нет, конечно есть всякие KSQL - но это как молотком шурупы вкручивать.
2. Иногда хочется передать сразу весь снапшот, а не дельту, или даже большущий БЛОБ
В топике - чанкаем. В БД просто льем.
3. Как же удобно управлять сообщениями(записями) в базе !
- Любая статистика.
- Удаляй любого на выбор.
- Перекладывать мертвых и инвалидов из топика в топик не надо. Достаточно пометить.
- и т. д. и т. п.
4. Масштабируемость - сколько топиков вытянет ваша система ?
А что делать если эти топики еще и динамически создаются/удаляются ?
У топика только одно преимущество. Он чистится автоматом.
При передачи сообщений через базу нужно быть очень аккуратным, иначе горы мусора гарантированы.
#messaging #performance #производительность #эффективность #Архитектурные_стили
Возвращаясь к теме обмена сообщениями👆
Чем топик хуже нетипизированого набора данных в БД:
1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное.
Тем более со всей этой распределёнкой порядок сообщений в топике все равно случайный.
Нет, конечно есть всякие KSQL - но это как молотком шурупы вкручивать.
2. Иногда хочется передать сразу весь снапшот, а не дельту, или даже большущий БЛОБ
В топике - чанкаем. В БД просто льем.
3. Как же удобно управлять сообщениями(записями) в базе !
- Любая статистика.
- Удаляй любого на выбор.
- Перекладывать мертвых и инвалидов из топика в топик не надо. Достаточно пометить.
- и т. д. и т. п.
4. Масштабируемость - сколько топиков вытянет ваша система ?
А что делать если эти топики еще и динамически создаются/удаляются ?
У топика только одно преимущество. Он чистится автоматом.
При передачи сообщений через базу нужно быть очень аккуратным, иначе горы мусора гарантированы.
#messaging #performance #производительность #эффективность #Архитектурные_стили
👍1
Прямоугольники и стрелочки
Messaging.Topic Возвращаясь к теме обмена сообщениями👆 Чем топик хуже нетипизированого набора данных в БД: 1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное. Тем более со всей этой распределёнкой порядок сообщений в топике все…
Топики против базы данных (продолжение)
Основная проблема разделенной БД (Share Database) - связывание общающихся сервисов через общую схему данных
Если БД используется для передачи сообщений - этой проблемы нет.
Время жизни сообщения - время взаимодействия.
Миграция с нулевым даунтаймом - без проблем.
Конечно, при этом, БД должна допускать любую структуру сообщения (NoSQL)
Месседжеры обещают поставлять сообщения по-очереди - но не справляются со своим единственным контрактом в распределенной системе (либо не по-очереди либо слишком медленно)
У себя организовали прототип (RSocket, Bookeeper)
По отношению к прототипу на Pulsar задержка в 10 раз меньше на том же профиле нагрузки
При этом
- абсолютно не ограничены в количестве клиентов
- можем бегать по сообщениям в базе - выбирая по приоритетам, фильтрам, или как захотим
Основная проблема разделенной БД (Share Database) - связывание общающихся сервисов через общую схему данных
Если БД используется для передачи сообщений - этой проблемы нет.
Время жизни сообщения - время взаимодействия.
Миграция с нулевым даунтаймом - без проблем.
Конечно, при этом, БД должна допускать любую структуру сообщения (NoSQL)
Месседжеры обещают поставлять сообщения по-очереди - но не справляются со своим единственным контрактом в распределенной системе (либо не по-очереди либо слишком медленно)
У себя организовали прототип (RSocket, Bookeeper)
По отношению к прототипу на Pulsar задержка в 10 раз меньше на том же профиле нагрузки
При этом
- абсолютно не ограничены в количестве клиентов
- можем бегать по сообщениям в базе - выбирая по приоритетам, фильтрам, или как захотим
architectural-decision-records.pdf
266.9 KB
Гайд по ADR от AWS
Forwarded from Антонов такой Антонов
Секреты низкой продуктивности
В 2021 году становится все сложнее сохранить низкую продуктивность. Как это сделать - помогут пять простых советов:
1. Постоянно встречайтесь с кем-то вместо того, чтобы решать всё на онлайн звонках. Это позволит вместо получаса тратить по часу-полутора на каждую встречу, плюс час между ними на разные передвижения, перемещения и просто свободные окна. В результате вы сможете сократить количество полезных разговоров в 3-4 раза!
2. Откажитесь от быстрых транзакций в онлайне и через крипту - передавайте деньги наличными, выставляйте счета, пусть Галочка сделает перевод в банковские часы. Ни к чему отправлять тысячу долларов с телефона с карты на карту - лучше встретится в конце недели и вместе выпить чаю.
3. Старайтесь заниматься всеми делами с телефона, маленький экран поможет тратить побольше времени на чтение разных материалов. А уж как маленький экран помогает медленно печатать!
4. Постарайтесь не делать никаких заметок, которые могут позволить вам лучше понять какую-то информацию, запомнить события или узнать себя. Лучше каждый день начинать с чистого листа, а всё важное вспоминать по ситуации.
5. Не пользуйтесь гуглом, пусть вам лучше кто-нибудь всё объяснит так, как он это видит. Вообще, старайтесь перелопачивать поменьше информации, полагаясь на мнение одного-двух человек, желательно случайных.
Надеюсь, эти секреты помогут вам нарастить отставание от своих коллег и партнеров, а также поспособствуют новым жалобам на несправедливость жизни.
В 2021 году становится все сложнее сохранить низкую продуктивность. Как это сделать - помогут пять простых советов:
1. Постоянно встречайтесь с кем-то вместо того, чтобы решать всё на онлайн звонках. Это позволит вместо получаса тратить по часу-полутора на каждую встречу, плюс час между ними на разные передвижения, перемещения и просто свободные окна. В результате вы сможете сократить количество полезных разговоров в 3-4 раза!
2. Откажитесь от быстрых транзакций в онлайне и через крипту - передавайте деньги наличными, выставляйте счета, пусть Галочка сделает перевод в банковские часы. Ни к чему отправлять тысячу долларов с телефона с карты на карту - лучше встретится в конце недели и вместе выпить чаю.
3. Старайтесь заниматься всеми делами с телефона, маленький экран поможет тратить побольше времени на чтение разных материалов. А уж как маленький экран помогает медленно печатать!
4. Постарайтесь не делать никаких заметок, которые могут позволить вам лучше понять какую-то информацию, запомнить события или узнать себя. Лучше каждый день начинать с чистого листа, а всё важное вспоминать по ситуации.
5. Не пользуйтесь гуглом, пусть вам лучше кто-нибудь всё объяснит так, как он это видит. Вообще, старайтесь перелопачивать поменьше информации, полагаясь на мнение одного-двух человек, желательно случайных.
Надеюсь, эти секреты помогут вам нарастить отставание от своих коллег и партнеров, а также поспособствуют новым жалобам на несправедливость жизни.
😁5👍1
Ориентация на продукт/проект
MSA декларирует ориентацию на продукт (принцип Products not Projects)
В разговоре с коллегами - полное непонимание.
Максимум, что вспоминают - это наличие не человека DevOps-а.
В моём упрощенном и поэтому несколько ущербном представлении:
- Ориентация на проект - это ориентация на выполнение задач,
- Ориентация на продукт- это возможность (can, may) эти задачи ставить.
Если задачи приходят от ПО - команду ориентируют на проект.
Если от ПО приходят истории - а команды перекладывает их в задачи - ориентация на продукт.
Если инциденты приходят от службы эксплуатации - процесс.
Если служба эксплуатации часть команды - продукт (привет DevOps!).
И самое интересное с архитектором.
Архитектор вне команды - процесс.
Архитектор в команде (ArcOps, DevArcOps) -> архитектурный бэклог (enablers) внутри команды - продукт.
Однако, архитектор это один из немногих кто знает где выход из бункера (Silos)
Должен быть вне командный арх. ком. - на котором решают вопросы взаимодействия.
Откуда берутся задачи для арх. кома ?
Ставит ГЛАВНЫЙ архитектор - процесс
Ставит команда (архитектура как сервис) - продукт.
"Главный" архитектор - в роли арбитра и последней инстанции
но без прав и власти (не дает задачи). Хм
Чувствую, тут не всё так однозначно
MSA декларирует ориентацию на продукт (принцип Products not Projects)
В разговоре с коллегами - полное непонимание.
Максимум, что вспоминают - это наличие не человека DevOps-а.
В моём упрощенном и поэтому несколько ущербном представлении:
- Ориентация на проект - это ориентация на выполнение задач,
- Ориентация на продукт- это возможность (can, may) эти задачи ставить.
Если задачи приходят от ПО - команду ориентируют на проект.
Если от ПО приходят истории - а команды перекладывает их в задачи - ориентация на продукт.
Если инциденты приходят от службы эксплуатации - процесс.
Если служба эксплуатации часть команды - продукт (привет DevOps!).
И самое интересное с архитектором.
Архитектор вне команды - процесс.
Архитектор в команде (ArcOps, DevArcOps) -> архитектурный бэклог (enablers) внутри команды - продукт.
Однако, архитектор это один из немногих кто знает где выход из бункера (Silos)
Должен быть вне командный арх. ком. - на котором решают вопросы взаимодействия.
Откуда берутся задачи для арх. кома ?
Ставит ГЛАВНЫЙ архитектор - процесс
Ставит команда (архитектура как сервис) - продукт.
"Главный" архитектор - в роли арбитра и последней инстанции
но без прав и власти (не дает задачи). Хм
Чувствую, тут не всё так однозначно
Завтра веду курс "Современные сервисные архитектуры"
Хочу часть опросов проводить на этом канале
С целью накопления статистики
Хочу часть опросов проводить на этом канале
С целью накопления статистики
🔥2👍1
Какое утверждение Вам ближе всего ?
Anonymous Poll
13%
Микросервисы - это архитектура будущего. Все там будем
2%
Микросервисы - это хайп. Много шуму из ничего
56%
Микросервисы - это здорово. Но мало кто умеет их готовить
11%
Микросервисы решают слишком узкий круг задач. Нужны редко и подходят далеко не всем
10%
Под словом "микросервисы" каждый понимает своё. О чём опрос ?
8%
Другое (в коментариях)
Кто в Ваших проектах принмает архитектурные решения ?
Anonymous Poll
33%
Разработчики (коллегиально)
17%
Разработчик в роли архитектора
16%
Выделенный архитектор в составе команды разработчиков
17%
Внешний (к команде) архитектор, по заданию команды разработчиков
29%
Внешний (к команде) архитектор по заданию из вне
5%
Никто
12%
Хочу просто посмотреть ответы
Вынос логики сервиса.png
60.2 KB
Вынос логики из сервиса
Возможные пути
Возможные пути