на

В истории S3 есть момент, который архитекторы иногда пересказывают как "AWS придумала новый consensus algorithm". Я бы формулировал точнее: AWS не раскрывала публично новый алгоритм уровня Raft или Paxos, но в 2020 S3 получил strong read-after-write consistency для GET, PUT и LIST без заявленного ухудшения performance и без глобальной координации. И вот инженерно это намного интереснее самого названия алгоритма. ([Amazon Web Services, Inc.][1])

Представим наивную distributed storage. Есть 3 replica, запись подтверждаем после W=2, чтение делаем с R=2. Тогда:

W + R > N
2 + 2 > 3

Кворумы обязательно пересекаются хотя бы в одной replica, поэтому можно определить актуальную версию. Но за consistency платим coordination latency: если RTT до replica 1, 3 и 12 мс, запись зависит уже не от быстрейшей машины, а минимум от второй успевшей подтвердить.

На масштабе S3 проблема становится жестче. Нельзя просто посадить миллиарды ключей на один consensus group - leader превратится в bottleneck. Значит, coordination domain надо дробить, маршрутизацию делать локальной, а metadata и версии объектов обновлять так, чтобы независимые ключи практически не мешали друг другу.

Именно здесь архитектура выигрывает у "более быстрого алгоритма". Если миллион независимых ключей распределить между 10000 coordination groups, средняя область конкуренции уменьшается примерно:

1 000 000 / 10 000 = 100 ключей на group.

Теперь consensus остается локальным, а throughput масштабируется горизонтально.

В итоге S3 получил сильную консистентность при сохранении региональной изоляции, а приложениям больше не понадобились отдельные слои вроде S3Guard только ради согласованного представления данных. Позже conditional writes позволили еще и переносить optimistic concurrency control непосредственно в S3 вместо внешних lock-сервисов. ([Amazon Web Services, Inc.][1])

Для меня это хороший пример зрелой distributed architecture: настоящий прорыв часто не в том, чтобы придумать "Raft быстрее Raft", а в том, чтобы уменьшить область, внутри которой consensus вообще необходим.

[1]: https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/?utm_source=chatgpt.com "Amazon S3 Update – Strong Read-After-Write Consistency | AWS News Blog"

#заметкиархитектора #история

Головне не в житті не вийти на себе)

#жартипроандрія

Після 2014 року я вперше по справжньому побачив, як в Україні працює технологічна допомога армії.

Я тоді займався машинним навчанням. До мене прийшли військові з ідеєю автоматичної турелі. Камера знаходить людину, система визначає свій це чи чужий, сама наводиться і відкриває вогонь. Без маячків, без електронної ідентифікації, тільки по зображенню.

Я пояснив, що це матиме величезну похибку. Камуфляж, погане освітлення, трофейна форма, закрите обличчя, нестача нормальних даних. Сказав, що помилка легко перевищить 25 відсотків.

Мені відповіли: нормально, нас влаштовує.

Тобто система може вбивати своїх, і це для когось прийнятна статистика. Я подивився на них і сказав, що в такому лайні участі не братиму.

Наприкінці 2022 і на початку 2023 року ми вже працювали над системами візуальної навігації, розпізнавання і автоматичного наведення. Технологія була. Люди були. Можна було робити реальні речі для армії.

А потім почалася не інженерія, а українська система.

Після спілкування з генералітетом у мене склалося дуже просте враження: якщо конкретна людина не бачить особистої вигоди, їй часто байдуже, наскільки корисна технологія для країни. Серед військових теж вистачало реакції в стилі: а що з цього буде нам. Ті, хто реально підтримував, були, але їх було недостатньо.

Потім пішли погрози, спроби забрати напрацювання і речі, після яких питання технологій уже відійшло на другий план.

І все це в країні, де був колосальний запас інженерного досвіду. Люди, які працювали з радіолокацією, ракетною технікою, авіацією, космосом, складними системами керування. Фахівці, знання яких під час війни мали б збирати по країні вручну і давати їм усе необхідне для роботи.

Замість цього багато хто доживав своє життя нікому не потрібним.

Я знаю розробників, які після 2022 року приходили з командами, прототипами, досвідом і готовністю працювати. І дуже часто вони розповідали одну й ту саму історію. Їх зупиняла не фізика, не математика і не відсутність технологій. Їх зупиняли кабінети.

Мене найбільше бісить саме це.

