Continuous Architecture in Practice — выпуск 2

Один из ведущих напоминает рамку книги: первые две главы задали принципы и процессы вокруг архитектурной работы, а всё остальное — тулбокс, где каждая глава устроена как обзор направления со списком литературы в конце и отсылкой к принципу, из которого следует выбор. Драйверов внимания к данным авторы называют три: взрыв новых технологий хранения, спровоцированный интернет-компаниями; возможность вытаскивать из данных знания для стратегических решений; фокус бизнеса на управлении по данным — в примерах высокомаржинальные отрасли вроде фармацевтики и финансов. Ведущий честно говорит, что глава страниц на тридцать пытается вместить все известные технологии и работает скорее как разводящая страница к следующему списку книг: Клеппман сам называл свою книгу кратким обзором с большой библиографией, а здесь обзор обзора за полчаса. Другой участник добавляет, что драйверы будто вынуты из контекста — мир 24/7, много разных баз, бизнес хочет стать data-driven, — а откуда они выросли, авторы обещают рассказать дальше по слайдам.

Дальше в главе треугольник: биты на диске превращаются в информацию, информация — в знание, то есть ответы на вопросы, а вершина — мудрость, связи и ответ на «почему», например понимание клиентов ради лучшего продукта. Перестройку мышления авторы показывают банковским примером — переходом от account-centric к клиентской модели, — а один из ведущих вспоминает, как в Нижнем Новгороде счёт обслуживало конкретное отделение и ехать приходилось в определённую часть города в зависимости от берега реки. Тут же DDD и ubiquitous language: авторы советуют Эванса и Вернона, участники — книгу с обезьянкой на обложке, написанную Владом Хононовым и разобранную в клубе; заодно в тексте находят ошибку, где сабдомены названы bounded context, хотя такой иерархии в DDD нет. Историю хранилищ ведущий пересказывает сам: реляционные базы, веб-масштаб, гарантии послабее ради скорости, старая Amazon Dynamo, файловая система Google, а термин NoSQL, по его словам, остался от митапа примерно 2009 года.

Полезнее общего обзора оказывается список дополнительных тем: владение данными и метаданными, интеграция, эволюция схем. Владение авторы закрепляют за сервисом или доменом, который становится единой точкой истины, остальные ссылаются на него по идентификаторам — и это постоянный дополнительный трафик, который надо балансировать; в сквозном примере с приложением для аккредитивов неизменяемые данные просто кэшируют на нужном сервисе. Одному из участников нравится, что ownership делят на запись и чтение, на продюсера и консьюмера, а поскольку у каждого компонента в примере своя база, владение разбирается почти автоматически. Эволюция схем охватывает и данные внутри сервисов, и данные между ними, и сводится к версионированию API и обмену спеками. Главу закрывают быстро, отметив, что интеграции — REST, GraphQL, gRPC — в главе о данных выглядят неожиданно, а разговор про схемы клуб уже вёл у Клеппмана пару лет назад.

Безопасность ведёт гость, и мысль, за которую он ставит книге лайк, звучит так: безопасность — свойство софта, возникающее ровно там, куда вложили усилия, а вложенные усилия не потрачены на другое — растут косты, защитные фичи бьют по доступности и производительности. Триаду «конфиденциальность, целостность, доступность» книга приводит, но зацикливаться на ней не стоит: современная безопасность идёт от рисков. Вложиться в защиту — значит не вложиться в фичи, и участники вспоминают похожий тезис из книги Google про SRE: в надёжность можно вложить столько времени, что система станет ригидной. Больше всего гость спорит с shift left. Это лозунг: сдвигать влево, находясь в нуле, нельзя, начинать надо справа — с пентестов, аудитов и опыта починки архитектурных дыр по три месяца и по полгода, после которого цену все понимают и готовы платить. Иначе выходит «раньше тратили ноль, теперь рубль — дорого, давайте 50 копеек». Ломают же там, где вложено меньше всего: можно подключить кучу продуктов для анализа, а зайдут через роутер, присланный по почте, или через сотрудника.

К моделированию угроз у гостя два вопроса. Ответственность: авторы будто предполагают, что этим занимается само ИТ, а он не знает компании, где разработчики строят модель сами и хорошо; делать внутри ИТ можно, но результат обязан кто-то верифицировать — иначе получается как в книге, где на класс угроз выписали пару штук, а первая ссылка в поиске даёт десять. Методология: STRIDE он не любит, потому что начинать нужно с критичности актива — угрозы у платёжного провайдера и у лендинга разные, а для незначимой системы риски можно расписать по минимуму, но обязательно зафиксировать, ведь систем сотни и тысячи и после себя важно оставить правильные артефакты и повторяемый чек-лист. Матрицу «вероятность на импакт» участники предлагают упростить и идти от правого верхнего угла, напоминая, что риск можно не только митигировать, но и избежать или принять: это базовый продуктовый менеджмент.

В практической части правок больше всего. Разговор с разработчиком про криптографию, считает гость, начинается не с симметричных и асимметричных схем, а с «не пиши свои крипто-примитивы»: есть TLS и готовые библиотеки, а своя крипта считается рабочей только после проверки редким специалистом. Один из ведущих возражает, что книга скорее про выбор, чем про реализацию, и участники сходятся: такие решения должны быть зашиты в библиотеки или в платформу. Дальше — бэкапы, до которых не дотянется злоумышленник, вроде хранилища с запретом на перезапись; ротация секретов, сокращающая жизнь скомпрометированного секрета до минут; и фишинг: код из SMS можно ввести на любом фальшивом сайте, а факторы, которые сами проверяют Origin, снимают вопрос обученности человека. Zero trust гость называет простой философией — не доверять соседней системе, смотреть на контекст, ставить бастионы, — а в книге видит воду. Понравился ему и термин «театр безопасности» — когда риски переоценивают и защищаются от всего на свете. Через неделю клуб берёт главы про масштабирование и производительность.