В блоге Мартина Фаулера вышла длинная статья о трудностях обновлений legacy систем. Статья не слишком техническая, вероятно потому, что авторы не слишком юны и не слишком верят в технологические сложности. Моя сверх-короткая выжимка из статьи включает всего 2 пункта: (1) обновлять нужно не только софт, но и процессы и структуру, (2) цели реновации должны быть понятны бизнесу и четко прописаны. Кроме того, в статье несколько забавных примеров, жизненное описание ошибок и какое-то количество весьма скучного капитанского здравомыслия. https://martinfowler.com/articles/patterns-legacy-displacement/

У SEI вышел детальненкий план по тому, как проектировать/выбирать ДЦ для smb https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=736043

Иногда кажется, что чистые красивые схемы - это удел лишь небольших проектов да прототипов. Наша задача как архитекторов не переусложнять и знать схемы, ведь большинство проектов невелики. Ну и изобретать гибриды, когда красивые схемы перестают работать. Пример тому - гибридный подход Twitter-а к доставке твитов. От схемы с реляционной БД к схеме с доставкой в почтовые ящики и от нее к гибриду, когда для разных пользователей схема отличается. Пример базируется на описании из книги с кабаном (Designing Data-Intensive Applications https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/ ). Книга, кстати, на редкость дельная (огооонь!). Если у вас совсем нет времени на чтение и вы читаете одну книгу в год, то, кажется, это правильный выбор.

Статья о дизайне API из Slack - не то, чтобы принципиально новое, но внятное описание естественных практик. Почерпнула для себя, что Slack сразу думает об ограничении коллекции (по числу сущностей или через пагинацию/страничное разбиение). Мысль верная: добавление ограничений не ломает обратную совместимость, но старые клиенты продолжат делать объемные запросы. https://slack.engineering/how-we-design-our-apis-at-slack/

Начала набрасывать структуру курса по reference architecture. Курс ориентирован на тех, кто уже знает различные quality attribute-ы и как их прокачать для нужного решения, понимает QAS и знает общие архитектурные принципы. Задача курса - познакомить с типичными решениями\фреймворками разных доменов. Добавить мяса, что ли. Я буду очень признательна вашим комментариями, замечаниям - что бы вы считали нужным в курс добавить, что убрать. Делюсь ссылокой и буду рада любым комментариям https://docs.google.com/document/d/18aIGLTMRUZuBGBpO9uvGtyXISBXCrAeFO0R4AUELqiU/edit?usp=sharing

Facebook опубликовал CacheLib и CacheBench.https://engineering.fb.com/2021/09/02/open-source/cachelib/ Не смотрела еще имплементацию, но читала статью от Carnegie-Mellon и впечатлило. https://www.usenix.org/system/files/osdi20-berg.pdf то есть прям грамотный современный in-app кэшинг в опен-сорсе. С учетом и thread-safe, и nvm, и работы с оом-ом, и куча-куча мелких инженерных фишечек, которые говорят о выстраданности решения и его зрелости. А какие системы для кэшей используете вы в своем проекте?

Аккуратная структурированная статья о dual write проблеме. https://developers.redhat.com/articles/2021/09/21/distributed-transaction-patterns-microservices-compared .Кажется, вопрос о dual writes может стать пробным камнем для тех, кто на общем собрании поднял вопрос, а не перейти ли нам на микросервисы. Если в команде хватает экспертизы/задора, то можно попробовать. А иначе даже не стоит начинать.

простая статья, которая подсветила область "я не знаю чего не знаю". Какой дефолтный ответ сразу всплывает при запросе "нужно реализовать API throttling"? У меня автоматом всплыл ответ - 429 на каждый второй например запрос и пусть клиент разбирается. Однако, товарищ рассматривает еще два способа - fallback на другое API и перейти на delayed execution (по сути асинхронная схема с 202 возвратом). https://dzone.com/articles/api-throttling-strategies

Большая подборка по подготовке к system design interview, aka входной набор знаний для синьор/архитектора https://blog.pragmaticengineer.com/preparing-for-the-systems-design-and-coding-interviews/ Читая этот список, открыла для себя пару новых ресурсов и взгрустнула на тему применимости. Так много знания, аппетитного для мозга, но времени не так много и в продакшене лишь 20% задач интересны и требуют того самого мозга, что эти книги тренируют. Спасибо Александру Бриллиантову за ссыль

