Continuous Architecture in Practice — Episode 3

The hosts open with a warning: the chapters of parts two and three strike them as shallow, the authors duplicate text between chapters and at times inside a single chapter, the page count grows while the content shrinks. Nobody wants to return to it as a reference: it is neither Kleppmann nor a thick distributed-systems textbook, but a philosophical overview where every term collects several definitions. Scalability is defined as the ability to grow and shrink together with cost: the ideal is linear, five per cent more clients giving five per cent more spend, while idle resources mean money burnt inefficiently. The participants note that the real subject is elasticity — the ability not only to add resources but to give them back as load falls away — yet the term appears exactly once, and only about clouds.

Alexander explains what overview books are good for: in his head they unfold a map of related concepts. Here he recalled an author who once worked at Amazon: that one started not with technique but with the question of what actually needs scaling, looked at company processes rather than code, and carried it to the point where the whole chain of services has to scale. Against that, the book under discussion reads like a table of contents: the topic matters to everyone in the room professionally, but without twenty other books behind you there is little to extract, and the emphasis falls on the commercial cloud, where much of it comes out of the box. What the participants did like is that the authors tie scalability to economics; a story surfaces at once about accidentally spending forty thousand in a month in the cloud before autoscaling was wired up. The running fictional case draws the opposite complaint: the genuinely hard situations are declared inapplicable exactly where they get interesting.

The strong question in the chapter is whether you need scalability at all: stakeholders will not tell you, because they may not know themselves. The book shows it through a bank, where the number of tellers caps the flow of clients, while a participant carries the example on himself: an office with twenty tellers, and plans to build another a year on; in modern products nothing caps the flow, and the participants confirm that a product sometimes goes virally popular and grows well beyond the boldest assumptions. The shapes of the dependency — constant, linear, stepwise, exponential — are named and then forgotten, never returned to, as far as the speaker recalls. The forces are modelled as supply and demand, but on automatic scaling the participants add their own point: widening one place in a complex microservice system is like cutting a single traffic light from a hundred and twenty seconds to sixty and ending up with ten points of congestion instead of eight, because the load has simply moved further down the chain, and all of it then has to be brought back up.

One participant would rather not quarrel over where scalability ends and performance begins, and proposes describing quality attribute scenarios in full — what type, what we expect, how it will evolve — then checking them with fitness functions; he points to Requirements Engineering for Software and Systems by Phillip Laplante, which he found academic, while a host answers honestly that he understood nothing and asks for a link. The list of tactics — split clients across instances, set up a master and replicas, separate services by domain — is called banal: not a word about availability, and complex technical decisions hide behind the boxes and cylinders. Alexander brings up an engineering article from Ozon about caches: master systems that scale badly on their own survive peaks of around 350 Gbit/s, but the caching strategy is centralised, so a team now has to know its neighbours' caches — a nested locale parameter can serve Chinese responses to Russian users. Engineering-wise the problem is solved, organisationally it repeats the trouble of a centralised data warehouse.

Databases and clouds come next. In the book's case study the analytics replica is fed by native replication rather than events through a broker, because that is cheaper and needs no extra serialisation, and the decision is that alternatives need no revisiting for a couple of years; nothing is said about whether the replication is synchronous. Partitioning, the authors advise, should be deferred to the last, and the participants agree: it turns the system into a distributed one. What is left unexamined is how far a database can be grown vertically — a live question while Oracle is still sold to you, with its nearly endless vertical growth and RAM measured in terabytes, after which moving to another technology means almost a full rewrite. On the cloud the book carries two sound warnings that deserved red type: money can vanish fast, and the provider has limits too, raising which through a manager takes up to a day, precisely when the customers have already arrived. Serverless is recalled as absolute vendor lock-in: in an Amazon article, as the speaker remembers it, video analytics on lambdas was eventually rewritten back into a distributed monolith.

The second half of the episode belongs to performance, and a host reassures listeners: mentally swap scalability for performance and the content holds, a couple of criteria aside. Metrics are split into user-side time and throughput; the participants add that fighting for the tail of the distribution is very expensive, and it is sometimes cheaper to hand some clients a stub asking them to come back later. The network is wrongly forgotten in such conversations: exchanges write their own network card drivers, and at NASDAQ the fastest channel to the server is radio, with racks standing in the same building and a round trip of some fifty microseconds. Load testing past a certain number of requests per second runs into price: there is no production-like rig, so results must be extrapolated, and the growth curve only looks linear. Hence the plea to call it observability rather than monitoring, and the advice to benchmark a new database on your own scenarios, remembering that somebody will also have to fix it at night. The next episode is about reliability and circuit breakers.