Україна десятиліттями була країною сильних програмістів та інженерів. Ми робили складний софт для світових компаній, ракети, авіацію, радари, космічну техніку. Потенціал є.

Але потенціал нічого не вартий, коли рішення приймають не спеціалісти, а люди, для яких головне посада, контроль і власна вигода.

Можна скільки завгодно говорити про технологічний прорив. Але поки наверху сидять люди, яким важливіше від'їсти собі сраку, ніж дати працювати тим, хто реально щось уміє, країна з колін не підніметься.

Мораль проста. Найважчий legacy в Україні написаний не на C++ і не на COBOL. Він сидить у кабінетах і вперто не хоче рефакторитись.

#спогадирозробника

Есть компании, где покупку сервиса за $500 нужно обосновать через ROI.

Но правило, которое ежедневно бесит 5000 сотрудников, может существовать десять лет просто потому, что "у нас так принято".

Опоздание на две минуты. Зеленый Slack. Обязательные часы в офисе. Бессмысленные митинги. Timesheets с точностью до 15 минут.

Самое интересное, что многие из этих правил можно посчитать.

И внезапно оказывается, что компания может экономить десятки тысяч долларов на "дисциплине", одновременно теряя сотни тысяч или миллионы на продуктивности, увольнениях, потере доверия и репутационных рисках.

Я попробовал представить корпоративный микроменеджмент как обычную математическую задачу.

Получился Corporate Bullshit Ratio.

И некоторые правила этот тест явно не проходят.

https://www.linkedin.com/pulse/%D0%BA%D0%B0%D0%BA-%D0%BD%D0%B5%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BD%D0%BE-%D1%83%D0%B3%D1%80%D0%BE%D0%B1%D0%B8%D1%82%D1%8C-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8E-andrii-nikishaiev-ua-fergf

Стоимость - это тоже non-functional requirement.

Мы привыкли проектировать системы вокруг привычных SLO:

Availability: 99.95%
P99 latency: 200 ms
Throughput: 10k RPS

Но рядом почти никогда нет еще одной строки:

Cost: $0.00012/request

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

Почти каждое улучшение надежности имеет цену.

Reliability растет.
Latency снижается.
Capacity reserve увеличивается.

И вместе с этим обычно растет cost.

Можно держать огромный запас мощности, replicas базы в нескольких AZ, дорогой storage, кэшировать все подряд и писать гигантские объемы telemetry. Система будет надежной.

Но правильный вопрос архитектора - не "можем ли мы сделать еще надежнее?", а "сколько дополнительной надежности мы покупаем за каждый дополнительный доллар?"

Overprovisioning дает запас, но сжигает compute. Autoscaling экономит деньги, но может плохо переживать резкие пики. Karpenter помогает эффективнее использовать Kubernetes capacity. Reserved capacity выгодна для стабильной нагрузки. Spot сильно снижает цену, если workload умеет переживать eviction.

То же самое с данными. Read replica снижает latency, но увеличивает постоянную стоимость. Queue сглаживает пики и позволяет уменьшить compute. Cache убирает дорогие DB calls, но добавляет стоимость и consistency complexity.

Есть и расходы, которые легко не заметить.

Cross-AZ traffic. Логи, которые никто не читает. High-cardinality metrics. Traces для каждого запроса. Данные, годами лежащие в дорогом storage tier.

А теперь к этому добавились AI workloads.

Здесь архитектурной метрикой становится не только cost per request, но и cost per inference, cost per token, cost per customer, cost per transaction. Выбор модели, размер context window, prompt caching и количество agent iterations становятся такими же архитектурными решениями, как выбор базы данных.

Поэтому мне близка эволюция FinOps от идеи "сократить счет AWS" к unit economics и business value. Cloud bill сам по себе почти ничего не говорит. Если инфраструктура стоит миллион и приносит сто миллионов - это одна архитектура. Если она стоит миллион и обслуживает продукт с выручкой в полтора - совсем другая.

Поэтому в architecture review я бы добавил обязательный вопрос:

"Сколько стоит одна полезная единица работы этой системы?"

Когда инженер проектирует не только latency и availability, но и unit economics, архитектура начинает напрямую влиять на P&L.

#заметкиархитектора

В истории S3 есть момент, который архитекторы иногда пересказывают как "AWS придумала новый consensus algorithm". Я бы формулировал точнее: AWS не раскрывала публично новый алгоритм уровня Raft или Paxos, но в 2020 S3 получил strong read-after-write consistency для GET, PUT и LIST без заявленного ухудшения performance и без глобальной координации. И вот инженерно это намного интереснее самого названия алгоритма. ([Amazon Web Services, Inc.][1])