подборочка сертификатоа для архитекторов https://medium.com/@nvashanin/certificates-in-software-architecture-6b18e0102fe7 из всего списка заинтересовал лишь RedHat architect и то из-за нежной любви к инженерным статьям RedHat-а. Есть ли у вас что-то сверх списка? И есть ли какие-то российские сертификаты на тему?

вот уж удивительно не знать своих героев. К стыду своему, не знала что Single Responsibility Principle ввел не кто-нибудь, а Robert Martin, чью книгу Clean Architecture я так недолюбливаю. Возможно, настала пора пересмотреть свои взгляды и перечитать книгу. А вот и оригинальная заметка в блоге Uncle Bob-а про SRP https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Open-source утилита для построения DAG диаграм по трейсам Jaeger (трейсинга распределенных систем) и нахождения критического пути. И, главное, вот уверена, что не только uber такое делает, что слишком распространенная задача, но взять на себя расходы и опубликовать в паблик код - крутое начинание. Для всех, кому важен перформанс его распределенной/микросервисной системы. https://eng.uber.com/crisp-critical-path-analysis-for-microservice-architectures/

Обширная коллекция API Guideline-ов для вдохновения при написании своего собственногго гайда http://apistylebook.com/design/guidelines/

Разбор unavailability инцидента в github. Поучительно и всего 4 минуты на чтение. https://github.blog/2021-12-01-github-availability-report-november-2021/

коротенькая статья о простом (но и dummy) тестировании производительности сервиса. Правда, не могу придумать реальных случаев, когда такой подход востребован. Серьезные системы имеют и стресс-тесты и прикрученные графаны, которые и mean померяют, и персентили нарисуют. А простым системам производительность и масштабируемость не важна. Но поделюсь все же ссылкой - вдруг пригодится https://developers.redhat.com/articles/2021/12/16/elegant-way-performance-test-microservices-kubernetes

Архитектурное пожелание на наступающий год. Желаю нам с вами, чтобы все наши прекрасно проработанные планы и спеки реализовывались в полной мере. Чтобы мы чаще искали лучших из хороших решений, нежели приемлемых из плохих. Чтобы budget-owner-ы отзывались на наши инциативы и меньше сомневались в наших рассчетах. И тогда все больше было бы в мире хорошо сделанных, качественных продуктов и сервисов.

На хабре опубликовала статью по выявлению и оценке технического долга. Статья (а точнее доклад) появился как ответ на вопрос «что делать, когда техдолг снижает скорость разработки, все на что-то жалуются, а с чего начать неясно?» https://habr.com/ru/company/oleg-bunin/blog/645349/

Статья о том, как Netflix перформанс тесты в ci встроили. https://netflixtechblog.com/fixing-performance-regressions-before-they-happen-eab2602b86fe что интересно: они отказались от статических величин threshold-ов для тестов и стали смотреть на аномалии и changepoint-ы. Про аномалии-то понятно, а changepoint стал чем-то новым для меня. Ну и будоражат истории о том, как ci из красного стал зеленым.

Серия статей Tinder от 2019ого года о том, как они делали geo-shard. https://medium.com/tinder-engineering/geosharded-recommendations-part-1-sharding-approach-d5d54e0ec77a https://medium.com/tinder-engineering/geosharded-recommendations-part-2-architecture-3396a8a7efb https://medium.com/tinder-engineering/geosharded-recommendations-part-3-consistency-2d2cb2f0594b

Четкое и ясное описание replicated log на базе Raft для синхронизации состояния в распределенной системе. Кажется, это первый раз когда до меня на самом деле дошло, как оно внутри устроено со всеми corner cases (до этого довольствовалась описанием концепта, но на кончиках пальцев понимания деталей не хватало). https://martinfowler.com/articles/patterns-of-distributed-systems/replicated-log.html Но это еще не все - этот паттерн лишь часть коллекции Distrubuted systems patterns, которые Unmesh Joshi публикует в блоге Фаулера https://martinfowler.com/articles/patterns-of-distributed-systems/ Кстати, мог бы быть неплохой вопрос на собеседовании - рассказать базовый алгоритм, а дальше предложить кандидату фантазировать о всех corner case в условиях что любой из серверов любое количество времени может быть unavailable. Не нужно чтобы ответил все, но вопрос насколько богато воображение.