Аутсорсинг
Плюс - не скучно.
Минус (жирный) - каждый раз в новом домене и на новой платформе начинаешь с нуля.
Только что был экспертом и опять джун)
Плюс - не скучно.
Минус (жирный) - каждый раз в новом домене и на новой платформе начинаешь с нуля.
Только что был экспертом и опять джун)
Фрагментарность ИТ-знаний
Большая проблема ИТ инженерии - фрагментарность знаний.
При этом каждый фрагмент написан автором на своём, зачастую уникальном, языке.
Причины понятны:
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/upwww.tgoop.com/
Понадобилось быстро перекинуть девятки в часы.
Обычно пользуюсь для этого таблицами.
Сегодня набрел на удобную утилиту, ссылку на которую оставлю здесь.
https://shootnick.ru/upwww.tgoop.com/
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
Задачка на справедливость
Реальная задача из прошлого:
Есть кластер БД (Postgres), который кормится с очереди (Kafka).
Высокая нагрузка. И очень высокие требования по производительности.
Заказчик желает минимизировать задержку.
Неповторяющиеся запросы поступают через случайные промежутки времени (М) и имеют существенный разброс по времени выполнения (G).
То есть очередь M/G/N.
В плюс: запросы регламентированы и можно оценить время их выполнения.
Мы не можем улучшить эффективность выполнения запросов.
Мы не можем докинуть железа.
Что остается?
Играть с планировщиком запросов.
Многие недооценивают этот механизм, но он реально позволяет в разы улучшить среднее время выполнения запросов .
Идеальное решение:
По условию задачи идеальной политикой балансировки/планировщика должна быть общая очередь на SQRT(1) (Central-Queue-SRPT)
Не тут то было (. Сыграть на Postgres "мелодию" с вытеснением запросов - нереально.
- ограничение №1 - слоник.
Можно было бы использовать TAGS(2):
Поставить в ряд несколько инстансов с возрастающими таймаутами и тот, кто не успел обработать свой запрос, передает следующему.
Postgres вполне может прервать задачу по таймауту.
Но нет (
ограничение №2 кластер PG чужой (AD) и кроме тупого FIFO ничего не умеет.
Остаются самые скучные варианты: SJF(3) и FSFC (FIFO).
По среднему времени отклика в наших условиях SJF чуть лучше и вроде бы игра не стоит свеч.
Однако здесь вспоминаем о справедливости.
Клиент, посылающий короткий запрос, не хотел бы ждать, пока система провернет глыбу аналитики.
Строим две очереди: легкие и тяжелые запросы.
Тянем из первой, пока не пусто. Если кончились, идём во вторую.
Но будь моя воля, разобрал бы кластер и поставил цепь из инстансов PG с мапом на размер запроса.
Получил бы очень хорошие показатели )
(1) SQRT - вытесняющий алгоритм планирования, пропускающий вперед запросы с минимальным оставшимся временем обработки
(2) TAGS - “Task Assignment by Guessing Size” успешно используется в Microsoft и Unix системах
(3) SJF - Вначале обрабатывает быстрые запросы
#производительность
Реальная задача из прошлого:
Есть кластер БД (Postgres), который кормится с очереди (Kafka).
Высокая нагрузка. И очень высокие требования по производительности.
Заказчик желает минимизировать задержку.
Неповторяющиеся запросы поступают через случайные промежутки времени (М) и имеют существенный разброс по времени выполнения (G).
То есть очередь M/G/N.
В плюс: запросы регламентированы и можно оценить время их выполнения.
Мы не можем улучшить эффективность выполнения запросов.
Мы не можем докинуть железа.
Что остается?
Играть с планировщиком запросов.
Многие недооценивают этот механизм, но он реально позволяет в разы улучшить среднее время выполнения запросов .
Идеальное решение:
По условию задачи идеальной политикой балансировки/планировщика должна быть общая очередь на SQRT(1) (Central-Queue-SRPT)
Не тут то было (. Сыграть на Postgres "мелодию" с вытеснением запросов - нереально.
- ограничение №1 - слоник.
Можно было бы использовать TAGS(2):
Поставить в ряд несколько инстансов с возрастающими таймаутами и тот, кто не успел обработать свой запрос, передает следующему.
Postgres вполне может прервать задачу по таймауту.
Но нет (
ограничение №2 кластер PG чужой (AD) и кроме тупого FIFO ничего не умеет.
Остаются самые скучные варианты: SJF(3) и FSFC (FIFO).
По среднему времени отклика в наших условиях SJF чуть лучше и вроде бы игра не стоит свеч.
Однако здесь вспоминаем о справедливости.
Клиент, посылающий короткий запрос, не хотел бы ждать, пока система провернет глыбу аналитики.
Строим две очереди: легкие и тяжелые запросы.
Тянем из первой, пока не пусто. Если кончились, идём во вторую.
Но будь моя воля, разобрал бы кластер и поставил цепь из инстансов PG с мапом на размер запроса.
Получил бы очень хорошие показатели )
(1) SQRT - вытесняющий алгоритм планирования, пропускающий вперед запросы с минимальным оставшимся временем обработки
(2) TAGS - “Task Assignment by Guessing Size” успешно используется в Microsoft и Unix системах
(3) SJF - Вначале обрабатывает быстрые запросы
#производительность
👍5
This media is not supported in your browser
VIEW IN TELEGRAM
Иллюстрация к предыдущему посту
Зависимость среднего времени отклика от нагрузки для разных алгоритмов планировщика
Source: Prof. Mor Harchol-Balter, http://www.cs.cmu.edu/~harchol/
P.S. Заменил на гифку - чтобы оценить масштаб проблемы при увеличении вариативности времени выполнения
Зависимость среднего времени отклика от нагрузки для разных алгоритмов планировщика
Source: Prof. Mor Harchol-Balter, http://www.cs.cmu.edu/~harchol/
P.S. Заменил на гифку - чтобы оценить масштаб проблемы при увеличении вариативности времени выполнения
👆 Ну да.)
Любимый "Слоник" вытягивает вариативность за счет многопоточности. Вероятность того что одновременно придет 16 "аналитических" запросов не должна быть высокой.
MS же честно пилит запросы на кванты обеспечивая идеальную справедливость при приемлемой задержке.
Любимый "Слоник" вытягивает вариативность за счет многопоточности. Вероятность того что одновременно придет 16 "аналитических" запросов не должна быть высокой.
MS же честно пилит запросы на кванты обеспечивая идеальную справедливость при приемлемой задержке.
Кстати, в следующую пятницу т.е. 27.10.2023
читаю доклад на ArchDays 2023
Простая «архитектурная» задача и немного ТРИЗ
Заходите, пообщаемся )
https://archdays.ru/?speaker=1346&session=1469
читаю доклад на ArchDays 2023
Простая «архитектурная» задача и немного ТРИЗ
Заходите, пообщаемся )
https://archdays.ru/?speaker=1346&session=1469
ArchDays 2025
Конференция по архитектуре IT-решений
Для всех айтишников, кто следит за современными трендами и хочет участвовать в их развитии
🔥13
Прямоугольники и стрелочки pinned «Кстати, в следующую пятницу т.е. 27.10.2023 читаю доклад на ArchDays 2023 Простая «архитектурная» задача и немного ТРИЗ Заходите, пообщаемся ) https://archdays.ru/?speaker=1346&session=1469»
Наблюдаемость
(Observability)
1. Широко известно, что наблюдаемость необходимое качество системы.
2. Ведем журналы, фиксируем показатели, навешиваем метрики.
3. На вопрос какие метрики стоит навешивать легко отвечаю:
Включайте GOLD. Это правильный набор метрик.
4. Однако, так ли уж важна наблюдаемость. Точнее важна ли она сама по себе.
Если я захочу взять стакан воды, то глаза мне, конечно, пригодятся.
Но кроме этого неплохо бы иметь руки, да и сам стакан не помешает.
5. Для успеха любого действия нужны
- как минимум цель(стакан),
- возможность определить движемся ли мы к цели (глаза)
- и возможность скорректировать движение (руки).
То есть нужно сформировать механизм называемый в кибернетике "положительная обратная связь".
6. Наблюдение имеет смысл, если включено в этот механизм. А то получается как в анекдоте:
- Петька, приборы?
- 40
- Что 40?
- А что приборы?
7. То есть наблюдаемость не тянет на самостоятельность.
Я бы сказал, что это только часть качества.
Само качество надо назвать как-то иначе. (корректируемость ?)
8. Ну и в заключении процитирую один разговор:
- Какие метрики мы должны добавить в нашу систему ?
- Нужные метрики. Те, что позволят вам корректировать качества продукта.
- Это слишком умно (
- Включайте GOLD. Это правильный набор метрик. (сарказм)
#Наблюдаемость
(Observability)
1. Широко известно, что наблюдаемость необходимое качество системы.
2. Ведем журналы, фиксируем показатели, навешиваем метрики.
3. На вопрос какие метрики стоит навешивать легко отвечаю:
Включайте GOLD. Это правильный набор метрик.
4. Однако, так ли уж важна наблюдаемость. Точнее важна ли она сама по себе.
Если я захочу взять стакан воды, то глаза мне, конечно, пригодятся.
Но кроме этого неплохо бы иметь руки, да и сам стакан не помешает.
5. Для успеха любого действия нужны
- как минимум цель(стакан),
- возможность определить движемся ли мы к цели (глаза)
- и возможность скорректировать движение (руки).
То есть нужно сформировать механизм называемый в кибернетике "положительная обратная связь".
6. Наблюдение имеет смысл, если включено в этот механизм. А то получается как в анекдоте:
- Петька, приборы?
- 40
- Что 40?
- А что приборы?
7. То есть наблюдаемость не тянет на самостоятельность.
Я бы сказал, что это только часть качества.
Само качество надо назвать как-то иначе. (корректируемость ?)
8. Ну и в заключении процитирую один разговор:
- Какие метрики мы должны добавить в нашу систему ?
- Нужные метрики. Те, что позволят вам корректировать качества продукта.
- Это слишком умно (
- Включайте GOLD. Это правильный набор метрик. (сарказм)
#Наблюдаемость
👍5
Материалы по модели производительности
Вчера на конференции ArchDays2023 пообещал выложить материалы по мат. моделированию.
Вот то, что мне зашло больше всего:
1. Model-Based Software Performance Analysis
by Vittorio Cortellessa, Antinisca Di Marco, Paola Inverardi
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
рассмотрены различные подходы к моделированию производительности
2. Performance Modeling and Design of Computer Systems: Queueing Theory in Action
by Mor Harchol-Balter
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
ИМХО одна из лучших книг по QNM модели
3. Вообще все, что читал у Harchol-Balter мне нравится.
Рекомендую её сайт, где много материалов для свободного скачивания.
В том числе презентации, "разжевывающие" предыдущую книгу.
https://www.cs.cmu.edu/~harchol/
4. Baron Schwartz практик, использующий модели в проектировании
Его книги есть в свободном доступе
Выкладывал на канале -
- The Essential Guide to Queueing Theory
https://www.tgoop.com/rect_arrow/159
Книга по теории массового обслуживания
- Practical Scalability Analysis With The Universal Scalability Law
https://www.tgoop.com/rect_arrow/167
по USL (масштабирование)
#Книга #производительность
Вчера на конференции ArchDays2023 пообещал выложить материалы по мат. моделированию.
Вот то, что мне зашло больше всего:
1. Model-Based Software Performance Analysis
by Vittorio Cortellessa, Antinisca Di Marco, Paola Inverardi
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
рассмотрены различные подходы к моделированию производительности
2. Performance Modeling and Design of Computer Systems: Queueing Theory in Action
by Mor Harchol-Balter
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
ИМХО одна из лучших книг по QNM модели
3. Вообще все, что читал у Harchol-Balter мне нравится.
Рекомендую её сайт, где много материалов для свободного скачивания.
В том числе презентации, "разжевывающие" предыдущую книгу.
https://www.cs.cmu.edu/~harchol/
4. Baron Schwartz практик, использующий модели в проектировании
Его книги есть в свободном доступе
Выкладывал на канале -
- The Essential Guide to Queueing Theory
https://www.tgoop.com/rect_arrow/159
Книга по теории массового обслуживания
- Practical Scalability Analysis With The Universal Scalability Law
https://www.tgoop.com/rect_arrow/167
по USL (масштабирование)
#Книга #производительность
Telegram
Прямоугольники и стрелочки
Книга по теории массового обслуживания
Вспомнил одну интересную книжку по теории массового обслуживания в аспекте производительности информационных систем.
Очень кратко, но по сути.
Когда-то распространялась бесплатно. Сейчас сайт перепрофилировался.
Выложу…
Вспомнил одну интересную книжку по теории массового обслуживания в аспекте производительности информационных систем.
Очень кратко, но по сути.
Когда-то распространялась бесплатно. Сейчас сайт перепрофилировался.
Выложу…
👍16
Прямоугольники и стрелочки pinned «Материалы по модели производительности Вчера на конференции ArchDays2023 пообещал выложить материалы по мат. моделированию. Вот то, что мне зашло больше всего: 1. Model-Based Software Performance Analysis by Vittorio Cortellessa, Antinisca Di Marco, Paola…»
Максим_Юнусов_Простая_«архитектурная»_задача_и_немного_ТРИЗ.pdf
2.6 MB
Презентация моего доклада на ArchDays 2023
👍12
image_2023-10-30_12-39-52.png
1.7 MB
Зачем нужен архитектор
Возвращаясь к вопросу.
Хотел накидать список полезностей архитектора, но решил проверить в интернете и нашел готовый )
На картинке карта компетенций по solution architecture.
Отвечает на вопросы: что нужно уметь и как себя продавать.
Возвращаясь к вопросу.
Хотел накидать список полезностей архитектора, но решил проверить в интернете и нашел готовый )
На картинке карта компетенций по solution architecture.
Отвечает на вопросы: что нужно уметь и как себя продавать.
👍3
Архитектура как клиническая практика
Работа архитектора в чем-то схожа с работой врача.
Можно найти те же паттерны.
Например:
Пациент жалуется на головную боль
(Заказчику не достает производительности)
1. Подход "технология вперед"
Выпей аспирину - в прошлый раз помогло.
А еще лучше фуфломецин - его везде рекламируют
2. Подход "очевидное решение"
Головная боль - очевидно простуда. Выпей аспирин.
3. Архитектурный подход.
А какие симптомы кроме этого? Кашель, насморк?
Нога болела два дня назад?
Гугл подсказывает, что при таких симптомах нужен аспирин.
4. Инженерный подход.
Симптомы наводят на мысль, но точного диагноза поставить нельзя. Нужно сдать анализы.
Все хором - анализы это же дорого и долго - выпей аспирин.
В общем - очень похоже.
Разница только в том, что архитектор зачастую работает с еще не родившимся "пациентом".
#Сарказм
Работа архитектора в чем-то схожа с работой врача.
Можно найти те же паттерны.
Например:
Пациент жалуется на головную боль
(Заказчику не достает производительности)
1. Подход "технология вперед"
Выпей аспирину - в прошлый раз помогло.
А еще лучше фуфломецин - его везде рекламируют
2. Подход "очевидное решение"
Головная боль - очевидно простуда. Выпей аспирин.
3. Архитектурный подход.
А какие симптомы кроме этого? Кашель, насморк?
Нога болела два дня назад?
Гугл подсказывает, что при таких симптомах нужен аспирин.
4. Инженерный подход.
Симптомы наводят на мысль, но точного диагноза поставить нельзя. Нужно сдать анализы.
Все хором - анализы это же дорого и долго - выпей аспирин.
В общем - очень похоже.
Разница только в том, что архитектор зачастую работает с еще не родившимся "пациентом".
#Сарказм
👍4😁4