Представим наивную distributed storage. Есть 3 replica, запись подтверждаем после W=2, чтение делаем с R=2. Тогда:

W + R > N
2 + 2 > 3

Кворумы обязательно пересекаются хотя бы в одной replica, поэтому можно определить актуальную версию. Но за consistency платим coordination latency: если RTT до replica 1, 3 и 12 мс, запись зависит уже не от быстрейшей машины, а минимум от второй успевшей подтвердить.

На масштабе S3 проблема становится жестче. Нельзя просто посадить миллиарды ключей на один consensus group - leader превратится в bottleneck. Значит, coordination domain надо дробить, маршрутизацию делать локальной, а metadata и версии объектов обновлять так, чтобы независимые ключи практически не мешали друг другу.

Именно здесь архитектура выигрывает у "более быстрого алгоритма". Если миллион независимых ключей распределить между 10000 coordination groups, средняя область конкуренции уменьшается примерно:

1 000 000 / 10 000 = 100 ключей на group.

Теперь consensus остается локальным, а throughput масштабируется горизонтально.

В итоге S3 получил сильную консистентность при сохранении региональной изоляции, а приложениям больше не понадобились отдельные слои вроде S3Guard только ради согласованного представления данных. Позже conditional writes позволили еще и переносить optimistic concurrency control непосредственно в S3 вместо внешних lock-сервисов. ([Amazon Web Services, Inc.][1])

Для меня это хороший пример зрелой distributed architecture: настоящий прорыв часто не в том, чтобы придумать "Raft быстрее Raft", а в том, чтобы уменьшить область, внутри которой consensus вообще необходим.

[1]: https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/?utm_source=chatgpt.com "Amazon S3 Update – Strong Read-After-Write Consistency | AWS News Blog"

#заметкиархитектора #история

Security начинается не с pentest и не с security review перед релизом. Она начинается еще до первой строки business logic.

Identity, Authorization, Service boundary, Data boundary, Audit, Observability. Если эти границы не определены архитектурой, security-команда потом будет бесконечно латать последствия. Особенно это заметно сейчас, когда в инфраструктуре появляются AI agents.

Представим простую задачу: агенту говорят "fix production" и выдают AWS credentials.

Для человека это уже слишком широкие права. Для AI-агента ситуация еще опаснее. Он может интерпретировать контекст неправильно, выполнить неожиданную последовательность действий или попасть под prompt injection через данные, которые сам же читает.

Поэтому агенту нельзя выдавать "доступ в AWS". Ему нужно выдавать конкретные capabilities. Например: прочитать логи одного сервиса, перезапустить deployment, изменить один параметр autoscaling. На ограниченное время. С полным audit trail.

Именно здесь важны ephemeral credentials, workload identity и least privilege. Долгоживущие secrets постепенно должны исчезать из архитектуры. Сервис получает identity среды, а права выдаются конкретному workload. AI agent получает временные credentials только на необходимую операцию.

Но IAM - лишь один слой.

Service boundary определяет, кто вообще может обращаться к компоненту. Data boundary - какие данные он имеет право видеть. Network policies ограничивают маршруты. Audit позволяет восстановить цепочку действий. Observability должна показывать не только ошибки, но и необычные security-sensitive операции.

Есть еще software supply chain. Можно идеально настроить IAM и проиграть атаку через dependency. Поэтому SBOM, проверка provenance, подпись artifacts, scanning dependencies и контроль build pipeline становятся частью архитектуры, а не набором дополнительных security tools.

И здесь снова появляется AI. Если агент способен устанавливать package, менять pipeline, создавать cloud resources или выполнять shell commands, его tool permissions фактически становятся новой системой авторизации.

Prompt injection в таком мире - это уже не проблема чат-бота. Это потенциальный путь к инфраструктуре. Поэтому главный вопрос при проектировании AI-enabled системы для меня звучит не "что агент умеет делать?" А "какой минимальный набор действий ему действительно необходимо разрешить?"

Security зрелой системы определяется не количеством security-продуктов. Она определяется тем, насколько сложно одному ошибочному действию превратиться в компрометацию всей системы. Именно поэтому cloud security, secure architecture и AI security сегодня начинают сходиться в одну дисциплину.

Это уже не задача отдельной security-команды. Это ответственность архитектуры.

#заметкиархитектора