✅

https://youtu.be/euxnCZ7ErjY

Опубликовали новое видео с ArchDays 2022

«Майндшифт» или мысли, как Архитектор

Доклад основан на многолетнем практическом опыте и наблюдениях, как одни и те же задачи решаются инженерами и архитекторами решений. На примерах можно понять, как совершить тот самый майндшифт и начать мыслить, как архитектор. Из профессионального опыта — это самое сложное преодоление в карьерном пути инженера.

Смотреть: https://youtu.be/srknAo8OgXs

💎Не забывайте подписываться на канал в YouTube, чтобы не пропустить другой интересный контент

Небольшое дополнение по одной из обсуждённых тем, «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

Было две команды, у одной был руководителем Вася, у другой Петя. Вася был очень сильным разработчиком, он делал самые сложные задачи сам, исправлял любые баги, следил за работой каждого. Петя же не был так силен и старался помочь раскрыть свои способности членам своей команды. Васина команда была на голову выше Петиной. Однако все изменилось, когда Вася и Петя пошли на повышение: Васина команда сразу скатилась в самый низ, так как без него они не могли уже показывать такие хорошие результаты, а Петина команда продолжила работать как и раньше, потихоньку увеличивая свой уровень.

Опубликовали новое видео с ArchDays 2022

«SSO — три заветные буквы MustHave в любой архитектуре»

В докладе Илья рассмотрел эволюцию сервисов SingleSignOn от стародревних oAuth до OIDC и Seamless решений.

Рассказал:
— что такое MobileID,
— в чем проблема реавторизации через «соседнее» приложение,
— почему операторы связи — главные противники Apple и Google.

👉 Смотреть: https://youtu.be/4wao-_xuE_o

Рефакторинг микросервисной архитектуры

Даже грамотно спроектированная микросервисная архитектура с течением времени требует пересмотра и рефакторинга.
— Как не пропустить этот момент в случае проектирования и разработки с нуля?
— Как понять, что легаси микросервисы спроектированы не лучшим образом?
— Как, собственно, начать рефакторинг архитектуры и, немало важно, закончить его и довести до прода в виде реализации?

Руслан ответил на эти и другие вопросы в ходе доклада. А также рассмотрел тревожные сигналы о необходимости рефакторинга, поговорил о принципах рефакторинга в переложении на архитектуру микросервисов, наметил конкретные шаги и этапы безопасного и итерационного рефакторинга архитектуры на практике.

Смотреть: https://youtu.be/foKH9KJjgRI

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

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?

Всем привет)

Какие ресурсы/блоги/рассылки по архитектуре читаете?)

Часто в разные чаты прилетают запросы на разбор реальных архитектурных кейсов.

При этом в больших чатах:
- бывает сложно обсудить кейс, так как у каждого свой интерес и обсуждение постоянно уходит то в одну сторону, то в другую
- во время обсуждения бывает сложно определить, что относится к обсуждению кейса, а что – нет, так как параллельно может идти несколько обсуждений разных тем
- вследствие вышесказанного бывает сложно найти ответы на свой вопрос, тем более спустя некоторое время.

Для решения этих проблем создал отдельную группу в телеграм: «Архитектурные этюды» (правила группы)
Первый кейс уже обсуждается 👌

В этой группе:
- публикуются только кейсовые вопросы
- каждый кейс публикуется в собственном топике
- обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса

Это не первая попытка организовать подобную деятельность. Первая была в 2020-м, но тогда основной замысел был в очных встречах и случился локдаун.

Большой-большой материал по «Data Engineering: ETL, ELT, Data Pipeline, Data Warehouse, Data Lakes, Data Marts»

https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/

Девушки, с праздником! 🌷🥂

Cейчас в чате обсуждаетя (примерно здесь старт https://tttttt.me/microservices_ru/17178), сокращенно:

— Сервисы суют тогда, когда нужно …. масштабироваться горизонтально ….
— ….по-моему нормально монолитом решается
— Ага, особенно хорошо решается монолитом, когда одна часть монолита требует мощный процессор, вторая много оперативки, третья большой диск, и при горизонтальном масштабировании приходится ставить сразу N мега-серверов вне зависимости от того, во что уперлись)

🙂

Ссылки по DevSecOps

- Awesome Threat Modeling
- Awesome Policy-as-Code
- Cloud & DevSecOps Learning Resources
- DevSecOps Roadmap
- DevSecOps Reference Architecture
- OWASP DevSecOps Guideline
- DevSecOps Maturity Model
- OWASP SAMM

#DevSecOps

Всем привет, есть новости 🙂

14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.

А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.

Наблюдения 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.

А я как-то пропустил, что многоликий DDD и на DotNext выложили, доклад похожий, но рассказан немного иначе и все-таки на конференции, а не на митапе 🙂
https://www.youtube.com/watch?v=2WHarUW0PjI

В Архитектурных Этюдах новый кейс.

…Проблемой является периодическая недоступность сервиса nalog.ru. Требуется реализовать возможность накопить сообщения и, когда сервис восстановится, закончить проверку…