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
Forwarded from Конференция ArchDays
Рефакторинг микросервисной архитектуры
Даже грамотно спроектированная микросервисная архитектура с течением времени требует пересмотра и рефакторинга.
— Как не пропустить этот момент в случае проектирования и разработки с нуля?
— Как понять, что легаси микросервисы спроектированы не лучшим образом?
— Как, собственно, начать рефакторинг архитектуры и, немало важно, закончить его и довести до прода в виде реализации?
Руслан ответил на эти и другие вопросы в ходе доклада. А также рассмотрел тревожные сигналы о необходимости рефакторинга, поговорил о принципах рефакторинга в переложении на архитектуру микросервисов, наметил конкретные шаги и этапы безопасного и итерационного рефакторинга архитектуры на практике.
Смотреть: https://youtu.be/foKH9KJjgRI
Даже грамотно спроектированная микросервисная архитектура с течением времени требует пересмотра и рефакторинга.
— Как не пропустить этот момент в случае проектирования и разработки с нуля?
— Как понять, что легаси микросервисы спроектированы не лучшим образом?
— Как, собственно, начать рефакторинг архитектуры и, немало важно, закончить его и довести до прода в виде реализации?
Руслан ответил на эти и другие вопросы в ходе доклада. А также рассмотрел тревожные сигналы о необходимости рефакторинга, поговорил о принципах рефакторинга в переложении на архитектуру микросервисов, наметил конкретные шаги и этапы безопасного и итерационного рефакторинга архитектуры на практике.
Смотреть: https://youtu.be/foKH9KJjgRI
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Mike Beedle (died at March 23, 2018)
Agile Manifesto co-creator
proposed the term “agile” to manifesto co-creators introduced “Enterprise Scrum” and “Business Agility”
Source: https://twitter.com/mikebeedle/status/976500772438409216
Agile Manifesto co-creator
proposed the term “agile” to manifesto co-creators introduced “Enterprise Scrum” and “Business Agility”
Source: https://twitter.com/mikebeedle/status/976500772438409216
A Definition of Done for Architectural Decisions
https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9
В целом хороший перечень пунктов с конкретикой, касающихся:
- Доказательной базы
- Критериев оценки и наличия альтернатив
- Непосредственно процесса принятия решения
- Документации
- Реализации и плана пересмотра решения
Пример
Are we confident enough that this design will work?
Have we decided between at least two options, and compared them (semi-)systematically?
Have we discussed among each other and with peers just enough and come to a common view?
Have we captured the decision outcome and shared the decision record?
Do we know when to realize, review and possibly revise this decision?
https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9
В целом хороший перечень пунктов с конкретикой, касающихся:
- Доказательной базы
- Критериев оценки и наличия альтернатив
- Непосредственно процесса принятия решения
- Документации
- Реализации и плана пересмотра решения
Пример
Are we confident enough that this design will work?
Have we decided between at least two options, and compared them (semi-)systematically?
Have we discussed among each other and with peers just enough and come to a common view?
Have we captured the decision outcome and shared the decision record?
Do we know when to realize, review and possibly revise this decision?
Всем привет)
Какие ресурсы/блоги/рассылки по архитектуре читаете?)
Какие ресурсы/блоги/рассылки по архитектуре читаете?)
Часто в разные чаты прилетают запросы на разбор реальных архитектурных кейсов.
При этом в больших чатах:
- бывает сложно обсудить кейс, так как у каждого свой интерес и обсуждение постоянно уходит то в одну сторону, то в другую
- во время обсуждения бывает сложно определить, что относится к обсуждению кейса, а что – нет, так как параллельно может идти несколько обсуждений разных тем
- вследствие вышесказанного бывает сложно найти ответы на свой вопрос, тем более спустя некоторое время.
Для решения этих проблем создал отдельную группу в телеграм: «Архитектурные этюды» (правила группы)
Первый кейс уже обсуждается 👌
В этой группе:
- публикуются только кейсовые вопросы
- каждый кейс публикуется в собственном топике
- обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса
Это не первая попытка организовать подобную деятельность. Первая была в 2020-м, но тогда основной замысел был в очных встречах и случился локдаун.
При этом в больших чатах:
- бывает сложно обсудить кейс, так как у каждого свой интерес и обсуждение постоянно уходит то в одну сторону, то в другую
- во время обсуждения бывает сложно определить, что относится к обсуждению кейса, а что – нет, так как параллельно может идти несколько обсуждений разных тем
- вследствие вышесказанного бывает сложно найти ответы на свой вопрос, тем более спустя некоторое время.
Для решения этих проблем создал отдельную группу в телеграм: «Архитектурные этюды» (правила группы)
Первый кейс уже обсуждается 👌
В этой группе:
- публикуются только кейсовые вопросы
- каждый кейс публикуется в собственном топике
- обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса
Это не первая попытка организовать подобную деятельность. Первая была в 2020-м, но тогда основной замысел был в очных встречах и случился локдаун.
Большой-большой материал по «Data Engineering: ETL, ELT, Data Pipeline, Data Warehouse, Data Lakes, Data Marts»
https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/
https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/
Cейчас в чате обсуждаетя (примерно здесь старт https://tttttt.me/microservices_ru/17178), сокращенно:
— Сервисы суют тогда, когда нужно …. масштабироваться горизонтально ….
— ….по-моему нормально монолитом решается
— Ага, особенно хорошо решается монолитом, когда одна часть монолита требует мощный процессор, вторая много оперативки, третья большой диск, и при горизонтальном масштабировании приходится ставить сразу N мега-серверов вне зависимости от того, во что уперлись)
🙂
— Сервисы суют тогда, когда нужно …. масштабироваться горизонтально ….
— ….по-моему нормально монолитом решается
— Ага, особенно хорошо решается монолитом, когда одна часть монолита требует мощный процессор, вторая много оперативки, третья большой диск, и при горизонтальном масштабировании приходится ставить сразу N мега-серверов вне зависимости от того, во что уперлись)
🙂
Всем привет, есть новости 🙂
14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.
А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.
14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.
А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.
AgileDays 2023
Воркшоп Event Storming
Онлайн-воркшоп спикера Сергей Баранов — 14.04.2023
Наблюдения Jim Hurne, technical lead for a "services" team within IBM Watson касательно структуры команд под микросервисы:
Many of the organizations that have successfully applied the microservices style (e.g. Amazon, Netflix) have had a similar internal team structure:
- Teams are responsible for one or more services
- No service is owned by more than one team
- Teams are relatively autonomous and are free to make independent implementation choices, so long as they adhere to the agreed-upon APIs and service contracts.
- Teams contain the complete skill set necessary to support a service from inception to deployment (product management, development, operations, database administration, production support, etc).
- While teams are loosely coupled from internal implementation details, they are tightly aligned on overall organizational goals.
Many of the organizations that have successfully applied the microservices style (e.g. Amazon, Netflix) have had a similar internal team structure:
- Teams are responsible for one or more services
- No service is owned by more than one team
- Teams are relatively autonomous and are free to make independent implementation choices, so long as they adhere to the agreed-upon APIs and service contracts.
- Teams contain the complete skill set necessary to support a service from inception to deployment (product management, development, operations, database administration, production support, etc).
- While teams are loosely coupled from internal implementation details, they are tightly aligned on overall organizational goals.