Continuous Architecture in Practice — Episode 2

One of the hosts recalls the shape of the book: the first two chapters set out principles and the processes around architectural work, and the rest is a toolbox, where each chapter surveys one area, ends with a reading list, and ties its choices back to a principle. The authors name three drivers for paying attention to data: the explosion of storage technologies provoked by internet-scale companies; knowledge pulled out of data for strategic decisions; and a business focus on managing by data, with high-margin industries such as pharmaceuticals and finance as examples. The host says frankly that a thirty-page chapter tries to fit in every known technology and works more as a landing page for the next reading list: Kleppmann called his own book a short overview with a long bibliography, and here is an overview of that overview in half an hour. Another participant adds that the drivers look lifted out of context — a 24/7 world, many different databases, a business that wants to be data-driven — while where they grew from is something the authors promise for the slides ahead.

Then comes the triangle: bits on disk turn into information, information into knowledge — answers to questions — and the top is wisdom, the connections and the answer to why, such as understanding customers well enough to give them a better product. The authors show the shift in thinking through a banking example, the move from an account-centric to a client-centric model, and one of the hosts recalls how in Nizhny Novgorod a single branch serviced your account, so you travelled to a particular part of the city depending on which bank of the river you lived on. DDD and ubiquitous language turn up here too: the authors point to Evans and Vernon, the participants to the book with the monkey on the cover by Vlad Khononov, discussed in the club; they also spot a slip where subdomains are called bounded contexts, which is not a DDD hierarchy. The host retells the storage history himself: relational databases, web scale, weaker guarantees traded for speed, the old Amazon Dynamo, the Google file system, and the term NoSQL left over, by his account, from a meetup around 2009.

The list of extra topics proves more useful than the overview itself: data and metadata ownership, integration, schema evolution. The authors pin ownership to a service or domain that becomes the single source of truth, with everyone else referring to it by identifiers — constant extra traffic to be balanced; in the running example, an application for letters of credit, unchanging data is simply cached on the service that needs it. One participant likes the split of ownership into writing and reading, producer and consumer, and since every component in the example has its own database, ownership falls out almost automatically. Schema evolution covers both data inside services and data between them, and boils down to API versioning and exchanging specs. The chapter closes quickly, with a note that integrations — REST, GraphQL, gRPC — look unexpected in a data chapter, and that the club already had the schema conversation with Kleppmann a couple of years ago.

Security is led by the guest, and the idea he gives the book a like for is this: security is a property of software that appears exactly where effort went, and effort spent here is not spent elsewhere — costs go up, protective features hit availability and performance. The book presents the confidentiality-integrity-availability triad, but fixating on it is a mistake: modern security starts from risks. Investing in protection means not investing in features, and the participants recall a similar thesis from Google's SRE book: pour enough time into reliability and the system turns rigid. What the guest argues with most is shift left. It is a slogan: you cannot shift left from zero, you start from the right — from pentests, audits and the experience of fixing architectural holes that take three months or half a year, after which everyone understands the price and will pay it. Otherwise the company reasons: we used to spend nothing, now a rouble — too expensive, make it fifty kopecks. And attackers come where least has been invested: plug in a heap of analysis products and you are still breached through a router sent by post, or through an employee.

The guest has two objections to threat modelling. Responsibility: the authors seem to assume IT does it alone, and he knows no company where developers build a good model themselves; doing it inside IT is fine, but somebody has to verify the result — otherwise you get what the book itself shows, a couple of threats written down for a class where the first search result lists ten. Methodology: he dislikes STRIDE, because modelling has to start from how critical the asset is — a payment provider and a landing page face different threats, and for an insignificant system risks can be written up minimally, but written up all the same, because systems run to hundreds and thousands and what matters is leaving the right artefacts and a repeatable checklist. The likelihood-by-impact matrix, the participants suggest, could be simpler and worked through from the top right corner; and a risk can be mitigated, avoided or accepted — basic product management.

The practical part draws the most corrections. A conversation with a developer about cryptography, the guest argues, starts not with symmetric and asymmetric schemes but with do not write your own crypto primitives: TLS and ready-made libraries exist, and home-grown crypto only counts as working once a rare specialist has checked it. One of the hosts objects that the book is about choices, not implementation, and the participants agree that such decisions belong in libraries or the platform. Then come backups an attacker cannot reach, such as storage that forbids overwriting; secret rotation, which cuts the life of a compromised secret to minutes; and phishing: an SMS code can be entered on any fake site, whereas factors that check the origin themselves take the user's training out of the equation. Zero trust the guest calls a simple philosophy — distrust the neighbouring system, look at context, put up bastions — while the book, in his view, is mostly padding on the subject. He also likes the term security theatre: risks overestimated, defences raised against everything. In a week the club takes the chapters on scaling and performance.