Cassandra: The Definitive Guide, 3rd edition - Part II (Рубрика #Architecture)

В этом посте я продолжаю рассказ об интересной книге по Cassandra (начало в предыдущем посте) и говорю только про шестую главу "The Cassandra Architecture"
Эта глава начинается с определения архитектуры

Architecture—fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
—ISO/IEC/IEEE 42010

И дальше начинается интересное

1) Про топологию развертывания кластера, а точнее про датацентры и стойки (racks). Это важно для понимания того, а как обеспечивается отказоустойчивость - для этого в Cassandra есть сплетни (gossip protocols) и детекция сбоев (phi accrual failure detector). И про то и про другое прикольно рассказано в книге "Database Internals", которую мы обсуждали в "CoA" (выпуски раз и два).

2) Про механизм consistent hashing с токенами, кольцом и виртуальными нодами (насайте DataStax есть отличное описание и визуализация). Про то, как работает partitioner, который раскидывает наши партиции по нодам кластера и про стратегии репликации. Дальше наступает время обсудить consistency level и tunable consistency кассандры, которую мы можем выставлять на каждый запрос.

3) Про координацию запроса координирующей нодой, которая от имени клиента взаимодействует с репликами, чтобы обеспечить запрошенный уровень консистентности. Тут появляется такая штука как hinted handoff для write запросов, когда координирующей ноде не удалось записать данные, но она оставила себе напоминание, что надо надо услышав сплетню о возвращении реплики в строй отправить туда write запрос. Тут же появляются темы как бороться с энтропией (anty-entropy) и чинить реплицированные данные (подход Cassandra основан на подходе Amazon Dynamo, про который можно почитать в whitepaper от 2007 года). Тут и пригождается знание алгоритмов и структур данных, например дерева хешей или дерева Меркла (Merkle trees).

4) Про транзакции, точнее lightweight transactions (LWT) и протокол Paxos для достижения консенсуса. Собственно LWT нужно для достижения линеаризуемости, о которой речь шла в знаменитой CAP теореме (подробнее в прошлых постах: Про CAP теорему и Про формализацию CAP теоремы и ее доказательство). Автор объясняет, что чтение с кворума и запись в кворум, которые гарантируют strong consistency, не позволяют предотвратить состояние гонки (race conditions) в случаях, когда клиентам сначала надо прочитать, а потом записать данные. Именно для этого и появляется LWT, который базируется на Paxos (про который надо рассказывать отдельно). Но надо отметить, что

Cassandra’s lightweight transactions are limited to a single partition.

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

5) Про внутренее устройство движка хранения данных, где у нас есть Memtables, SSTables, and Commit Logs. Это работает так, что запросы на запись мы пишем в commit log и делаем это durable, а дальше записываем данные в in-memory структуру memtable, где каждая memtable содержит данные для специфичной таблицы Cassandra. Дальше при достижении определенного предела memtable записывается на диск (это уже называется sstable - sorted strings table или отсортированная таблица строк). Таких SSTable на диске много и Cassandra периодически их компактит, производя mergesort (опять тут пригодятся алгоритма для понимания).

Дальше интересно обсудить чтение данных, где нам помогают вероятностные структуры данных, а точнее фильтры Блума (Bloom filters). Они позволяют понять, а есть ли искомая запись внутри конкретной SSTable без full scan. Кроме того используются стратегии кеширования для производительности. Плюс удаление записей с append-only структурой хранения выглядит интересно - мы не можем просто удалить запись, так как надо сохранить tombstone о том, что она удалена. Если мы это не сделаем, то при compaction наши удаленные записи оживут ... и не в виде зомби, а полноценными записями:)

Финал обзора в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign

