Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Книга "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.
Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.
В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).
В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients
Собственно, их и намереваюсь рассмотреть, начав с первой.
#book #iam_general #oauth
Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.
Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.
В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).
В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients
Собственно, их и намереваюсь рассмотреть, начав с первой.
#book #iam_general #oauth
🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Первая часть обзора книги "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
🔵 Как будто больше маркетинга, чем рациональных доводов
🔵 В доводах указываются вещи, которые я бы не связал напрямую с OAuth
🔵 Не хватило секции “почему не что-то другое”
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Илиюный неокрепший ум… Не знаю, в общем.
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
1️⃣ Identity & Access Management — Authorization Server
2️⃣ API Management — API Gateway
3️⃣ Entitlement Management — Policy Engine
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Или
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Cloud native is a technology approach for operating services and infrastructure in a vendor-neutral way.
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[2/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
🔵 валидация входящих временных учетных данных
🔵 трансляция их в JWT access token для конечных сервисов.
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
🔵 Здесь получаете не отдельный токен доступа в виде JWT, а обернутый в JWT тот же ответ от introspection endpoint
🔵 Таким образом два представления токена доступа полноценно не “развязать”: полученный JWT не ограничить отдельно по времени жизни или области действия
🔵 Сами авторы RFC пишут, что возвращаемый здесь JWT “is not an alternative representation of the introspected access token and is not intended to be used as an access token”
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
🔵 Flexibility (API работают только с предоставленным результатом, саму логику контроля доступа можно изменять, не ломая их)
🔵 Auditability (имеем события аудита как для применения политик, так и их для изменения)
🔵 Security agility (отделение ЖЦ политик доступа от ЖЦ конечных сервисов)
🔵 Quality assurance via policy as code (если политики прописываются отдельно, сами сервисы могут не тестировать их внутреннюю логику, а покрывать только возможные исходы)
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
While secure flows are essential, they should be complemented by a keen focus on access tokens.
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
We have seen that your overall API security is distributed between the API gateway APIs, and possibly additional components such as service meshes.
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2🔥1🙏1
Forwarded from Конференция ArchDays
🎙 Пропустили ArchDays MeetUp 3 июля? Запись уже доступна!
Тема «Почему ваш микросервис — это не микросервис, а распределённый монолит?»
Сергей Баранов разобрал, как мнимая модульность превращается в головную боль, и почему иногда монолит — это не провал, а осознанное решение.
Смотрите, где удобно:
YouTube
VK Видео
🗓 А уже 17 июля в 11:00 (GMT+3) — следующий митап ArchDays MeetUp!
📌 Тема: Архитектура для не-технарей: как объяснить сложное просто?
Поговорим о soft skills архитектора:
— какие диаграммы и метафоры реально работают,
— как доносить ценность архитектурных решений на языке выгод,
— и как не провалить презентацию, даже если тема — суперсложная.
🔗 Зарегистрироваться
Тема «Почему ваш микросервис — это не микросервис, а распределённый монолит?»
Сергей Баранов разобрал, как мнимая модульность превращается в головную боль, и почему иногда монолит — это не провал, а осознанное решение.
Смотрите, где удобно:
YouTube
VK Видео
Поговорим о soft skills архитектора:
— какие диаграммы и метафоры реально работают,
— как доносить ценность архитектурных решений на языке выгод,
— и как не провалить презентацию, даже если тема — суперсложная.
🔗 Зарегистрироваться
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
MeetUp ArchDays`25: Почему ваш микросервис — это не микросервис?
Провокационный разбор ошибок в микросервисной архитектуре.
- Признаки «ложных» микросервисов;
- Когда монолит выгоднее?
- Признаки «ложных» микросервисов;
- Когда монолит выгоднее?
🔥4👍2❤1👎1
Forwarded from Конференция ArchDays
Дима Дзюба всем передает привет:
«В своем докладе на ArchDays 24 "Enterprise governance c доставкой в продукт" я рассказывал про инструменты AaaC, которые мы разрабатываем и применяем в Beeline. Я обещал, что мы начнем их выкладывать в Opensource. И вот, с некоторым опозданием, мы начали выкладывать наши инструменты. Первым выложили плагин к Visual Studio Code для работы с архитектурой в нотации Structurizr DSL https://github.com/tech-beeline »
«В своем докладе на ArchDays 24 "Enterprise governance c доставкой в продукт" я рассказывал про инструменты AaaC, которые мы разрабатываем и применяем в Beeline. Я обещал, что мы начнем их выкладывать в Opensource. И вот, с некоторым опозданием, мы начали выкладывать наши инструменты. Первым выложили плагин к Visual Studio Code для работы с архитектурой в нотации Structurizr DSL https://github.com/tech-beeline »
👍5❤1
Forwarded from Сергей Баранов
Мы продолжаем набор спикеров на конференцию ArchDays!
Это первая в РФ конференция по архитектуре, получившая достаточно серьезное признание за 6 лет проведения.
Мы ждем интересные выступление по темам проектирования, корпоративной архитектуре, использовании AI, в том числе построении систем на их базе.
Уверен, компаниям участников этого чата есть чем поделиться.
Конференция пройдет 7 ноября в Москве, подаваться на сайте: http://archdays.ru
Если нужны пояснения, то можно написать мне в ЛС.
Сегодня опубликуем первые включенные в программу выступления
Это первая в РФ конференция по архитектуре, получившая достаточно серьезное признание за 6 лет проведения.
Мы ждем интересные выступление по темам проектирования, корпоративной архитектуре, использовании AI, в том числе построении систем на их базе.
Уверен, компаниям участников этого чата есть чем поделиться.
Конференция пройдет 7 ноября в Москве, подаваться на сайте: http://archdays.ru
Если нужны пояснения, то можно написать мне в ЛС.
Сегодня опубликуем первые включенные в программу выступления
archdays.ru
ArchDays 2025
Конференция по архитектуре IT-решений. 7 ноября Москва + Online
Сколько вы сейчас в компании одновременно используете облачных провайдеров, вроде AWS, Cloud.ru, SberCloud и так далее.
Anonymous Poll
39%
0
38%
1
14%
2
4%
3
2%
4
2%
5+
Архитектор без выстроеннное архитектурной функции – это как отличный футболист, может быть даже с мячом, но без поля и правил. Давайте поговорим об архитектурной функции.
Почему именно сейчас?
Я скоро выпущу статью о проблемах, с которыми сталкиваемся не только мы в свете последнних событий, но и в целом мир, а именно – решения становятся сложнее, риски нарастают, технологии меняются, подходы к работе тоже меняются.
Архитектурная функция в компании – это то, что позволяет выполнять работу архитектора эффективно, интегрируя в общую экосистему бизнес-процессов компании. Не мало компаний в последнее время задумались о найме архитектора или расширения штата и отдают ответственность за построение архитектурной функции самим архитекторам. Но тут есть одно НО, – навыки проектирования, архитектурные навыки не равно навыкам по постронию архитектурной функции. Целостной, слаженной. И мы получаем странные ситуации, – то архитекторы работают в изоляции от всей компании, то наоборот перегибают и выступают в качестве кнута и бутылочного горлышка, а то и вообще непонятно чем занимаются.
Для того, чтобы архитектурная функция заработала, нередко требуется и ребалансировка ответственности и знатная доля дисциплины. Так хочется порешать все возникающие в системах проблемы, ведь кто лучше архитектора знает как все работает, но это ведет к тому, что архитектор уходит не то что от стратегических вопросов, но даже от тактических, становясь своего рода затыкателем дырок в тонущем корабле. Всем удобно. Для архитектора – высокий уровень значимости, для команд и бизнеса - спокойствие. В перспективе это сродни вулкану, который копит напряжение и в какой-то момент взорвется и уйдет хлопнув дверью, еще и вдогонку, возможно, растеряв часть компетенций.
Подходов к построеию архитектурной функции достаточно много, есть три основных категории – централизованная, децентрализованная и гибридная/аутсорсинговая, в каждой из которых обширный выбор методов. И выбирать, конечно, нужно с умом, учитывая, что они еще и комбинируются и в своей структуре не должны стать противоречивыми.
До текущего момента в рамках деятельности я строил в том числе архитектурные функции в рамках более широкого скоупа работ и накопился солидный опыт, который удалось обобщить и подкрепить примерами. Чего там только не было. В ближайшее время опубликую курс на тему организации и развитию арх функции, а пока хотелось бы узнать, насколько уважаемой аудитории эта тема интересна, насколько востребована, насколько откликается, а то может это мои галлюцинации 🙂
Напишите свое мнение, либо опишите свою ситуацию, либо вопросы, либо критику, все, что покажется полезным.
А позже я сюда напишу еще, уже более конкретных вещей.
Спасибо,
Сергей Баранов
Почему именно сейчас?
Я скоро выпущу статью о проблемах, с которыми сталкиваемся не только мы в свете последнних событий, но и в целом мир, а именно – решения становятся сложнее, риски нарастают, технологии меняются, подходы к работе тоже меняются.
Архитектурная функция в компании – это то, что позволяет выполнять работу архитектора эффективно, интегрируя в общую экосистему бизнес-процессов компании. Не мало компаний в последнее время задумались о найме архитектора или расширения штата и отдают ответственность за построение архитектурной функции самим архитекторам. Но тут есть одно НО, – навыки проектирования, архитектурные навыки не равно навыкам по постронию архитектурной функции. Целостной, слаженной. И мы получаем странные ситуации, – то архитекторы работают в изоляции от всей компании, то наоборот перегибают и выступают в качестве кнута и бутылочного горлышка, а то и вообще непонятно чем занимаются.
Для того, чтобы архитектурная функция заработала, нередко требуется и ребалансировка ответственности и знатная доля дисциплины. Так хочется порешать все возникающие в системах проблемы, ведь кто лучше архитектора знает как все работает, но это ведет к тому, что архитектор уходит не то что от стратегических вопросов, но даже от тактических, становясь своего рода затыкателем дырок в тонущем корабле. Всем удобно. Для архитектора – высокий уровень значимости, для команд и бизнеса - спокойствие. В перспективе это сродни вулкану, который копит напряжение и в какой-то момент взорвется и уйдет хлопнув дверью, еще и вдогонку, возможно, растеряв часть компетенций.
Подходов к построеию архитектурной функции достаточно много, есть три основных категории – централизованная, децентрализованная и гибридная/аутсорсинговая, в каждой из которых обширный выбор методов. И выбирать, конечно, нужно с умом, учитывая, что они еще и комбинируются и в своей структуре не должны стать противоречивыми.
До текущего момента в рамках деятельности я строил в том числе архитектурные функции в рамках более широкого скоупа работ и накопился солидный опыт, который удалось обобщить и подкрепить примерами. Чего там только не было. В ближайшее время опубликую курс на тему организации и развитию арх функции, а пока хотелось бы узнать, насколько уважаемой аудитории эта тема интересна, насколько востребована, насколько откликается, а то может это мои галлюцинации 🙂
Напишите свое мнение, либо опишите свою ситуацию, либо вопросы, либо критику, все, что покажется полезным.
А позже я сюда напишу еще, уже более конкретных вещей.
Спасибо,
Сергей Баранов
❤17👍16🔥5❤🔥1
Forwarded from Системный сдвиг
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
👍8❤1😁1
Сегодня состоаялся интересный диалог о стратегических и тактических аспектах в развитии продукта. Так как у нас канал архитектурный, давайте затронем тему стратегических и тактических аспектов в архитектуре.
Начнем с определений, чтобы задать контекст.
Стратегия - cовокупность долгосрочных целей и плана их достижения, охватывающая всю экосистему; формирует «что достичь» и «почему»
Тактика – комплекс краткосрочных мер и решений, обеспечивающих достижение стратегических целей; описывает «как реализовать»
Исходя из определений уже становится понятно, что баланс между стратегией и тактикой – это ложная дихотомия, так как тактика – это то, как достигаются стратегические цели.
Стратегические действия – это своего рода инициативы, меняющие фундаментальные параметры ландшафта (со своих дата центров переезжаем в облака), при этом тактические действия – это оперативные изменения, реализующие стратегические решения (миграция отдельного сервиса в облако).
То есть цели формируют стратегию, стратегия фиксируется через принципы, дорожные карты и портфель, а тактика ежедневно реализует стратегию через проектиные решения, контроль стандартов и оперативное управление данными и техдолгом (если упрощенно).
А если постоянно все реализуется на костылях, то это либо часть стратегии и осознанные действия, либо блуждание в темноте без четких ориентиров. Блуждаие в темноте тоже может быть эффективным, своего рода оппортунистическим, но вероятность этого настолько мала, что я бы не советовал так делать 🙂
Начнем с определений, чтобы задать контекст.
Стратегия - cовокупность долгосрочных целей и плана их достижения, охватывающая всю экосистему; формирует «что достичь» и «почему»
Тактика – комплекс краткосрочных мер и решений, обеспечивающих достижение стратегических целей; описывает «как реализовать»
Исходя из определений уже становится понятно, что баланс между стратегией и тактикой – это ложная дихотомия, так как тактика – это то, как достигаются стратегические цели.
Стратегические действия – это своего рода инициативы, меняющие фундаментальные параметры ландшафта (со своих дата центров переезжаем в облака), при этом тактические действия – это оперативные изменения, реализующие стратегические решения (миграция отдельного сервиса в облако).
То есть цели формируют стратегию, стратегия фиксируется через принципы, дорожные карты и портфель, а тактика ежедневно реализует стратегию через проектиные решения, контроль стандартов и оперативное управление данными и техдолгом (если упрощенно).
А если постоянно все реализуется на костылях, то это либо часть стратегии и осознанные действия, либо блуждание в темноте без четких ориентиров. Блуждаие в темноте тоже может быть эффективным, своего рода оппортунистическим, но вероятность этого настолько мала, что я бы не советовал так делать 🙂
👍9👎3🔥2
Catalog of legacy modernization patterns by Nick Tune:
https://legacy-modernization.io/patterns/
https://legacy-modernization.io/patterns/
Legacy-Modernization.io
Patterns
Common patterns for modernizing legacy systems.
👍8❤2🔥2
"On Orchestrators: You Are All Right, But You Are All Wrong Too"
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
Dlthub
On Orchestrators: You Are All Right, But You Are All Wrong Too
🔥3👍2🙏1
Forwarded from ScrumTrek
This media is not supported in your browser
VIEW IN TELEGRAM
Как обычно представляют роль архитектора? 💎
Это эксперт, который работает с масштабными системами и бюджетами, решает очень сложные задачи. Кажется, это вершина карьеры разработчика — никакой рутины, только стратегия и нестандартные кейсы.
Всё так, но не совсем 😉 В статье вы найдете примеры, инсайты из вакансий, статистические данные и «темные стороны», о которых обычно не говорят ни на собеседованиях, ни коллеги в кулуарах 🤐
Об ожиданиях и реальности от роли архитектора Сергей Баранов🔗 рассказывает в своей статье на vc.ru
Это эксперт, который работает с масштабными системами и бюджетами, решает очень сложные задачи. Кажется, это вершина карьеры разработчика — никакой рутины, только стратегия и нестандартные кейсы.
Всё так, но не совсем 😉 В статье вы найдете примеры, инсайты из вакансий, статистические данные и «темные стороны», о которых обычно не говорят ни на собеседованиях, ни коллеги в кулуарах 🤐
Об ожиданиях и реальности от роли архитектора Сергей Баранов
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
В чате ассоциации идет достаточно бурно обсуждение фитнес-функций. Думаю, что как человек, который строил функции приспособленности в области генетических алгоритмов, а с другой стороны лично знаком с Патриком Куа (соавтором первой книги по Evolutionary Arch) и привозил его в РФ с выступлением на эту тему, а так же много лет применяю концепцию на практике, имею право высказать свое мнение с некоторым запросом на достоверность.
Функция приспособленности в генетических алгоритмах, если очень просто, – это математическая функция, оценивающая качества каждого индивида в популяции. Это по своей сути частный случай целевой функции, направляющей эволюцию в сторону оптимума. Можно сказать, что это математическое описание приспособленности из фразы «выживает самый приспособленный».
На практике это выглядит так, что есть некоторая функция, описывающая индивидуумов, а фитнес-функция оценивает каждого идивидуума, присваивая ему некоторое число, далее происходит селекция родителей для следующего поколения. Фактически - это направление поиска оптимума. В генетических алгоритмах это обычно миллиарды и триллионы индивидуумов. Еще одна важная особенность – фитнес-функция выступает и как критерий остановки алгоритма селекции.
Эти функции построить очень сложно, объективно сложно, особенно часто они страдают от невозможности различать решения различного качества.
Архитектурная же фитнес-функция – это механизм объективной оценки целостности некоторых арх характеристик. Фактически - аналог тестирования функциональных требований, только тут тестируем NFR. И вот тут начинается недопонимание. Цель арх. фитнес-функции – предотвратить деградацию архитектуры со временем. Тут практически не будет свойств оригинальной фитнес-функции, авторы взяли термин и от оригинального термина и придали другие свойства (защита ключевых хар-к, то есть защита от деградации и автономность команд, т.е. возможность принимать командам арх решения, оставаясь в рамках заданных ограничений), от оригинальных свойств осталась только объективная оценка движения архитектуры в нужном направлении.
То есть это в целом не самая простая концепция и поэтому лично мое мнение, что зря они ее втянули в архитектуру. Мало того, что не простая, так еще и не самая широко распространенная (кто знал про фитнес функции до выхода этой книги?). Таким образом авторы через сложную, специализированную терминологию из совершенно другой области взяли понятия и как-бы по аналогии попытались объяснить другую сложную концепцию и вполне логично, что когнитивная нагрузка здесь будет зашкаливать.
То есть у них даже цели разные, в оригинале - поиск оптимального решения, в архитектуре – защита архитектурных качеств системы. И даже природа самих изменений отличается – в генетике это будут дискретные поколения с заменой популяции, а в архитектуре (по концепции самой эволюционной архитектуры) – инкрементальная эволюция с сохранением работающей системы.
При этом AI открывает новые возможности. В целом, когда технологии позволят, нам достаточно будет определить ту самую фитнес функцию и комбинаторно найти наиболее оптимальное решение, это будет ближе к оригиналу, может быть на горизонте нескольких лет это даже станет возможным.
Функция приспособленности в генетических алгоритмах, если очень просто, – это математическая функция, оценивающая качества каждого индивида в популяции. Это по своей сути частный случай целевой функции, направляющей эволюцию в сторону оптимума. Можно сказать, что это математическое описание приспособленности из фразы «выживает самый приспособленный».
На практике это выглядит так, что есть некоторая функция, описывающая индивидуумов, а фитнес-функция оценивает каждого идивидуума, присваивая ему некоторое число, далее происходит селекция родителей для следующего поколения. Фактически - это направление поиска оптимума. В генетических алгоритмах это обычно миллиарды и триллионы индивидуумов. Еще одна важная особенность – фитнес-функция выступает и как критерий остановки алгоритма селекции.
Эти функции построить очень сложно, объективно сложно, особенно часто они страдают от невозможности различать решения различного качества.
Архитектурная же фитнес-функция – это механизм объективной оценки целостности некоторых арх характеристик. Фактически - аналог тестирования функциональных требований, только тут тестируем NFR. И вот тут начинается недопонимание. Цель арх. фитнес-функции – предотвратить деградацию архитектуры со временем. Тут практически не будет свойств оригинальной фитнес-функции, авторы взяли термин и от оригинального термина и придали другие свойства (защита ключевых хар-к, то есть защита от деградации и автономность команд, т.е. возможность принимать командам арх решения, оставаясь в рамках заданных ограничений), от оригинальных свойств осталась только объективная оценка движения архитектуры в нужном направлении.
То есть это в целом не самая простая концепция и поэтому лично мое мнение, что зря они ее втянули в архитектуру. Мало того, что не простая, так еще и не самая широко распространенная (кто знал про фитнес функции до выхода этой книги?). Таким образом авторы через сложную, специализированную терминологию из совершенно другой области взяли понятия и как-бы по аналогии попытались объяснить другую сложную концепцию и вполне логично, что когнитивная нагрузка здесь будет зашкаливать.
То есть у них даже цели разные, в оригинале - поиск оптимального решения, в архитектуре – защита архитектурных качеств системы. И даже природа самих изменений отличается – в генетике это будут дискретные поколения с заменой популяции, а в архитектуре (по концепции самой эволюционной архитектуры) – инкрементальная эволюция с сохранением работающей системы.
При этом AI открывает новые возможности. В целом, когда технологии позволят, нам достаточно будет определить ту самую фитнес функцию и комбинаторно найти наиболее оптимальное решение, это будет ближе к оригиналу, может быть на горизонте нескольких лет это даже станет возможным.
❤5👍3
Forwarded from Конференция ArchDays
🔥 Приглашаем на онлайн-встречу ArchDays MeetUp!
Тема: DDD на практике: как не утонуть в терминах и получить пользу?
Дата и время: 28 августа, 11:00 (GMT+3)
Что обсудим:
🟢 Как выделять ограниченные контексты без «войн» между командами;
🟢 Антипаттерны Domain-Driven Design;
🟢 Примеры успешного и неудачного внедрения DDD.
➡️ Регистрируйтесь по ссылке 👈 и не пропустите полезный митап!
Тема: DDD на практике: как не утонуть в терминах и получить пользу?
Дата и время: 28 августа, 11:00 (GMT+3)
Что обсудим:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7❤🔥2👍2
Forwarded from ScrumTrek
Для команды инженеров красивая диаграмма с десятками стрелок и модных слов выглядит убедительно.
Но для бизнеса это часто просто непонятная схема без ответа на главный вопрос: «Что мы с этого получим?».
В статье Сергея Баранова — о том, как переводить технические решения на язык ценности:
⏱ Чтение займёт ~12 минут
📖 Читать статью
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤1
Конференция ArchDays
🔥 Приглашаем на онлайн-встречу ArchDays MeetUp! Тема: DDD на практике: как не утонуть в терминах и получить пользу? Дата и время: 28 августа, 11:00 (GMT+3) Что обсудим: 🟢 Как выделять ограниченные контексты без «войн» между командами; 🟢 Антипаттерны Domain…
Этого не будет, я заболел, голоса нет. На след неделю перенесем.
😢11👌4💯1