О терминологии в IT
Забавно вновь и вновь наблюдать споры вокруг слов. Что такое архитектор, что такое микросервисы, что такое ddd и так далее до бесконца.
Как будто много веков назад для разрешения подобных споров люди не придумали научную методологию и механизм определений.
Можно что угодно понимать под словом "архитектор" и отстаивать свое мнение с пеной у рта.
А можно прочитать, что в этот термин вкладывал автор концепции, и как эта концепция развивалась во времени.
Отсутствие явных и точных определений известных каждому серьезно сдерживает развитие сферы IT.
Забавно вновь и вновь наблюдать споры вокруг слов. Что такое архитектор, что такое микросервисы, что такое ddd и так далее до бесконца.
Как будто много веков назад для разрешения подобных споров люди не придумали научную методологию и механизм определений.
Можно что угодно понимать под словом "архитектор" и отстаивать свое мнение с пеной у рта.
А можно прочитать, что в этот термин вкладывал автор концепции, и как эта концепция развивалась во времени.
Отсутствие явных и точных определений известных каждому серьезно сдерживает развитие сферы IT.
👍5
Потребность в архитекторе
Перефразируя Черчилля:
Необходимость в архитекторе обусловлена тем, что предпочитает менеджер: платить или расплачиваться.
Перефразируя Черчилля:
Необходимость в архитекторе обусловлена тем, что предпочитает менеджер: платить или расплачиваться.
👍6🔥3🤔2😁1
ADR и "перспективы"
ADR как способ фиксации архитектурных решений на пике популярности.
Однако, есть запросы не покрываемые данным подходом.
Например, требуется определить какие решения предприняты для обеспечения отказоустойчивости.
"Старые" методологии (например Розански и Вудс) предлагали "перспективы" (см. https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/0321112296).
Перспектива это раздел описания посвященный одному качеству (например производительности).
Я хотел бы объединить эти два подхода.
Для этого нужно иметь возможность группировать архитектурные решения (ADR) по качествам (а возможно и по бизнес функциям).
Задача выглядит простой пока не попытаешься реализовать это практически:
1. Гит не дает тегать общим тегом несколько коммитов
2. Конфлюенс плохо демонстрирует динамику и плохо связан с этапами работы в гите.
3. Хочется использовать obsidian с тегами обратными ссылками и привязкой к git. Но тут проблема - инструмент новый и уговаривать на переезд придется долго )
Коллеги, а у вас есть опыт фасетной группировки арх. решений?
#Документация
ADR как способ фиксации архитектурных решений на пике популярности.
Однако, есть запросы не покрываемые данным подходом.
Например, требуется определить какие решения предприняты для обеспечения отказоустойчивости.
"Старые" методологии (например Розански и Вудс) предлагали "перспективы" (см. https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/0321112296).
Перспектива это раздел описания посвященный одному качеству (например производительности).
Я хотел бы объединить эти два подхода.
Для этого нужно иметь возможность группировать архитектурные решения (ADR) по качествам (а возможно и по бизнес функциям).
Задача выглядит простой пока не попытаешься реализовать это практически:
1. Гит не дает тегать общим тегом несколько коммитов
2. Конфлюенс плохо демонстрирует динамику и плохо связан с этапами работы в гите.
3. Хочется использовать obsidian с тегами обратными ссылками и привязкой к git. Но тут проблема - инструмент новый и уговаривать на переезд придется долго )
Коллеги, а у вас есть опыт фасетной группировки арх. решений?
#Документация
Закономерности развития ИТ систем
В очередной раз убеждаюсь в правоте герметики - "То, что находится внизу, соответствует тому, что пребывает вверху; и то, что пребывает вверху, соответствует тому, что находится внизу".
Сервисные архитектуры почти идеально повторяют решения выработанные адептами ООП.
Единая цель "снижение когнитивной нагрузки на разработчика" приводит к одним и тем же структурам.
Приведу несколько примеров:
1. Независимая разработка потребовала введение объектов на уровне монолита и сервисов в распределенной системе.
2. Устраняя связанность по данным получили инкапсуляцию в ООП и автономность с собственными БД в сервисах.
3. Усиливая автономность ввели понятие строгих контрактов в ООП и аналогично на сервисах (API и т. п.)
4. Модули закрыли фасадами. Сервисы закрыли шлюзами.
5. Разделяя бизнес логику и сценарии использования в ООП ввели слой приложения и сервисы приложения. В сервисных архитектурах появились оркестраторы.
6. Минимизация связанностей привела к понятию "домен" в который объединяется множество объектов. Тот же самый механизм использован при объединении сервисов (см. например DOMA от Uber)
и так далее и тому подобное.
ИМХО, глядя на эти соответствия можно не только находить общие закономерности в развитии архитектурных стилей, но и предсказывать новые решения.
В очередной раз убеждаюсь в правоте герметики - "То, что находится внизу, соответствует тому, что пребывает вверху; и то, что пребывает вверху, соответствует тому, что находится внизу".
Сервисные архитектуры почти идеально повторяют решения выработанные адептами ООП.
Единая цель "снижение когнитивной нагрузки на разработчика" приводит к одним и тем же структурам.
Приведу несколько примеров:
1. Независимая разработка потребовала введение объектов на уровне монолита и сервисов в распределенной системе.
2. Устраняя связанность по данным получили инкапсуляцию в ООП и автономность с собственными БД в сервисах.
3. Усиливая автономность ввели понятие строгих контрактов в ООП и аналогично на сервисах (API и т. п.)
4. Модули закрыли фасадами. Сервисы закрыли шлюзами.
5. Разделяя бизнес логику и сценарии использования в ООП ввели слой приложения и сервисы приложения. В сервисных архитектурах появились оркестраторы.
6. Минимизация связанностей привела к понятию "домен" в который объединяется множество объектов. Тот же самый механизм использован при объединении сервисов (см. например DOMA от Uber)
и так далее и тому подобное.
ИМХО, глядя на эти соответствия можно не только находить общие закономерности в развитии архитектурных стилей, но и предсказывать новые решения.
👍1
Структура архитектурной документации
В любом арх. процессе присутствуют следующие группы арх. артифактов:
1. Сырье - необработанное нечто на входе.
2. Требования, гипотезы или как назовете - нечто после анализа и структурирования.
3. Решения с обоснованиями
4. Модель (точнее их множество)
5. Представления, rfc, презентации - выжимки для коммуникаций.
- документирование всего этого хозяйства целиком/частями опция и выбор зависит от массы факторов
Сырье кидаю в обсидиан в папку raw и мечу тегами под поиск.
Требования беру у аналитиков и докидываю свои драйвера - текст с трассировкой на jira
Решения - madr
Модель веду в конфлюенсе (в текущем проекте), но предпочел бы archi
Представления размазаны по конфлюенсу (rfc) и разным документам (в основном powerpoint)
А хочется единого пространства и удобной трассировки (
#Документирование
В любом арх. процессе присутствуют следующие группы арх. артифактов:
1. Сырье - необработанное нечто на входе.
2. Требования, гипотезы или как назовете - нечто после анализа и структурирования.
3. Решения с обоснованиями
4. Модель (точнее их множество)
5. Представления, rfc, презентации - выжимки для коммуникаций.
- документирование всего этого хозяйства целиком/частями опция и выбор зависит от массы факторов
Сырье кидаю в обсидиан в папку raw и мечу тегами под поиск.
Требования беру у аналитиков и докидываю свои драйвера - текст с трассировкой на jira
Решения - madr
Модель веду в конфлюенсе (в текущем проекте), но предпочел бы archi
Представления размазаны по конфлюенсу (rfc) и разным документам (в основном powerpoint)
А хочется единого пространства и удобной трассировки (
#Документирование
👍5
http://microservices.io/i/SuccessTriangleWithBooks.png
Красивая картинка у К. Ричардсона.
"Ignoring those two elements is a common anti-pattern of microservice adoption."
Красивая картинка у К. Ричардсона.
"Ignoring those two elements is a common anti-pattern of microservice adoption."
👍3
Нефункциональные требования и ограничения (Constraints)
Для того чтобы принять оптимальное архитектурное решение необходимо обработать большой массив входящих данных (т.н. архитектурных драйверов или мотивов).
Часть этих данных структурирована, часть нет (т.н. контекст проектирования).
В одном из арх. каналов возник спор по поводу структурированных данных.
Было предложено всех их обобщить термином "требования".
В этом вопросе я придерживаюсь классического подхода - разделяю требования и ограничения.
Зачем? Казалось бы, и то и другое приходит от стейкхолдеров и формирует архитектуру. В чём разница?
Мои резоны:
1. Среди всех стейкхолдеров я выделяю потребителя. Того для кого готовится продукт.
Требования прочих заинтересованных лиц ограничивают развитие продукта, а зачастую и ухудшают его потребительские качества.
Пользователю нужна функциональность, производительность, надежность и безопасность . Это требования.
Служба эксплуатации ограничивает список технологий. Смежники диктуют интерфейсы и протоколы. Бизнес ограничивает время/деньги. Команда предоставляет ограниченный набор скиллов. Это ограничения.
2. Мне нравится подход, при котором я сперва проектирую идеальную архитектуру, которая бы на все сто удовлетворила пользователя, а потом начинаю "портить" ее имеющимися ограничениями.
3. В моем понимании требования непреложны (атрибутивны), а ограничения оспариваемы (акцидентны) и ради хорошего продукта я могу преодолевать ограничения в архитектуре надсистемы.
#АрхитектурныеДрайвера
Для того чтобы принять оптимальное архитектурное решение необходимо обработать большой массив входящих данных (т.н. архитектурных драйверов или мотивов).
Часть этих данных структурирована, часть нет (т.н. контекст проектирования).
В одном из арх. каналов возник спор по поводу структурированных данных.
Было предложено всех их обобщить термином "требования".
В этом вопросе я придерживаюсь классического подхода - разделяю требования и ограничения.
Зачем? Казалось бы, и то и другое приходит от стейкхолдеров и формирует архитектуру. В чём разница?
Мои резоны:
1. Среди всех стейкхолдеров я выделяю потребителя. Того для кого готовится продукт.
Требования прочих заинтересованных лиц ограничивают развитие продукта, а зачастую и ухудшают его потребительские качества.
Пользователю нужна функциональность, производительность, надежность и безопасность . Это требования.
Служба эксплуатации ограничивает список технологий. Смежники диктуют интерфейсы и протоколы. Бизнес ограничивает время/деньги. Команда предоставляет ограниченный набор скиллов. Это ограничения.
2. Мне нравится подход, при котором я сперва проектирую идеальную архитектуру, которая бы на все сто удовлетворила пользователя, а потом начинаю "портить" ее имеющимися ограничениями.
3. В моем понимании требования непреложны (атрибутивны), а ограничения оспариваемы (акцидентны) и ради хорошего продукта я могу преодолевать ограничения в архитектуре надсистемы.
#АрхитектурныеДрайвера
👍5🔥2
Architect - Share.zip
10.7 MB
База знаний в обсидиане
Затемплайтил свою архитектурную базу знаний со структурой, темой и настроенными плагинами.
Теперь для включения в новый проект достаточно распаковать и запустить.
Положу здесь. Возможно, еще кому-нибудь пригодится.
#Документирование
Затемплайтил свою архитектурную базу знаний со структурой, темой и настроенными плагинами.
Теперь для включения в новый проект достаточно распаковать и запустить.
Положу здесь. Возможно, еще кому-нибудь пригодится.
#Документирование
🔥8👍3
Анти-паттерн "42"
Всегда восхищался способностью арх. комов и некоторых продвинутых архитекторов оценить архитектуру по её описанию.
Лично мне трудно оценить правильность ответа на «главный вопрос Жизни, Вселенной и Всего Остального», без понимания вопроса.
При этом под "пониманием вопроса" я подразумеваю не только требования.
В случае архитектуры это еще и глубокое погружение в контекст.
#Антипаттерны #Сарказм
Всегда восхищался способностью арх. комов и некоторых продвинутых архитекторов оценить архитектуру по её описанию.
Лично мне трудно оценить правильность ответа на «главный вопрос Жизни, Вселенной и Всего Остального», без понимания вопроса.
При этом под "пониманием вопроса" я подразумеваю не только требования.
В случае архитектуры это еще и глубокое погружение в контекст.
#Антипаттерны #Сарказм
😁10
Транзакционность
Опять попал на обсуждение вопроса о том, что есть САГА: ACID, ACD или даже CID.
Полная путаница в терминологии приводит к бесконечным холиварам.
Хотел бы здесь зафиксировать своё понимание транзакционности.
1. Транзакция - минимальная логически осмысленная операция.
2. Выполнение транзакции не должно ломать целостность или когерентность данных.
Это свойство называется согласованностью (consistency) в широком смысле слова.
Что бы не путаться я называю его транзакционностью )
То есть транзакция должна быть транзакционной ))
3. Угрозы целостности и когерентности:
- одна из операций транзакции не может быть завершена (по бизнесу)
Решается атомарностью (Atomicity), которую Мартин Клеппман называет abortability.
- операции на разных ресурсах могут выполняться в произвольном порядке
Решается согласованностью в узком (ACID) смысле
- операции от разных клиентов могут мешать друг другу
Решается изолированностью (Isolation)
- операции могут завершится неудачей в следствии сбоя, в частности по таймауту
Решается устойчивостью (Durability)
4. Соответственно, хорошая транзакция должна поддерживать ACID.
Но при этом всегда можно пойти на компромиссы.
План по поддержке транзакционности примерно такой:
1. Определить список основных операций.
2. Определить требования по производительности, надежности и целостности/когерентности
3. Определить требуемый уровень согласованности (по NFR).
4. Определить механизм поддержки согласованности. (централизованный/децентрализованный, синхронный/асинхронный).
5. Определить механизм поддержки атомарности (кто и как делает откаты).
6. Определить требуемый уровень изолированности (по списку операций).
7. Определить механизм устойчивости (например SAGA vs TCC)
8. Реализовать )
#Транзакционность
Опять попал на обсуждение вопроса о том, что есть САГА: ACID, ACD или даже CID.
Полная путаница в терминологии приводит к бесконечным холиварам.
Хотел бы здесь зафиксировать своё понимание транзакционности.
1. Транзакция - минимальная логически осмысленная операция.
2. Выполнение транзакции не должно ломать целостность или когерентность данных.
Это свойство называется согласованностью (consistency) в широком смысле слова.
Что бы не путаться я называю его транзакционностью )
То есть транзакция должна быть транзакционной ))
3. Угрозы целостности и когерентности:
- одна из операций транзакции не может быть завершена (по бизнесу)
Решается атомарностью (Atomicity), которую Мартин Клеппман называет abortability.
- операции на разных ресурсах могут выполняться в произвольном порядке
Решается согласованностью в узком (ACID) смысле
- операции от разных клиентов могут мешать друг другу
Решается изолированностью (Isolation)
- операции могут завершится неудачей в следствии сбоя, в частности по таймауту
Решается устойчивостью (Durability)
4. Соответственно, хорошая транзакция должна поддерживать ACID.
Но при этом всегда можно пойти на компромиссы.
План по поддержке транзакционности примерно такой:
1. Определить список основных операций.
2. Определить требования по производительности, надежности и целостности/когерентности
3. Определить требуемый уровень согласованности (по NFR).
4. Определить механизм поддержки согласованности. (централизованный/децентрализованный, синхронный/асинхронный).
5. Определить механизм поддержки атомарности (кто и как делает откаты).
6. Определить требуемый уровень изолированности (по списку операций).
7. Определить механизм устойчивости (например SAGA vs TCC)
8. Реализовать )
#Транзакционность
👍1
Сага
Продолжая предыдущий пост, хотелось бы ответить на вопрос, что есть Сага.
Ad ovo:
1. В распределенной среде долгоживущие транзакции могут обеспечить транзакционность (ACID) на блокировках. Работает это очень ненадёжно и медленно.
В 1986 году Hector Garcaa-Molrna, Kenneth Salem предложили разбить транзакцию на несколько мелких локальных и назвали это сагой.
С их точки зрения сага была не атомарна, то есть CID.
Так как атомарностью они назвали принцип "Всё или ничего" (БД-шное понимание атомарности).
2. Мартин Клеппман переопределил атомарность как abortability. То есть как возможность прервать и откатить транзакцию в случае отката одной из операций. В этом понимании Сага вполне атомарна (ACID).
3. Однако, в процессе проведения Саги часть транзакций может быть закомичена до общей фиксации. То есть конкуренты увидят результаты незавершенной транзакции. Крис Ричардсон считает, что это явное нарушение изоляции. То есть Сага - ACD.
4. Криса ругают и доказывают, что изоляцию для Саги построить легко. Например, на блокировках. С моей т.з. сага с блокировками противоречит идее создания саги и уже и не сага вовсе. И Крис таки прав.
#Сага #Транзакционность
Продолжая предыдущий пост, хотелось бы ответить на вопрос, что есть Сага.
Ad ovo:
1. В распределенной среде долгоживущие транзакции могут обеспечить транзакционность (ACID) на блокировках. Работает это очень ненадёжно и медленно.
В 1986 году Hector Garcaa-Molrna, Kenneth Salem предложили разбить транзакцию на несколько мелких локальных и назвали это сагой.
С их точки зрения сага была не атомарна, то есть CID.
Так как атомарностью они назвали принцип "Всё или ничего" (БД-шное понимание атомарности).
2. Мартин Клеппман переопределил атомарность как abortability. То есть как возможность прервать и откатить транзакцию в случае отката одной из операций. В этом понимании Сага вполне атомарна (ACID).
3. Однако, в процессе проведения Саги часть транзакций может быть закомичена до общей фиксации. То есть конкуренты увидят результаты незавершенной транзакции. Крис Ричардсон считает, что это явное нарушение изоляции. То есть Сага - ACD.
4. Криса ругают и доказывают, что изоляцию для Саги построить легко. Например, на блокировках. С моей т.з. сага с блокировками противоречит идее создания саги и уже и не сага вовсе. И Крис таки прав.
#Сага #Транзакционность
👍4
BPM-движки
Глядя на различные системы, использующие bpm-движки (camunda, zeebe и ежи с ними), осознаю некоторое неустранимое противоречие.
По пунктам:
1. BPMN - нотация моделирования.
2. BPM - модель процесса. То есть некоторая абстракция, упрощение.
3. Движок предполагает реализацию.
Как авторами концепции предполагалось заполнить пробел между абстракцией и реализацией?
Они реально думали, что модель нарисованная, например аналитиком, сразу же заработает как реализованный алгоритм?
По факту пробел заполняют разработчики, внося в начальную красивую диаграмму массу деталей. При этом преодолевая вязкость нотации bpmn, которая вовсе не хочет становиться языком программирования.
Глядя на различные системы, использующие bpm-движки (camunda, zeebe и ежи с ними), осознаю некоторое неустранимое противоречие.
По пунктам:
1. BPMN - нотация моделирования.
2. BPM - модель процесса. То есть некоторая абстракция, упрощение.
3. Движок предполагает реализацию.
Как авторами концепции предполагалось заполнить пробел между абстракцией и реализацией?
Они реально думали, что модель нарисованная, например аналитиком, сразу же заработает как реализованный алгоритм?
По факту пробел заполняют разработчики, внося в начальную красивую диаграмму массу деталей. При этом преодолевая вязкость нотации bpmn, которая вовсе не хочет становиться языком программирования.
👍3
Архитектурное решение
Мне не нравится когда говорят, что архитектор принимает решение.
Принимать решение удел менеджера.
Архитектор обдумывает и прорабатывает решение.
Процесс архитектора несколько более затратный.
Это не сложный выбор и не волевое действие.
Это полное погружение в задачу, до формирования необходимых нейронных цепей, до ясности понимания.
Нужна архитектура за день? Да пожалуйста. Только то будет не совсем "архитектура".
Мне не нравится когда говорят, что архитектор принимает решение.
Принимать решение удел менеджера.
Архитектор обдумывает и прорабатывает решение.
Процесс архитектора несколько более затратный.
Это не сложный выбор и не волевое действие.
Это полное погружение в задачу, до формирования необходимых нейронных цепей, до ясности понимания.
Нужна архитектура за день? Да пожалуйста. Только то будет не совсем "архитектура".
👍5😱1
Аутсорсинг
Плюс - не скучно.
Минус (жирный) - каждый раз в новом домене и на новой платформе начинаешь с нуля.
Только что был экспертом и опять джун)
Плюс - не скучно.
Минус (жирный) - каждый раз в новом домене и на новой платформе начинаешь с нуля.
Только что был экспертом и опять джун)
Фрагментарность ИТ-знаний
Большая проблема ИТ инженерии - фрагментарность знаний.
При этом каждый фрагмент написан автором на своём, зачастую уникальном, языке.
Причины понятны:
1. Знания формируются бессистемно, рецептурно различными, не связанными с друг другом авторами.
2. Цель - найти приемлемое рабочее решение, и не более.
Приведу пример.
1. Сущность (entity) у Эванса это идентифицируемый объект.
В DDD идентифицируемость указывается как самое важное свойство сущности. При этом Эванс предостерегает от превращения в сущности всего и вся, намекая на некоторые проблемы связанные с поиском эквивалентности.
2. Проблемы сущностей описаны у М. Фаулера в "Аналитических паттернах". Правда термин "сущность" здесь не упоминается. Паттерн называется "обращение к объектам" ("Referring to Objects"). Основные проблемы по Фаулеру порождаются несколькими источниками возникновения сущности. Эти проблемы: множественная идентификация, слияние и поиск эквивалента. Фаулер даёт несколько паттернов решения проблем не углубляясь в их реализацию.
3. Столкнувшись на практике с проблемами сущности вы скорее всего будете реализовывать сущность как золотую запись. Еще один термин, в этот раз из мира управления данными.
Вам потребуется MDM система. Возникнут вопросы связанные с природой сущности (НСИ, товар, продукт, контакт и т. п.), так как для каждого вида существует своя оптимальная MDM (RDM, PDM, CDI и др.)
То есть три разных фрагмента демонстрируют разные уровни работы с одним и тем же объектом, используя разные термины и в общем случае не связанные с друг другом.
Синтезируем это всё в голове архитектора.
И к сожалению, никто не берётся за систематизацию этого бардака (
Большая проблема ИТ инженерии - фрагментарность знаний.
При этом каждый фрагмент написан автором на своём, зачастую уникальном, языке.
Причины понятны:
1. Знания формируются бессистемно, рецептурно различными, не связанными с друг другом авторами.
2. Цель - найти приемлемое рабочее решение, и не более.
Приведу пример.
1. Сущность (entity) у Эванса это идентифицируемый объект.
В DDD идентифицируемость указывается как самое важное свойство сущности. При этом Эванс предостерегает от превращения в сущности всего и вся, намекая на некоторые проблемы связанные с поиском эквивалентности.
2. Проблемы сущностей описаны у М. Фаулера в "Аналитических паттернах". Правда термин "сущность" здесь не упоминается. Паттерн называется "обращение к объектам" ("Referring to Objects"). Основные проблемы по Фаулеру порождаются несколькими источниками возникновения сущности. Эти проблемы: множественная идентификация, слияние и поиск эквивалента. Фаулер даёт несколько паттернов решения проблем не углубляясь в их реализацию.
3. Столкнувшись на практике с проблемами сущности вы скорее всего будете реализовывать сущность как золотую запись. Еще один термин, в этот раз из мира управления данными.
Вам потребуется MDM система. Возникнут вопросы связанные с природой сущности (НСИ, товар, продукт, контакт и т. п.), так как для каждого вида существует своя оптимальная MDM (RDM, PDM, CDI и др.)
То есть три разных фрагмента демонстрируют разные уровни работы с одним и тем же объектом, используя разные термины и в общем случае не связанные с друг другом.
Синтезируем это всё в голове архитектора.
И к сожалению, никто не берётся за систематизацию этого бардака (
👍5🔥1
Утилита для расчета SLA по доступности
Понадобилось быстро перекинуть девятки в часы.
Обычно пользуюсь для этого таблицами.
Сегодня набрел на удобную утилиту, ссылку на которую оставлю здесь.
https://shootnick.ru/uptime/
Понадобилось быстро перекинуть девятки в часы.
Обычно пользуюсь для этого таблицами.
Сегодня набрел на удобную утилиту, ссылку на которую оставлю здесь.
https://shootnick.ru/uptime/
shootnick.ru
Калькулятор SLA: 99.9% аптайм / shootnick.ru
Онлайн-калькулятор SLA: максимальное время простоя при 99.9% аптайме
🔥7
Связывание по структуре данных (stamp coupling)
Казалось, что времена огромных отраслевых XML и таблиц в далёком прошлом.
Ан нет.(
Очередной заказчик предлагает собрать все возможные документы и обобщить их в единую структуру.
Нехилое развлечение для аналитиков.
Вопрос "что будет при появлении новых документов или при модификации существующих" - не возникает.
То, что сервисы шарящие базу, будут связаны как сиамские близнецы - проблема технарей, бизнес не волнует.
Архитектора убежали от SOAP и с ужасом косятся на всякие gRPC. Так получим это все в реляционку.
Есть решение снимающее эти проблемы?
Есть и даже два:
1. Свободный контракт от потребителя
(идеален, но требует зрелости команды)
2. Свободная форма (а ля k-v) + мета
(снимает связанность, но усложняет систему)
Продавливаем второй вариант
Казалось, что времена огромных отраслевых XML и таблиц в далёком прошлом.
Ан нет.(
Очередной заказчик предлагает собрать все возможные документы и обобщить их в единую структуру.
Нехилое развлечение для аналитиков.
Вопрос "что будет при появлении новых документов или при модификации существующих" - не возникает.
То, что сервисы шарящие базу, будут связаны как сиамские близнецы - проблема технарей, бизнес не волнует.
Архитектора убежали от SOAP и с ужасом косятся на всякие gRPC. Так получим это все в реляционку.
Есть решение снимающее эти проблемы?
Есть и даже два:
1. Свободный контракт от потребителя
(идеален, но требует зрелости команды)
2. Свободная форма (а ля k-v) + мета
(снимает связанность, но усложняет систему)
Продавливаем второй вариант
👍2
Архитектор-пропагандист
Хочу представить очень распространенный анти-паттерн "Архитектор-пропагандист".
Проблема:
"Специалист" вместо поиска решения активно продвигает "правильный" вариант, забыв основную мантру архитектора "It depends".
Симптомы:
Фразы типа:
- Это best practices, так все делают
- Это паттерн взятый у [имярек] и он не может быть неправильным
- Мы делали так на предыдущем проекте, и это великолепно работает
Решение:
Любое правильное "решение" должно быть взвешено в конкретном контексте и подвергнуто сравнению с другими решениями.
Следствие:
Приведенное выше решение тоже не всегда верно)
#Антипаттерны
Хочу представить очень распространенный анти-паттерн "Архитектор-пропагандист".
Проблема:
"Специалист" вместо поиска решения активно продвигает "правильный" вариант, забыв основную мантру архитектора "It depends".
Симптомы:
Фразы типа:
- Это best practices, так все делают
- Это паттерн взятый у [имярек] и он не может быть неправильным
- Мы делали так на предыдущем проекте, и это великолепно работает
Решение:
Любое правильное "решение" должно быть взвешено в конкретном контексте и подвергнуто сравнению с другими решениями.
Следствие:
Приведенное выше решение тоже не всегда верно)
#Антипаттерны
👍11🤔1
image_2023-09-23_19-51-09.png
47.7 KB
Логический и физический уровни системы
При архитектурном анализе системы рекомендую подход, разбивающий модель на логический и физический уровни.
Очень многое становится понятным.
Хороший пример области проблемы и решения в DDD.
Другой пример - распределённые транзакции (см. рисунок)
Бизнес процесс состоит из атомарных действий, которые отображаются на физические транзакции и (сюрприз!) не один в один.
Варианты:
Действие1. Идеальный расклад однозначного соответствия. Атомарность действия и атомарность реализации.
Действие 2. Грустный случай разбиения атомарного действия на две не атомарные транзакции. Этого стоило бы избегать, но не всегда возможно.
Можно попытаться связать физические транзакции блокировками (распределённая транзакция) - но получится нестабильно и медленно.
Делаем сагу. На логическом уровне атомарность. На физическом отменяемость (abortability у Martin Kleppmann).
Есть масса способов не дать клиенту увидеть проблемы реализации.
И пусть специалисты спорят атомарна ли сага))
3. Действия 3,4. Чрезмерное усложнение. Так лучше не надо.
Два неатомарных действия лучше догнать по итогу (eventually), чем мучиться с откатом и возможным неуспешным откатом.
#Сага #Saga
При архитектурном анализе системы рекомендую подход, разбивающий модель на логический и физический уровни.
Очень многое становится понятным.
Хороший пример области проблемы и решения в DDD.
Другой пример - распределённые транзакции (см. рисунок)
Бизнес процесс состоит из атомарных действий, которые отображаются на физические транзакции и (сюрприз!) не один в один.
Варианты:
Действие1. Идеальный расклад однозначного соответствия. Атомарность действия и атомарность реализации.
Действие 2. Грустный случай разбиения атомарного действия на две не атомарные транзакции. Этого стоило бы избегать, но не всегда возможно.
Можно попытаться связать физические транзакции блокировками (распределённая транзакция) - но получится нестабильно и медленно.
Делаем сагу. На логическом уровне атомарность. На физическом отменяемость (abortability у Martin Kleppmann).
Есть масса способов не дать клиенту увидеть проблемы реализации.
И пусть специалисты спорят атомарна ли сага))
3. Действия 3,4. Чрезмерное усложнение. Так лучше не надо.
Два неатомарных действия лучше догнать по итогу (eventually), чем мучиться с откатом и возможным неуспешным откатом.
#Сага #Saga
👍4
Контроль потока
При формировании сервисной архитектуры одним из первых стоит вопрос о механизме взаимодействия.
И перед тем как снизойти до технологии нужно определить что это будет sync или async.
То есть будет клиент ждать ответ или отпустит ресурсы и займется своими делами.
Критерии выбора описаны во множестве пособий.
За асинку - эффективность (низкая ресурсоемкость), надежность, безопасность.
За синку - простота (обработка ошибок, отладка), распространённость.
Хотел бы подсветить еще один, редко упоминаемый фактор.
Синк формирует т.н. закрытую модель взаимодействия с предсказуемой нагрузкой.
Пропускная способность здесь пропорциональна количеству пользователей и обратно пропорциональна времени оборота запроса - X <= M/T (до участка насыщения)
Синхронная система саморегулируема.
Появляются новые пользователи -> растет нагрузка -> растет время оклика -> снижается нагрузка. Клиент не шлет новый запрос не дождавшись завершения предыдущего.
В асинке такой защиты нет. Один клиент может накидать в очередь сколь угодно много запросов.
Асинхронная система открыта, в частности всякому DOSу, и должна быть защищена.
Выбирая асинк честный архитектор должен сразу же усложнить нагруженную систему механизмом контроля потока.
Реализовать контроль потока можно по разному:
1. Ограничением нагрузки (rate limiting)
2. Ограничением времени выполнения (deadline)
3. Дросселированием участников (throttling)
4. Обратным давлением (back pressure)
Но сделать это нужно обязательно.
Так что выбирая async на нагруженном участке вы заодно принимаете и усложнение системы. (
#производительность
При формировании сервисной архитектуры одним из первых стоит вопрос о механизме взаимодействия.
И перед тем как снизойти до технологии нужно определить что это будет sync или async.
То есть будет клиент ждать ответ или отпустит ресурсы и займется своими делами.
Критерии выбора описаны во множестве пособий.
За асинку - эффективность (низкая ресурсоемкость), надежность, безопасность.
За синку - простота (обработка ошибок, отладка), распространённость.
Хотел бы подсветить еще один, редко упоминаемый фактор.
Синк формирует т.н. закрытую модель взаимодействия с предсказуемой нагрузкой.
Пропускная способность здесь пропорциональна количеству пользователей и обратно пропорциональна времени оборота запроса - X <= M/T (до участка насыщения)
Синхронная система саморегулируема.
Появляются новые пользователи -> растет нагрузка -> растет время оклика -> снижается нагрузка. Клиент не шлет новый запрос не дождавшись завершения предыдущего.
В асинке такой защиты нет. Один клиент может накидать в очередь сколь угодно много запросов.
Асинхронная система открыта, в частности всякому DOSу, и должна быть защищена.
Выбирая асинк честный архитектор должен сразу же усложнить нагруженную систему механизмом контроля потока.
Реализовать контроль потока можно по разному:
1. Ограничением нагрузки (rate limiting)
2. Ограничением времени выполнения (deadline)
3. Дросселированием участников (throttling)
4. Обратным давлением (back pressure)
Но сделать это нужно обязательно.
Так что выбирая async на нагруженном участке вы заодно принимаете и усложнение системы. (
#производительность
👍11
"Типы" производительности
Любой архитектор знает, что производительность одно из основных качеств программной системы.
Риск не попасть в требования по производительности один из самых вероятных.
Многие при этом догадываются, что под словом "производительность" скрываются абсолютно разные хотелки заказчика.
Розански и Вудс выделили целых шесть типов заинтересованности:
1. Приемлемое время отклика (Фаулер называет это Отзывчивостью, Responsiveness)
2. Приемлемая пропускная способность (Мощность, Capacity)
3. Способность системы справляться с ростом нагрузки (Масштабируемость, Scalability)
4. Приемлемый разброс минимальных и максимальных времен отклика (Предсказуемость, Predictability)
5. Низкая потребность в аппаратных ресурсах (Эффективность, Efficiency)
6. Приемлемое поведение при пиковых нагрузках (Нил Форд и Марк Ричардс называют это качество Адаптируемостью, Adaptability)
Список большой, но на мой взгляд всё-таки не полный 🙂
Часто сталкиваюсь с заинтересованностью заказчика в справедливости (fairness):
Маленькие задачи должны обрабатываться быстро, вне зависимости от наличия больших задач.
У справедливости есть своя метрика - slowdown (отношение времени отклика к размеру задачи).
Желательно, чтобы это отношение было константой.
Есть свои приемы достижения справедливости. В частности различные алгоритмы планирования и балансировки.
Так что справедливость вполне состоявшееся качество.
Включаю в свой список.)
#производительность
Любой архитектор знает, что производительность одно из основных качеств программной системы.
Риск не попасть в требования по производительности один из самых вероятных.
Многие при этом догадываются, что под словом "производительность" скрываются абсолютно разные хотелки заказчика.
Розански и Вудс выделили целых шесть типов заинтересованности:
1. Приемлемое время отклика (Фаулер называет это Отзывчивостью, Responsiveness)
2. Приемлемая пропускная способность (Мощность, Capacity)
3. Способность системы справляться с ростом нагрузки (Масштабируемость, Scalability)
4. Приемлемый разброс минимальных и максимальных времен отклика (Предсказуемость, Predictability)
5. Низкая потребность в аппаратных ресурсах (Эффективность, Efficiency)
6. Приемлемое поведение при пиковых нагрузках (Нил Форд и Марк Ричардс называют это качество Адаптируемостью, Adaptability)
Список большой, но на мой взгляд всё-таки не полный 🙂
Часто сталкиваюсь с заинтересованностью заказчика в справедливости (fairness):
Маленькие задачи должны обрабатываться быстро, вне зависимости от наличия больших задач.
У справедливости есть своя метрика - slowdown (отношение времени отклика к размеру задачи).
Желательно, чтобы это отношение было константой.
Есть свои приемы достижения справедливости. В частности различные алгоритмы планирования и балансировки.
Так что справедливость вполне состоявшееся качество.
Включаю в свой список.)
#производительность
👍5🔥3