Сложность и модулярность две стороны одной медали - Влад Хононов - ArchDays 2023 - Part 1 (Рубрика #Architecture)

Интересное выступление Влада Хононова с конференции по архитектуре, в программный комитет которой я состою. В этом выступлении Влад рассказал кратко связь complexity и modularity, которые позволяют ввести интересные метрики качества систем и кода, которые упрощают coupling/connascence/cohesion. Этот доклад основан на материале книги "Balancing Coupling in Software Design", которую я закажу в бумаге сразу после ее издания

Ну а теперь пройдемся по основным мыслям доклада
- Влад определяет систему как набор взаимосвязанных элементов, организованных для достижения цели (это основано на определении Медоуз из книги "Азбука системного мышления", про которую я уже рассказывал)
- Дальше автор идет вглубь уровней абстракций и показывает, что система - это фрактальная история вида: системы -> микросервисы -> неймспейсы -> классы -> методы -> ...
- Возникает вопрос, а в чем разница между компонентами системы и модулем? И автор показывает, что различие не в физических или логических границах. Автор обращается к классическим определением модулей (self-contained, вызывается другими элментами, может быть скомпилированными отдельно). И дальше автор говорит, что у компонентов и модулей отличие в целях - деление на компоненты решает текущую задачу системы, а деление на модули помогает решить будущую задачу, когда система будет эволюционировать.
- Потом автор рассказывает про определение сложности от автора фреймворка Cynefin, где сложность зависит от простоты установления связи между причиной и эффектом. Условно, если мы можем предсказать последствия своих действий в системе, то это простая система. А вот если нам нужны эксперименты для определения взаимосвязи, то комплексная система
- В проектировании софта сложность может быть локальной и глобальной (условно сложность внутри модуля или сложность взаимосвязей между модулями). Понятно, что локальность/глобальность сложности зависит от точки
- В итоге, модульность и сложность - многоуровневые явления, которые можно наблюдать на разных уровнях абстракций.
- Дальше автор показывает метрики сложности, которые приводил uncle Bob в своей книге "Clean Architecture". Кстати, я уже делал краткое саммари ее части про дизайн модулей здесь. Влад в выступлении показывает как можно хачить метрики abstractness, stability, distance from main sequence. Хотя при желании можно похачить любые метрики, а значит и метрики самого Влада, которые он предлагает дальше:)
- Влад предлагает метод оценки через модель интеграции, которая основана на оценке взаимосвязи между элементами системы. Эта модель объединяет coupling/connascence/cohesion. Суть в том, что нам надо оценить интенсивность обмена между модуля по этим связям
- Модель включает четыре уровня, которые идут от самых терминальных случаев к оптимальным (по мере этого уменьшается объем общих знаний между модулями)
1) Intrusive coupling - интеграция через вторжение, когда нарушаются границы инкапсуляции и зависимый модуль получает доступ к внутренней реализации другого модуля. Примеры: взаимодействие через базу данных, использование reflection для доступа к приватным свойствам.
2) Functional coupling - взаимосвязь через функцию или бизнес-требования. Интересно, что тут не обязательно наличие связи в коде.
3) Model coupling - связь через общую модель бизнес домена, структуру данных. Здесь нам дальше сложно эволюционировать общую модель
4) Contract coupling - связь через контракты (API). В DDD для этого есть способы вида published language, anti-corruption layer, etc

Про то, как использовать эту модель я расскаал в продолжении поста, плюс рекомендую другую книгу Влада "Learning DDD" ("Изучаем DDD – предметно-ориентированное проектирование"), про которую я много рассказывал раньше.

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes #Management

Сложность и модулярность две стороны одной медали - Влад Хононов - ArchDays 2023 - Part 2 (Рубрика #Architecture)

Продолжая пост про доклад Влада Хононова на ArchDays 2023, я расскажу про использование модели интеграции для оценки качества архитектуры.
Для оценка Влад предлагает использовать 2 параметра: расстояние между взаимодействующими компонентами и уровень этого взаимодействия (intrusive coupling, functional coupling, model coupling, contract coupling). Получается у нас связь между стоимостью изменения и расстоянием между компонентами, что затрагивают эти изменения. Для того, чтобы отобразить доступные варианты Влад предлагает использовать стандартный подход консультантов с матрицей 2 на 2, где осями являются дистанция и сила связи. В итоге, у нас получается 4 варианта (2 первых предпочтительных и последние 2, которых стоит избегать)
- High distance, low strength - это стандартное loose coupling, когда компоненты далеко друг от друга и они полльзуются contract coupling
- Low distance, high strength - это стандартный high cohesion, когда компоненты рядом и связь между ними сильна
- Low distance, low strength - это локальная сложность, когда у нас в близлежащих компонентах нет связи и при изменениях нам надо пытаться вспомнить, а почему эти компоненты вообще расположены вместе:)
- High distance, high strength - а это стандартная история с глобальной сложностью, когда изменения в вроде бы несвязанных далеких компонентах приводят к спецэффектам наавроде взрыва на макаронной фабрике
Я приложил картинку с визуализацией этой матрицы 2x2.

