Пообщались с другом о производительности в разработке.
Сколько бы я не пытался рассуждать на эту тему, всегда рассуждения уходят в сторону производительности производственной системы, а все метрики – это метрики ее эффективности, того, как построена система, в которой мы проектируем и разрабатываем. Примеры приведенных метрик никогда не должны использоваться против людей. Круто же, когда мы просто не пропускаем код, усложняющий продукт? Это автоматом учит людей писать более понятный код. Code Review с этим не поможет, при Code Review ты уже мысленно закончил задачу, если реквест кто-то не принял - ты исправляешь код, но исправление не учит как писат более простой код, – это разные режимы решения, разное давление контекста, разные подходы к работе.
Q: Придумали ли уже что-то в мире для сравнения производительности разработчиков?
A: Уже приняли, что сравнить производительность отдельных разработчиков нерально, бизнес-проблемы решать – это не стулья собирать.
Это та ситуация, когда если нужно сравнить, то не нужно сравнить. Хай перформера в сравнении с лоу перформером будет видно невооруженным взглядом и хай перформер отличается чаще наработками, накопленными со временем.
Из того, что имеет смысл – сравние знаний в очень конкретных технологиях. Это имеет смысл, так как знания конкретных технологий – конечны. Чтобы оценить производительность разработчика нужно оценить навык применения этих технологий по отдельности и в комбинации, умение добывать информацию и работать в команде. Ну и опять же, как сравнить производительность в командах, где разработчики работают в парах?
И последнее – попытка сравнить производительность разработчиков по-отдельности приведет к их изоляции и разрушению командной работы (провокации конкуренции), даже если командная работа изначально была.
То есть объективно оценить производительность разработчика в отрыве от окружающего контекста имхо не получится.
Сложную задачу нужно делить на части 🙂
Разработка состоит из трех частей:
1. Знание требуемых технологий
2. Знание предметной области продукта
3. Социальные навыки (умение быть частью команды)
Знание технологий можно оценить даже тестами;
Знание предметной области можно оценить в диалоге и тестовыми заданиями, в которых нужно предложить решение бизнес-задачи (решение кейсов);
Социальные навыки можно оценить по взаимодействию в команде, с коллегами, по решению сложных вопросов, по инициативности, амбициозности, смотря что важно.
В дальнейшем диалоге немного развивалсь мысль и получились такие варианты:
Сложность кода (цикломатическая сложность например). То есть буквально, коммита кода общая сложность выросла, упала или осталась на прежнем уровне. Инструменты для подсчета есть (sonarqube тот же).
Среднее время на разработку при решении задачии, в которой программист принимает участие. Показывает и навык декомпозиции, то есть навык управления сложностью (чем крупнее задача тем выше уровень неопределенности и выше риски; разумная тактика – снижать риски, а за счет декомпозиции мы получаем снижение рисков почти бесплатно), и дисциплину. Тут и софтскилы видно, – будет человек брать задачу которую не понимает (чем выше оценка, тем ниже уровень понимания того, что нужно сделать) или не будет.
Тестовое покрытие, – после коммита тестовое покрытие упало, осталось как было или выросло (sonar тоже умеет считать).
И вообще-то, если сложность выросла или покрытие упало, надо бы такие коммиты отвергать автоматом. Это применение паттерна Build Threshold (сборка падает при нарушении правил проекта - протечки в архитектуре, медленные тесты, нарушение соглашений об оформлении кода).
Еще можно посмотреть через паттерны Short-Lived Branches (бранчи должны быть короткоживущими, в идеале — не более нескольких дней и никогда дольше итерации) и Commit Often (каждый член команды регулярно чекинится в транк - как минимум один раз в день, после готовности каждой задачи) и договориться внутри команды, – если вчера не коммитил, поясни почему. Это провоцирует задать вопрос если затупил, а если человек изворачивается члены команды это тоже быстро заметят.
Сколько бы я не пытался рассуждать на эту тему, всегда рассуждения уходят в сторону производительности производственной системы, а все метрики – это метрики ее эффективности, того, как построена система, в которой мы проектируем и разрабатываем. Примеры приведенных метрик никогда не должны использоваться против людей. Круто же, когда мы просто не пропускаем код, усложняющий продукт? Это автоматом учит людей писать более понятный код. Code Review с этим не поможет, при Code Review ты уже мысленно закончил задачу, если реквест кто-то не принял - ты исправляешь код, но исправление не учит как писат более простой код, – это разные режимы решения, разное давление контекста, разные подходы к работе.
Q: Придумали ли уже что-то в мире для сравнения производительности разработчиков?
A: Уже приняли, что сравнить производительность отдельных разработчиков нерально, бизнес-проблемы решать – это не стулья собирать.
Это та ситуация, когда если нужно сравнить, то не нужно сравнить. Хай перформера в сравнении с лоу перформером будет видно невооруженным взглядом и хай перформер отличается чаще наработками, накопленными со временем.
Из того, что имеет смысл – сравние знаний в очень конкретных технологиях. Это имеет смысл, так как знания конкретных технологий – конечны. Чтобы оценить производительность разработчика нужно оценить навык применения этих технологий по отдельности и в комбинации, умение добывать информацию и работать в команде. Ну и опять же, как сравнить производительность в командах, где разработчики работают в парах?
И последнее – попытка сравнить производительность разработчиков по-отдельности приведет к их изоляции и разрушению командной работы (провокации конкуренции), даже если командная работа изначально была.
То есть объективно оценить производительность разработчика в отрыве от окружающего контекста имхо не получится.
Сложную задачу нужно делить на части 🙂
Разработка состоит из трех частей:
1. Знание требуемых технологий
2. Знание предметной области продукта
3. Социальные навыки (умение быть частью команды)
Знание технологий можно оценить даже тестами;
Знание предметной области можно оценить в диалоге и тестовыми заданиями, в которых нужно предложить решение бизнес-задачи (решение кейсов);
Социальные навыки можно оценить по взаимодействию в команде, с коллегами, по решению сложных вопросов, по инициативности, амбициозности, смотря что важно.
В дальнейшем диалоге немного развивалсь мысль и получились такие варианты:
Сложность кода (цикломатическая сложность например). То есть буквально, коммита кода общая сложность выросла, упала или осталась на прежнем уровне. Инструменты для подсчета есть (sonarqube тот же).
Среднее время на разработку при решении задачии, в которой программист принимает участие. Показывает и навык декомпозиции, то есть навык управления сложностью (чем крупнее задача тем выше уровень неопределенности и выше риски; разумная тактика – снижать риски, а за счет декомпозиции мы получаем снижение рисков почти бесплатно), и дисциплину. Тут и софтскилы видно, – будет человек брать задачу которую не понимает (чем выше оценка, тем ниже уровень понимания того, что нужно сделать) или не будет.
Тестовое покрытие, – после коммита тестовое покрытие упало, осталось как было или выросло (sonar тоже умеет считать).
И вообще-то, если сложность выросла или покрытие упало, надо бы такие коммиты отвергать автоматом. Это применение паттерна Build Threshold (сборка падает при нарушении правил проекта - протечки в архитектуре, медленные тесты, нарушение соглашений об оформлении кода).
Еще можно посмотреть через паттерны Short-Lived Branches (бранчи должны быть короткоживущими, в идеале — не более нескольких дней и никогда дольше итерации) и Commit Often (каждый член команды регулярно чекинится в транк - как минимум один раз в день, после готовности каждой задачи) и договориться внутри команды, – если вчера не коммитил, поясни почему. Это провоцирует задать вопрос если затупил, а если человек изворачивается члены команды это тоже быстро заметят.
Несколько [не]очевидных атрибутов качества (не только) микросервисов
Я опишу с прицелом в микросервисы, но все то же самое актуально для любой [распределенной] системы 🙂
Стоимость исполнения (Execution cost)
Аддитивный атрибут, вычисляемый как денежная стоимость ресурсов, используемых для работы микросервиса.
Сильно зависит от выбранной платформы (aws, google cloud). Стоимость может быть оценена во время проектирования и скорректирована по результатам оценки во время выполнения.
Время отклика (Response time, latency)
Время отклика измеряется измерением времени, прошедшего между отправкой запроса и получением ответа.
Следует сравнивать со временем отклика монолита на тот же запрос.
При измерении синхронных вызовов учитывается максимальное время ответа, а для асинхронных вызовов учитывается среднее время, затраченное на вызов.
Health management / Fault tolerance / Resiliency to failure
Отказоустойчивость. Способность микросервисного решения справляться со сбоями. Микросервис удовлетворяет этому атрибуту качества путем сохранения своего внутреннего состояния и автоматического рестарта с загрузкой последнего наиболее актуального состояния (предшествующего сбою). Под отказоустойчивостью будем понимать как отказоустойчивость вычислений (рестарт), так и согласованность данных (отсутствие потерь данных).
Reusability
Повторное использования – основной способ снижения затрат. Хотя достижение возможностей повторного использования может быть дорогим, оно может существенно снизить стоимость разработки. В основном это достигается за счет закладывания возможностей изменения целей использования микросервиса для использования за пределами домена для которого он проектировался с минимальными изменениями кода.
Я опишу с прицелом в микросервисы, но все то же самое актуально для любой [распределенной] системы 🙂
Стоимость исполнения (Execution cost)
Аддитивный атрибут, вычисляемый как денежная стоимость ресурсов, используемых для работы микросервиса.
Сильно зависит от выбранной платформы (aws, google cloud). Стоимость может быть оценена во время проектирования и скорректирована по результатам оценки во время выполнения.
Время отклика (Response time, latency)
Время отклика измеряется измерением времени, прошедшего между отправкой запроса и получением ответа.
Следует сравнивать со временем отклика монолита на тот же запрос.
При измерении синхронных вызовов учитывается максимальное время ответа, а для асинхронных вызовов учитывается среднее время, затраченное на вызов.
Health management / Fault tolerance / Resiliency to failure
Отказоустойчивость. Способность микросервисного решения справляться со сбоями. Микросервис удовлетворяет этому атрибуту качества путем сохранения своего внутреннего состояния и автоматического рестарта с загрузкой последнего наиболее актуального состояния (предшествующего сбою). Под отказоустойчивостью будем понимать как отказоустойчивость вычислений (рестарт), так и согласованность данных (отсутствие потерь данных).
Reusability
Повторное использования – основной способ снижения затрат. Хотя достижение возможностей повторного использования может быть дорогим, оно может существенно снизить стоимость разработки. В основном это достигается за счет закладывания возможностей изменения целей использования микросервиса для использования за пределами домена для которого он проектировался с минимальными изменениями кода.
Поздравляю всех с наступающим новым годом!
Добра, счастья и благополучия!
🎄🥂
Добра, счастья и благополучия!
🎄🥂
Микросервисы / распределенные системы
Пообщались с другом о производительности в разработке. Сколько бы я не пытался рассуждать на эту тему, всегда рассуждения уходят в сторону производительности производственной системы, а все метрики – это метрики ее эффективности, того, как построена система…
А можно и развить эту тему.
Если рассматривать организацию или команду как единую систему, то при оценке навыков членов команд навык обучения других становится более важным, чем уровень навыка каждого конкретного члена команды в отдельности.
Если один разработчик выполняет задачу в 10 раз быстрее, чем остальные, но не умеет передавать знания — это хуже, чем если он же выполняет в 5 раз быстрее и может научить других делать так же быстро и эффективно.
В первом случае получаем потенциальное бутылочное горлышко и в перспективе: 10x, 1x, 1x, 1x
Во второму случае в перспективе: 5x, 5x, 5x, 5x и рост всех до 10x - это вопрос значительно более короткого промежутка времени.
Если рассматривать организацию или команду как единую систему, то при оценке навыков членов команд навык обучения других становится более важным, чем уровень навыка каждого конкретного члена команды в отдельности.
Если один разработчик выполняет задачу в 10 раз быстрее, чем остальные, но не умеет передавать знания — это хуже, чем если он же выполняет в 5 раз быстрее и может научить других делать так же быстро и эффективно.
В первом случае получаем потенциальное бутылочное горлышко и в перспективе: 10x, 1x, 1x, 1x
Во второму случае в перспективе: 5x, 5x, 5x, 5x и рост всех до 10x - это вопрос значительно более короткого промежутка времени.
Попытка переосмыслить 12 factors с учетом накопленного опыта и нынешних реалий.
https://architecturenotes.co/12-factor-app-revisited/
https://architecturenotes.co/12-factor-app-revisited/
Напишите, пожалуйста, в комментариях, – как вы переводите на русский язык термин Event Sourcing?
Может вместе найдем подходящий термин на русском.
Может вместе найдем подходящий термин на русском.
Микросервисы / распределенные системы
Напишите, пожалуйста, в комментариях, – как вы переводите на русский язык термин Event Sourcing? Может вместе найдем подходящий термин на русском.
Варианты за первые 20 минут (из двух каналов) 😈
Хронология событий
Источник событий
Летопись
Снабженец событий
Эвент Сорсинг
Событийный источник
События как источник
Не переводим (Event Sourcing)
Базирующийся на событиях
Проистекающий из событий
Событийно-обусловленный
Событийно генерируемый
Строящийся из событий
Построенный на событиях
Регистрация событий
Генерация событий
Порождение событий
Хронология событий
Источник событий
Летопись
Снабженец событий
Эвент Сорсинг
Событийный источник
События как источник
Не переводим (Event Sourcing)
Базирующийся на событиях
Проистекающий из событий
Событийно-обусловленный
Событийно генерируемый
Строящийся из событий
Построенный на событиях
Регистрация событий
Генерация событий
Порождение событий
Forwarded from Конференция ArchDays
Опубликовали новое видео с ArchDays 2022
Архитектура масштабирования: ускоряем обработку и повышаем доступность данных
Спикер: Сергей Харламов
Архитектор в VK Digital Tech
Основные Тезисы:
✅ Обзор предпосылок масштабирования и разбор цифровых стратегий современных финансовых организаций;
✅ Паттерны проектирования и технологии масштабирования: кэширование, стриминг, захват изменений;
✅ Примеры проектов: запуск новых online-продуктов, повышение доступности Legacy-систем и частные случаи омниканальности.
https://youtu.be/Zxs4jkiAZ1s
💎Не забывайте подписываться, чтобы не пропустить другой интересный контент на канале
Архитектура масштабирования: ускоряем обработку и повышаем доступность данных
Спикер: Сергей Харламов
Архитектор в VK Digital Tech
Основные Тезисы:
✅ Обзор предпосылок масштабирования и разбор цифровых стратегий современных финансовых организаций;
✅ Паттерны проектирования и технологии масштабирования: кэширование, стриминг, захват изменений;
✅ Примеры проектов: запуск новых online-продуктов, повышение доступности Legacy-систем и частные случаи омниканальности.
https://youtu.be/Zxs4jkiAZ1s
💎Не забывайте подписываться, чтобы не пропустить другой интересный контент на канале
YouTube
Архитектура масштабирования: ускоряем обработку и повышаем доступность данных. Сергей Харламов
Выступление на ArchDays 2022. Подробнее о конференции: https://archconf.ru/arch
Основные Тезисы:
— Обзор предпосылок масштабирования и разбор цифровых стратегий современных финансовых организаций;
— Паттерны проектирования и технологии масштабирования: кэширование…
Основные Тезисы:
— Обзор предпосылок масштабирования и разбор цифровых стратегий современных финансовых организаций;
— Паттерны проектирования и технологии масштабирования: кэширование…
Практики безопасности в микросервисах с точки зрения DevOps
Скорее всего после июня вынесу блок по безопасности из курса по проектированию микросервисов в отдельный отднодневный курс, опциональный модуль или вообще запишу серию видео и залью на ютуб всем на радость 🙂 Блок не на массового участника, конечно, под конкретный запрос. По-прежнему в 80% случаев безопасность живет в своем silo и применимость равно как и обозначенная в курсе проблематика безопасности просто не применимы в такой ситуации, да и не встраивается в существующую картину мира, если разработчик или архитектор полностью изолирован от вопросов безопасности.
Одна из основ DevOps – три пути DevOps
Небольой список практик и паттернов из мира DevSecOps, которые крайне полезны, а порой и жизненно необходимы при работе над распределенными системами (хотя будут полезны и сами по себе, конечно).
Практики первого пути (системное мышление, ускорение потока)
– Dev и Ops не ждут безопасность, безопасность – часть повседневной работы
– Использование SAST/DAST c тонкой настройка для снижения false positive
– Внутренняя база знаний с code snippets защищенного кода (как шифруем, как работаем с сертификатами, как экранируем)
– Использование актуальных версий образов
– Параллельный Security Pipeline для глубокого тестирования
– Использование Unit-тестов для проверки сценариев безопасности
– Stop The Line для дефектов безопасности
Практики второго пути (Shift Left, усиление обратной связи)
– Введение роли Security Champion, – ключевой контакт по всем вопросам ИБ в рамках конкретной команды
– Security Checks by Dev&Ops, так как поиск уязвимостей внешними компаниями не повышает навыки сотрудников, повышают периодические совместные проверки безопасности
– Тестирование безопасности на этапе анализа требований и проработки архитектуры решения, в том числе практики моделирования угроз на уровне команд
– Остановка сборки, если обнаружена серьезная уязвимость. Безопасность — часть процесса обеспечения качества.
Практики третьего пути (культура экспериментов и обучения)
– Обучение разработчиков безопасности, так как беза – сложная область знаний и навыков и ей необходимо обучать
– Проведение в командах совместных сессий по взлому (Mob hacking), организуемых Security Champions
– Анализ метрик безопасности, поиск паттернов и реакция на них; метрики безопасности как часть общей Immune System
– Введение практик Security Knowledge Management
– Проведение ретроспектив после инцидентов (Security Postmortems) с проверкой всех сервисов на наличие уязвимостей, подобных обнаруженной
Про какую практику имеет смысл рассказать/записать в первую очередь?
Скорее всего после июня вынесу блок по безопасности из курса по проектированию микросервисов в отдельный отднодневный курс, опциональный модуль или вообще запишу серию видео и залью на ютуб всем на радость 🙂 Блок не на массового участника, конечно, под конкретный запрос. По-прежнему в 80% случаев безопасность живет в своем silo и применимость равно как и обозначенная в курсе проблематика безопасности просто не применимы в такой ситуации, да и не встраивается в существующую картину мира, если разработчик или архитектор полностью изолирован от вопросов безопасности.
Одна из основ DevOps – три пути DevOps
Небольой список практик и паттернов из мира DevSecOps, которые крайне полезны, а порой и жизненно необходимы при работе над распределенными системами (хотя будут полезны и сами по себе, конечно).
Практики первого пути (системное мышление, ускорение потока)
– Dev и Ops не ждут безопасность, безопасность – часть повседневной работы
– Использование SAST/DAST c тонкой настройка для снижения false positive
– Внутренняя база знаний с code snippets защищенного кода (как шифруем, как работаем с сертификатами, как экранируем)
– Использование актуальных версий образов
– Параллельный Security Pipeline для глубокого тестирования
– Использование Unit-тестов для проверки сценариев безопасности
– Stop The Line для дефектов безопасности
Практики второго пути (Shift Left, усиление обратной связи)
– Введение роли Security Champion, – ключевой контакт по всем вопросам ИБ в рамках конкретной команды
– Security Checks by Dev&Ops, так как поиск уязвимостей внешними компаниями не повышает навыки сотрудников, повышают периодические совместные проверки безопасности
– Тестирование безопасности на этапе анализа требований и проработки архитектуры решения, в том числе практики моделирования угроз на уровне команд
– Остановка сборки, если обнаружена серьезная уязвимость. Безопасность — часть процесса обеспечения качества.
Практики третьего пути (культура экспериментов и обучения)
– Обучение разработчиков безопасности, так как беза – сложная область знаний и навыков и ей необходимо обучать
– Проведение в командах совместных сессий по взлому (Mob hacking), организуемых Security Champions
– Анализ метрик безопасности, поиск паттернов и реакция на них; метрики безопасности как часть общей Immune System
– Введение практик Security Knowledge Management
– Проведение ретроспектив после инцидентов (Security Postmortems) с проверкой всех сервисов на наличие уязвимостей, подобных обнаруженной
Про какую практику имеет смысл рассказать/записать в первую очередь?
Forwarded from Code of Architecture
Обсудим архитектурные стили на втором стриме по Distributed Systems 💡
🕓 Но сначала о времени эфира: в этот понедельник начнем в 17:00 по Москве.
На стриме разберем вторую главу Architecture. В ней авторы дают определение software и system architecture, а также рассказывают про архитектурные стили:
— Layered architectures;
— Service-oriented architectures;
— Publish-subscribe architectures.
Также в главе разбирается промежуточный слой (middleware), который играет большое значение в распределенных системах. Далее ван Стин и Таненбаум переходят к рассмотрению системных архитектур, в которых они выделяют:
— Layered-system architectures (простая клиент-серверная архитектура, multitiered architectures);
— Symmetrically distributed system architectures (peer-to-peer системы);
— Hybrid system architectures (здесь рассказывается про cloud computing, edge-cloud computing и blockchain).
Гостями стрима станут наш коллега Алексей Тарасов, которых развивает архитектуру Тинькофф Инвестиций, и Сергей Баранов организатор и создатель конференции ArchDays, а еще автор Agile Mindset и телеграм-канала «Микросервисы — русскоязычное сообщество».
🗓Встречаемся в следующий понедельник 23 января в 17:00 по Москве на нашем ютуб-канале.
🕓 Но сначала о времени эфира: в этот понедельник начнем в 17:00 по Москве.
На стриме разберем вторую главу Architecture. В ней авторы дают определение software и system architecture, а также рассказывают про архитектурные стили:
— Layered architectures;
— Service-oriented architectures;
— Publish-subscribe architectures.
Также в главе разбирается промежуточный слой (middleware), который играет большое значение в распределенных системах. Далее ван Стин и Таненбаум переходят к рассмотрению системных архитектур, в которых они выделяют:
— Layered-system architectures (простая клиент-серверная архитектура, multitiered architectures);
— Symmetrically distributed system architectures (peer-to-peer системы);
— Hybrid system architectures (здесь рассказывается про cloud computing, edge-cloud computing и blockchain).
Гостями стрима станут наш коллега Алексей Тарасов, которых развивает архитектуру Тинькофф Инвестиций, и Сергей Баранов организатор и создатель конференции ArchDays, а еще автор Agile Mindset и телеграм-канала «Микросервисы — русскоязычное сообщество».
🗓Встречаемся в следующий понедельник 23 января в 17:00 по Москве на нашем ютуб-канале.
Please open Telegram to view this post
VIEW IN TELEGRAM
Оставлю здесь, чтобы скидывать ссылку при необходимости объяснить разницу между layers и tiers.
The basic idea for the layered style is simple: components are organized in a layered fashion where a component at layer Lj can make a downcall to a component at a lower-level layer Li (with i < j) and generally expects a response. Only in exceptional cases will an upcall be made to a higher-level component.
….
Many distributed applications are divided into three layers: (1) a user-interface layer, (2) a processing layer, and (3) a data layer. One approach for organizing clients and servers is then to distribute these layers across different machines…. As a first step, we make a distinction between only two kinds of machines: client machines and server machines, leading to what is also referred to as a (physically) two-tiered architecture.
Источник: M. van Steen and A.S. Tanenbaum, Distributed Systems, 4th ed., distributed-systems.net, 2023.
—
Layers - логическая граница, tiers - физическая.
The basic idea for the layered style is simple: components are organized in a layered fashion where a component at layer Lj can make a downcall to a component at a lower-level layer Li (with i < j) and generally expects a response. Only in exceptional cases will an upcall be made to a higher-level component.
….
Many distributed applications are divided into three layers: (1) a user-interface layer, (2) a processing layer, and (3) a data layer. One approach for organizing clients and servers is then to distribute these layers across different machines…. As a first step, we make a distinction between only two kinds of machines: client machines and server machines, leading to what is also referred to as a (physically) two-tiered architecture.
Источник: M. van Steen and A.S. Tanenbaum, Distributed Systems, 4th ed., distributed-systems.net, 2023.
—
Layers - логическая граница, tiers - физическая.
Мы все всё время учимся. Допустим, вы точно решили, что вам нужно сходить на какой-то курс. Если есть выбор в каком формате сходить на курс, то что вы выберете?
(курсы практические, без видеозаписей)
(курсы практические, без видеозаписей)
Anonymous Poll
16%
2 дня по 8 часов с перерывами
13%
4 дня по 4 часа в первой половине дня
8%
4 дня по 4 часа во второй половине дня
49%
8 дней (2-3 раза в неделю) по 2 часа по вечерам
14%
8 дней (2-3 раза в неделю) в рабочее время
Forwarded from Конференция ArchDays
Опубликовали новое видео с ArchDays 2022
«Майндшифт» или мысли, как Архитектор
Доклад основан на многолетнем практическом опыте и наблюдениях, как одни и те же задачи решаются инженерами и архитекторами решений. На примерах можно понять, как совершить тот самый майндшифт и начать мыслить, как архитектор. Из профессионального опыта — это самое сложное преодоление в карьерном пути инженера.
Смотреть: https://youtu.be/srknAo8OgXs
💎Не забывайте подписываться на канал в YouTube, чтобы не пропустить другой интересный контент
«Майндшифт» или мысли, как Архитектор
Доклад основан на многолетнем практическом опыте и наблюдениях, как одни и те же задачи решаются инженерами и архитекторами решений. На примерах можно понять, как совершить тот самый майндшифт и начать мыслить, как архитектор. Из профессионального опыта — это самое сложное преодоление в карьерном пути инженера.
Смотреть: https://youtu.be/srknAo8OgXs
💎Не забывайте подписываться на канал в YouTube, чтобы не пропустить другой интересный контент
Микросервисы / распределенные системы
✅ https://youtu.be/euxnCZ7ErjY
Небольшое дополнение по одной из обсуждённых тем, «layer communication protocols»:
Важно обратить внимание, что использование layer communication protocols ведет к деградации производительности, но при этом дает и существенные выгоды:
- Модульная структура открывает возможности для самых различных комбинаций, например возможность добавлять и убирать слои в зависимости от требований. You only pay for what you use.
- При аккуратной декомпозиции вышестоящие протоколы могут быть реализованы и протестированы значительно быстрее, чем крупный, монолитный протокол
- Протоколы могут быть взаимозаменяемыми (например, выбор протокола под профиль нагрузки)
- Верифицировать корректность работы небольшого протокола проще
Среди минусов:
- Вычислительный оверхед
- Оверхед в передаваемых данных, в основном в заголовках между уровнями
- Зависимость слоев друг от друга
Из-за того, что в типовой системе сообщению требуется пройти 10 и более слоев, оверхед от пересечения границ протоколов может оказаться даже выше, чем затраты на выполнение полезной нагрузки.
Работы по оптимизации не прекращаются, среди направлений:
- Оптимизация вычислительной нагрузки
- Сжатие заголовков
- Отложенная обработка (например отложенная буферизация сообщения)
По мотивам: https://www.cs.cornell.edu/projects/spinglass/public_pdfs/Optimizing%20Layered.pdf
Важно обратить внимание, что использование layer communication protocols ведет к деградации производительности, но при этом дает и существенные выгоды:
- Модульная структура открывает возможности для самых различных комбинаций, например возможность добавлять и убирать слои в зависимости от требований. You only pay for what you use.
- При аккуратной декомпозиции вышестоящие протоколы могут быть реализованы и протестированы значительно быстрее, чем крупный, монолитный протокол
- Протоколы могут быть взаимозаменяемыми (например, выбор протокола под профиль нагрузки)
- Верифицировать корректность работы небольшого протокола проще
Среди минусов:
- Вычислительный оверхед
- Оверхед в передаваемых данных, в основном в заголовках между уровнями
- Зависимость слоев друг от друга
Из-за того, что в типовой системе сообщению требуется пройти 10 и более слоев, оверхед от пересечения границ протоколов может оказаться даже выше, чем затраты на выполнение полезной нагрузки.
Работы по оптимизации не прекращаются, среди направлений:
- Оптимизация вычислительной нагрузки
- Сжатие заголовков
- Отложенная обработка (например отложенная буферизация сообщения)
По мотивам: https://www.cs.cornell.edu/projects/spinglass/public_pdfs/Optimizing%20Layered.pdf
Было две команды, у одной был руководителем Вася, у другой Петя. Вася был очень сильным разработчиком, он делал самые сложные задачи сам, исправлял любые баги, следил за работой каждого. Петя же не был так силен и старался помочь раскрыть свои способности членам своей команды. Васина команда была на голову выше Петиной. Однако все изменилось, когда Вася и Петя пошли на повышение: Васина команда сразу скатилась в самый низ, так как без него они не могли уже показывать такие хорошие результаты, а Петина команда продолжила работать как и раньше, потихоньку увеличивая свой уровень.
Forwarded from Конференция ArchDays
Опубликовали новое видео с ArchDays 2022
«SSO — три заветные буквы MustHave в любой архитектуре»
В докладе Илья рассмотрел эволюцию сервисов SingleSignOn от стародревних oAuth до OIDC и Seamless решений.
Рассказал:
— что такое MobileID,
— в чем проблема реавторизации через «соседнее» приложение,
— почему операторы связи — главные противники Apple и Google.
👉 Смотреть: https://youtu.be/4wao-_xuE_o
«SSO — три заветные буквы MustHave в любой архитектуре»
В докладе Илья рассмотрел эволюцию сервисов SingleSignOn от стародревних oAuth до OIDC и Seamless решений.
Рассказал:
— что такое MobileID,
— в чем проблема реавторизации через «соседнее» приложение,
— почему операторы связи — главные противники Apple и Google.
👉 Смотреть: https://youtu.be/4wao-_xuE_o