Статья от Uber про их автоматизацию api процессов на базе thrift idl спеки https://eng.uber.com/architecture-api-gateway/ примечательна статья огромным объёмом работ, который в этот проект Uber вложил. Но ещё больше впечатляет их следующая статья о том, как они этот швейцарский нож улучшали, чтобы он не тормозил всю разработку https://eng.uber.com/scaling-api-gateway/

Чеклист CI/CD практик, вдохновленный книгой "DevOps: A Software Architect's Perspective"(https://www.amazon.com/DevOps-Software-Architects-Perspective-Engineering/dp/0134049845)

- Могут ли члены команды работать над разными версиями системы одновременно?
- Легко ли протестировать код других членов команды?
- Легко ли интегрировать код разных членов команды?
- Легко ли интегрировать код разных команд и собрать его в единую систему?
- Можно ли задеплоить систему в различных вариантах окружения?
- Может ли протестировать версию системы без влияния на продакшн?
- Есть ли возможность более пристально мониторить свеже задеплоенную систему?
- Доступны ли более старые версии кода после деплоя в продакшн?
- Можно ли откатиться в случае проблемы?
- Есть ли возможность поэтапного включения фичи в продакшне?
- Могут ли разные версии системы работать бок о бок, возможен ли поэтапный апгрейд?

А тем временем, инженеры Facebook сражаются с ошибками PCIe на своих немаленьких кластерах. Аккуратная гуманная статья с поправкой на то, что гиганты не могут жить на простых средствах (в том числе мониторинга) и часть стека переписывают сами. Статья понравилась детальностью, не хватало только их эвристик по фатальности алертов https://engineering.fb.com/2021/06/02/data-center-engineering/how-facebook-deals-with-pcie-faults-to-keep-our-data-centers-running-reliably/

В книге George Fairbanks "Just enough software architecture" вводится понятие предполагаемая/дефолтная архитектура ("presumptive architecture") - архитектурное решение для данного домена, которое сразу приходит в голову "по умолчанию". Дефолтная архитектура отличается от reference architecture, которую разрабатывают производители платформ: последняя может станет дефолтной архитектурой в домене, но без гарантий. Зацепила фраза Fairbanks'а: "The term presumptive architecture is introduced in this book because it would be a mistake to ignore these 800-pound gorillas and instead believe that all developers with start with first principles in their software architecture." Очень здравый подход. Куча книг по архитектуре утверждают: семь раз задизайнь, один раз напиши. А Fairbanks честно говорит "Ну, не всегда так и часто не так". И все же сразу хочется предостеречь с одним возможным ложным выводом о ненужности архитектурных знаний при наличии знания домена: начать не значит закончить. Да, начав строить очередной микросервис, у каждого, кто уже их строил, есть в голове некоторый стек, на базе которого он собирается это провернуть. Но как часто по мере развития системы требуется "креативность" и в архитектуре тоже. И без знаний принципов как это менять, развитие будет идти дорого, методом проб и ошибок.

https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104

На Хабре вышла статья моего бывшего коллеги Кости Кардаманова об архитектурной секции интервью в Яндексе https://habr.com/ru/company/yandex/blog/564132/

Сразу вспомнилась коллекция материалов для прохождения интервью на архитектурные позиции в гугле/fb https://github.com/donnemartin/system-design-primer . Оба ресурса использовать как способ подсветить свои слабые места. И, конечно, это не enterprise архитектура, в МТС на архитекторы спрашивают другие фреймворки.

Из серии "как оно на самом деле" - переход на канареечные релизы может быть не таким простым. Статья от инженеров Etsy про тру архитектуру https://codeascraft.com/2021/06/15/improving-the-deployment-experience-of-a-ten-year-old-application/

Конспект доклада как вид искусства :) via @ErBlack

Чек-лист проектирования от Максима Цепкова с TechLeadConf

Чек-лист проектирования от Максима Цепкова ([https://t.me/mtsepkov](https://t.me/mtsepkov)). Чек-лист достаточно краткий, но может стать оправной точкой для reference архитектуры при проектировании системы интернет-магазина со складами\доставкой и всякими прелестями отмены\задержки заказов.

- Как масштабируется каждый из сервисов под нагрузкой?
- Используется общая БД или отдельные?
- Где в БД возникают блокировки обработки запросов пользователей?
- Как взаимодействуют сервисы, где и какие очереди?
- Что происходит с записями в очереди, когда экземпляры сервисов и ноды падают?
- Как обеспечивается устойчивость при падении экземпляров сервисов?
- Как обеспечивается устойчивость при падении нод и дата-центров?
- Как обеспечивается работа, когда пользователь в "Сапсане" или в другом месте с плохой связью, соединение рвется, и он переоткрывает страницу?
- Какой мусор остается, если пользователь ушел, и как его чистят?

По заметкам APIEvangelist открыла для себя новую интересную тулзовину https://www.akitasoftware.com - она прослушивает траффик и строит модель АПИ. Настоящую модель, которую используют, а не ту, что описана в swagger(aka OpenAPI). Пока не поддерживают gRPC и GraphQL, но собираются (не факт, что нужно - все же там больше принята кодогенерация). Тулзовина ценна тем, что (1) позволяет легко отлавливать изменения поведения АПИ, (2) позволяет восстановить АПИ при отсутствии спек. Тулзовина не нужна там, где (1) практикуют строгий API-first, (2) большая разница между публичным и приватным АПИ. Жаль, что сейчас нет проекта, над которым можно поиграться. Но вдруг у вас есть и расскажите свои впечатления?

У hexlet есть чеклист инженерных практик (или скорее CI/CD практик). Тоже неполный, но поможет вашему проекту оценить свою степень зрелости. А вам понять, если вдруг у вас где-то не хватает воображения, чтобы пожелать еще более прекрасных процессов. Что бы вы еще в этот список добавили?