В итоге, главным уравнением в этом подходе является

Modularity = Strength Xor Distance

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

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes #Management

Музыка от SUSE (Рубрика #Humor)

У компании SUSE есть отличная музыкальная группа, которая делает крутые it версии популярных песен:) Самое то для пятницы - послушать забавную музыку и отдохнуть после сложной недели, которая получилась сложной и для многих моих коллег, но все справились на отлично. А теперь подборка от SUSE:
- Linus Said
- KUBERNETES
- SUSE. Yes Please.
- Every Byte You Take
- Paint it Green
- Remember When
- Can't Stop the SUSE
- We Didn't Start the Kernel
- Uptime Funk
- Coding
- SUSECON
- Open and Wild
- Where Open Source Grows
- Open Source My Way
- The Time Has Come

Возможно, я что-то пропустил, но если вам музыка понравилась, то вы сможете сами найти другие клипы на Youtube.

#Humor #Music

Cassandra: The Definitive Guide, 3rd edition - Part III (Рубрика #Architecture)

Этим постом я заканчиваю рассказывать о книге про Cassandra (предыдущие посты: 1 и 2).

7. Designing Applications with Cassandra - авторы разбирают дизайн приложения для букинга отелей и выбирают микросервисный подход из-за обеспечения инкапсуляции логики внутри сервисов, наличия автономности для деплоя сервисов, а также независимого масштабирования при необходимости. Для проектирования авторы предлагают итеративно работать над UX design, data modeling, architecture. С точки зрения проектирования авторы начинают с идентификации bounded context, идентификации сервисов, дизайна persistence для микросервисов. Причем авторы ратуют за polglot persistence, где мы можем выбирать разные базы для разных сценариев (RDBMS, Document-oriented, Wide-column, graph databases, ...). В итоге, у нас получаются bounded contexts и наборы query для получения данных - это можно использовать для моделирования данных с использование Chebotko diagrams. Тут же авторы рассказывают про secondary indexes, свою часть которых должна хранить каждая нода. А также про материализованные представления (materialized views), которые позволяют хранить преконфигурированное view, которое помогает с запросами, которые основаны на одной из колонок, что не входят в primary key.

8. Application Development with Drivers - рассказ про возможности драйверо для работы с Cassandra. Так как книга была написана уже давно, то рекомендую почитать доки к последнему драйверу для Java от DataStax.

9. Writing and Reading Data - авторы рассказывают и показывают как писать и читать в Cassandra с учетом tunable consistency. Они объясняют как выглядит write path и read path с учетом схемы деплоймента кластера, а также работы движка хранения (Commit logs, Memtable, SSTable, LWT). Также авторы рассказывают как работает батчевая запись, read repair, запросы по диапозонам, сортировка, фильтрация, пейджинация и удаление записей.

10. Configuring and Deploying Cassandra - авторы показывают как задеплоить свой Cassandra кластер при помощи ccm (Cassandra cluster management). Если у вас Cassandra предоставляется ни как сервис, то вам стоит внимательно прочитать эту главу (а тем у кого это сервис читать можно менее внимательно:) )

11. Monitoring - эта глава посвящена мониторингу кассандры. Авторы рассказывают про использование jmx, nodetool и virtual tables, которые предоставляют метаданные о нодах и таблицах через стандартный CQL. Также в этой главе упоминается про логгирование Cassandra

12. Maintenance - из этой главы становится ясно, что поддержка Cassandra совсем не тривиальная задача:)
13. Performance Tuning - авторы предлагают использовать USE для анализа performance и дальше они рассказывают про то, как устроить стресс-тестирование кластеру, а потом про ее тюнинг за счет кеширования, настройки memtables, sstables, commit logs, hinted handoff, compaction, concurrency и тредов, сети и выставленных таймаутов. А напоследок авторы разбирают настройки JVM, что влияют на perf Кассандры.

14. Security - глава начинается с того, а как устроена аутентификация и авторизация в Cassandra, например, авторы рассказывают про RBAC. Дальше наступает время обсудить encryption (сертификаты, node-to-node и client-to-node encryption) и опции безопасности, что можно настроить в JMX. А напоследок в главе рассказывается про audit logging и как его можно настроить

15. Migrating and Integrating - эта глава рассказывает как переехать с RDBMS на Cassandra и авторы выдают следующий алгоритм
- Понять когда пора мигрировать (авторы приводят список триггеров)
- Адаптировать модель данных (entity, relationships)
- Адаптировать приложение (поменять способы доступа к данным, способы поддержания консистентности, избавиться от хранимок (авторы рассказывают про UDF в Cassandra))
- Распланировать схему деплоя и смигрировать данные (предлагается стандартная схема без даунтайма с параллельной работой с новой/старой базой на уровне приложения)

#Software #Architecture #DistributedSystems #SystemDesign

Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022 (Рубрика #Architecture)

Интересный доклад Кирилла на тему архитектурного репозитория для компании среднего размера, в котором Кирилл рассказал про внедрение архитектурных процессов при росте компании. Основные мысли следующие
- При росте компании нужна формализация процессов проектирования
- Эта формализацию в небольшой компании может быть сделанна централизованно и для этого можно действовать пытаясь идти к подходам Arch as Code, который в версии Кирилла основан на следующих подходах и инструментах:
- Использование plantuml для описания диаграмм (фактически, это diagrams as a code) - я сам люблю этот инструмент для создания диаграмм. Он позволяет описывать диаграммы C4 Model и UML
- Использование Markdown для создания документации (из markdown можно генерировать в шагах пайплайна любые нужные вариации документации: сайт, pdf, ...)
- Использование Gitlab и TBD - собственно markdown документация и plantuml описания диаграмм лежат в коде (отсюда и название arch as a code)
- Процесс архревью выглядит как ревью изменения в архитектурном описании и получение аппрувов от нужных ребят: staff engineers, infra, security, etc

Дальше Кирилл интересно рассказывает про то, как выглядит их архитектурный репозиторий, который завязан на использование поддоменов из стратегических паттернов DDD и C4 Model для иерархического отображения архитектуры системы на разных уровнях абстракции. Интересно, что Simon Brown, создатель C4 Model, сделал свой инструмент для моделирования архитектуры - structurizr, где сначала идет описание модели системы, а потом можно делать разные view для разных целей (подробнее в моем посте)

В итоге, архитектурный репозиторий Кирилла имеет структуру вида
- Domains
-- Subdomains
--- Teams
---- Services
Дальше Кирилл рассказывает как эта вся машинерия работает, например, как заведены общие компоненты, как команды описывают свои сервисы и все такое. А дальше он переходит к описанию того, как в этом архитектурном репозитории пишутся и ревьювятся ADR (architecture decision records). Собственно при создании нового сервиса создается init ADR, в котором есть 3 части
- Описание проблема
- Ссылка на проведенный event storming (про который я уже как-то рассказывал раньше)
- Описание решения
Плюс прикладываются основные диаграммы:
- Container diagram
- Component diagram
- ERD diagram
- Use case diagram
При дальнейших ADR при изменениях системы описываются причины изменений + прикладываются диаграммы с diff было-стало, а также апдейтятся изначальные диаграммы.
Все это проходит ревью, у которого есть SLA по скорости ревью (утверждается, что SLA выставлено в 2 дня). После аппрува это все мерджится в репозиторий.

В общем, я думаю, что этот подход может неплохо работать на масштабе нескольких сотен человек. Но у описанного подхода есть проблема - реальность архитектуры существует рядом с кодом, так как схемы рисуют отдельные люди в отдельной репе, а код пишут другие и в других местах. Насколько эти разные реальности близки - это большой вопрос. Но называть такой подход как architecture as a code я бы не стал - это скорее тянет на architecture documentation as a code:) Но это уже большой шаг вперед по сравнению с тем, как обычно в компаниях управляют архитектурой, так что если у вас нет ничего, то попробуйте внедрить что-то похожее.

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems

ArchDays 2024 - CFP (Рубрика #Architecture)

Я уже рассказывал, что этой осенью пройдет очередная конференция ArchDays, причем уже в шестой раз. Я вхожу в программный комитет конференции и у нас открыт call for paper. И если вы принесете туда доклад по темам вроде arch governance, arch as a code, enerprise arch и вот это все, то с большой вероятностью именно я буду ревьювить его. Так что если у вас было желание обсудить со мной архитектурные вопросы, то you are welcome, регистрируйтесь как спикер здесь, заполняйте заявку, а дальше уже буду действовать я:) А если заявка пройдет ревью, вы выступите на конфе, а я потом пошарю ваше выступление в свой канал:)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #DistributedSystems #Conference

Архитектура как код - Роман Пионтик - ArchDays 2022 (Рубрика #Architecture)

Интересное выступление про Dochub от автора инструмента на ArchDays 2022. Актуальная информация по инсструменту расположена здесь, но тут я расскажу про основные тезисы доклада:
- Основная идея была в создании инструмена для покрытия всех этапов развития компании, от стартапа до зрелой организации.
- Этот инструмент должен быть адекватным конкретному домену, встраиваться в процессы производства и анализировать архитектуру.
- Инструмент должен был поддерживать расширяемую метамодель, позволяющую анализировать данные архитектуры.
- Инструмент должен поддерживать командное развитие архитектуры и контроль глобальных стандартов.
- То, что получилось позволило сделать "живые" документы и шаблоны, которые валидируются и актуализируются
- Внутри есть комбинация инструментов вида
-- PlantUML и Mermaid - для диаграмм как код
-- Markdown - для разметки и документации
-- Swagger и AsyncAPI - для документации контрактов API
-- YAML/JSON манифесты для описания архитектурных объектов
-- SmartAnts - язык для запросов по этим описаниям
Все это позволяет накрутить поверх проверки этой архитектурной документации, которые позволяют контролировать важные для архитекторов вещи при помощи запросов на языке SmartAnts.

В общем и целом, по моим ощущениям от этого доклада получается примерно такая схема:
- Предлагается некоторая система для документирования архитектуры на базе Dochub
- В этой системе работают специальные люди, у которых шилдик "архитектора"
- Они пишут не код приложений, а код, который документирует архитектуру
- Они же пишут валидаторы этого описания архитектуры
- А SDE (software development engineers) пишут свой код в продакшен системах
- Дальше встает вопрос а кто поддерживает актуальность production code vs architecture code и в рамках какого процесса? Например, если это обязательный этап для любой фичи и его надо пройти еще до ее релиза, то тогда lead time взмывает в небеса, если это делает благословленный небом архитектор, а если это делают SDE, то неясно какое преимущество он получает от этих действий. Если это делается постфактум, то мы опять получаем лаг между реальным кодом и архитектурным описанием как бы оно не было получено: нарисовано картинками или сгенерировано из описания картинки кодом (с тем же успехом можно промптом попросить chatGPT генерировать картинки).

P.S.
В этом подходе меня смущает, что все самое интересное заметено под ковер. Условно, хотелось бы уметь связывать архитектурное описание и реальность, причем идти от второго, а не рисовать первое хоть кодом, хоть руками. В итоге, описанный процесс с Dochub мне кажется сложным, дорогим и неудобным для всех в команде разработки, кроме архитектора, который находится во вне и придумывает правила и проверки, а также рисует диаграммы кодом.

P.P.S.
Интересно сравнить рассказ Романа из Сбера про Dochub и то, что в том же 2022 ходу рассказал Кирилл Ветчинкина из Сбер Маркета про их архрепу и процесс написания ADR (я рассказывал об этом вчера). Подход Кирилла показался мне более приземленным, практичным и полезным.

P.P.S
В следующем посте напишу куда я бы хотел копать эту тему с архитектурой, чтобы сделать сделать работу над архитектурой неинвазивной и полезной для самих разработчиков.

#Architecture #Software #SoftwareArchitecture #Management #Processes

Материалы к докладу "Architecture at T-Bank: how we design our solutions" (Рубрика #Architecture)

Сегодня я выступаю на нашем фестивале Т-Двор в Питере с рассказом про проектирование и архитектуру. Сегодняшний день фестиваля посвящен науке и технологиям, поэтому я решил взять такую тему и подать ее по максимуму просто, чтобы любой посетитель фестиваля понял. В итоге, у меня в докладе получилось много отсылок, которые заинтересовавшиеся смогут изучить в свободное время сами, а не просто верить мне на слово:) И вот эти отсылки
- Мое древнее выступление на ArchDays 2020 про подходы T-Bank (ex Tinkoff) к архитектуре
- Книга "Learning Domain Driven Design"("Изучаем DDD") Влада Хононова и особенно первая часть книги про стратегические паттерны DDD, где идет речь про бизнес домены и поддомены, а также их типы (core, generic, supporting). Про книгу я уже много рассказывал раньше
- Cynefin framework - интересная концепция про сложность с точки зрения предсказуемости наших действий, подходит для размышлений как в контексте менеджмента, так и архитектуры
- Книга "Balancing Coupling in Software Design" Влада Хононова или хотя бы его выступление "Сложность и модулярность две стороны одной медали" на ArchDays 2023, про которое я рассказывал раньше. Влад хорошо рассказывает про архитектуру как управление сложностью и показывает простой инструмент для ответа на вопрос "а хороша ли наша архитектура" и пора ли ее улучшать:)
А дальше идут отсылки к тому, а как менять это в большой организации
- Закон конвея и обратный маневр Конвея и почему нам часто для улучшения архитектуры системы под задачи бизнеса надо поменять оргструктуру. Кстати, я раньше рассказывал про интересный доклад "How Technical Problems Cause Organizational Friction" от Adam Tornhill на тему того, как из кода можно вытащить данные о том, что есть проблемы со взаимодействием команд и принять меры:) Ну и в эту же тему есть мой рассказ про изменения в мобильном банке, где менялась команда, процессы, архитектура, ...
- Переход на платформенные решения - мне видится это основным способом двигать архитектуру IT систем в сторону унификации и начинать экономить на масштабе, так как платформенные решения можно централизованно развивать под нужные сценарии. Рекомендую на эту тему почитать статью моего коллеги Димы Гаевского, который ее сделал по мотивам своего выступления на Highload++ Spb 2022 (я уже рассказывал про этот доклад раньше)
- Архитектура как код - это интересная концепция, которая у многих на слуху. Текущие подходы больше напоминают архитектурную документацию как код, которую сложно и дорого поддерживать, но которая дает ощущение контроля за архитектурой. На эту тему можно посмотреть
-- Выступления Кирилла Ветчинкина из Сбер Маркета, про которое я уже рассказывал
-- Выступление Романа Пионтика из Сбера, про которое я уже рассказывал
Мне кажется, что можно сделать работу над архитектурой еще лучше, но про это я отдельно напишу большой пост позже.
- Тестирование архитектуры - когда архитектура становится чем-то более приземленным, чем картинки, то появяляется желание ее протестировать. На эту тему можно почитать следующие книги
-- "Building Evolutionary Architecture", в которой был концепт fitness function, но не было интересных примеров (я про нее рассказывал)
-- "Software architecture metrics", где были примеры с архитектурными метриками (я про нее рассказывал)
-- "Continuous Architecture in Practice", где была похожая история с тестами архитектуры (я про нее рассказывал)

#Architecture #Software #SoftwareArchitecture #Management #Processes

System Design. Как построить распределенную систему и пройти собеседование - Владимир Маслов - JPoint (Рубрика #Architecture)

Интересный доклад про System Design Interview от Владимира Маслова. Он сделал прикольный обзор этого типа интервью и рассказал с мемасиками про следущие темы
- Зачем работодатели проводят этот тип интервью и что хотят проверить
- Какие варианты бывают (популярный сервис с нуля, новая фича в известный сервис, архитектура вашего проекта)
- Как важно общаться с интервьюером и уточнять у него, а что именно требуется спроектировать
- Кому обычно дают system design interview
- Как выглядит структура собеседования (по Alex Xu): Functional requiremens -> Non-functional requirements -> High-level design -> Detailed design -> Bottlenecks & tradeoffs
- Какие сигналы хочет увидеть интервьюер (умение понятно выражать мысли, аргументировать свои идеи, опыт проектирования, понимания ограничений спроектированного решения, ...)
- Как прорабатывать каждый из компонентов собеседования в глубину: требования, высокоуровневый дизайн, погружение в отдельные компоненты, масштабирование, надежность, ...
- Как подготовиться к интервью - здесь автор доклада дает много add-hoc способов где что по быстрому подботать, но также приводит и книги, которые стоит изучить
- Как набить опыт и повысить шансы найма через мок интервью
- Как навыки проектирования могут пригодится в реальной жизни инженера, а не только при прохождении интервью

В общем, мне было по фану смотреть это видео - оно сделано забавно и содержит много полезно контента.

P.S.
Когда-то я тоже рассказывал про этот тип интервью и подготовку к нему на ArchDays. Вот запись, расшифровка и рекомендуемые материалы.

#SystemDesign #SoftwareArchitecture #Software #Conference #Architecture #DistributedSystems #SystemDesign #SystemDesignInterview

Как остаться человеком в команде - Илья Якямсев - Trampoline Meetup (Рубрика #Humor )

Последние дни я слишком много говорил про архитектуру и проектирование, поэтому сегодня расскажу про забавный доклад от Ильи Якямсева, которому удается быть одновременно и стендап-комиком и agile коучем. И хоть Илья не пишет код, но в вопросах менедджмента и общения с людьми он собаку съел, поэтому его выступления на ИТ-конференциях смотрятся свежо и интересно. В этом докладе Илья рассказывает про правила коммуникации в IT-командах. За 40 минут получилось раскрыть тезисно
- Почему лучший сотрудник – Лунтик
- Какая основная ошибка новичков
- Почему ваш план больше вашего рабочего места
- Почему так важна иерархия и криги «я / команда / компания / клиент / рынок»
- Почему любое действие – это разговор
- Почему правила должны быть записаны
- Зачем разделять умение говорить и умение говорить по делу
- Как использовать иерархию как инструмент
- Почему, если ты не можешь объяснить, то ты не знаешь
- Что такое T-shape
- Что такое "5 почему" и чем они полезны
- Что делать в любой непонятной ситуации …

P.S.
У Ильи был и друго крутой доклад "Как перестать управлять и начать работать", про который я уже рассказывал раньше

#Humor #Management #Leadership #Software

Раз архитектура — «as Code», почему бы её не покрыть тестами?! - Руслан Сафин - ArchDays 2023 (Рубрика #Architecture )

Интересный и практичный доклад от Руслана Сафина на тему тестирования архитектуры. Основная логика доклада примерно такая
- Описываем архитектуру через plantuml в нотации C4 Model
- Все это сохраняем в репозитории в виде исходного кода (в той же репе, где хранятся конфигурации deployments для k8s)
- Дальше тестируем в пайплайнах соответствие нарисованного в plantuml и того, что лежит в настройках deployments (например, автор показывает как проверяется, что список сервисов в plantuml соответствует тому, что описано в деплойментах для k8s). Это позволяет поддерживать актуальность описанного в plantuml тому, что деплоится в реальности
- А вообще можно проверять тип и параметры связей, параметры деплойментов, соответствие конвенциям. Поэтому описываем базовые принципы нашей архитектуры и начинаем проверять их автоматически.

Руслан приводит следующие примеры принципов, которые они реализовали у себя
1) Использование ACL (anti-corruption layer) паттерна - сервисы, что реализуют ACL помечаем как adapter в plantuml, а дальше проверяем, что связи со внешними системами идут только через такие сервисы
2) Пассивные репозитории - репозитории предоставляют доступы только поверх БД, к ним могут быть входящие связи от сервисов, у них исходящие связи с базой, но вот исходящим связей к другим сервисам быть не может
3) Внешние вызовы должны идти через API Gateway - проверка по url в конфиге k8s и архитектурной диаграмме
4) Операции записи идут только через оркестратор бизнес-процессов (Kamunda)

Дальше можно накручиваать проверки и других принципов, которые вы приняли для себя (и зафиксировали в ADR). Ну и если находятся новые архитектурные проблемы, то можно написать еще новый тест и поправить потом проблему.

В конце доклада Руслан поделился тем, какие реально проблемы были решены
- Была актуализирована архитектура, а также приведена к конвенциям
- Были удалены устаревшие топики, куда только пушили сообщения, но не вычитывали
- Нашлись дубли внешних систем, которые были заведены в разных командах
- Получилось посчитать техдолг по количеству тестов и сервисов

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

P.S.
Странно, что в самом начале доклада Руслан говорит о том, что об идеи о тестировании архитектуры никто не додумался.
Этой теме очень много лет и про нее можно почитать книги, про которые я вспоминал раньше
-- "Building Evolutionary Architecture" (первое издание 2017 года), в которой был концепт fitness function, но не было интересных примеров (я про нее рассказывал)
-- "Software architecture metrics" (2022 год), где были примеры с архитектурными метриками (я про нее рассказывал)
-- "Continuous Architecture in Practice" (2021 год), где была похожая история с тестами архитектуры (я про нее рассказывал)

Ну или почитать whitepaper пятилетней давности "Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles", о котором я рассказывал в прошлом году.

#Architecture #Software #SoftwareArchitecture #Management #Processes

AI для разработки - базовый навык для 2024 - Владислава Куклева - Agile Days 2024 (Рубрика #AI)

Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"

#AI #ML #Software #Processes #Management