Building Evolutionary Architectures — Episode 5

The third part is about impact: mechanics gave the theory, structure gave concrete architectures, and here it is glued together. The first chapter carries the name of the whole book and contains a subsection called mechanics, and the participants note the authors ran out of naming ideas, while every large topic opens with the same run-up: hardware used to be expensive, so decisions were made this way, and now look how good microservices are. The chapter opens with a digest of principles, the liveliest being the last responsible moment. One participant walks through a bank case: a cross-functional team of two developers, a tester, an analyst, and a security specialist built a new tool for counterparty work in weekly iterations, shipping the first version as the dumbest HTML form over a backend on Java collections, taking data in Excel and carrying it to counterparties for feedback. An external database appeared only around the seventh iteration, he reckons, a month or six weeks in; security joined after roughly two months, once the hardest hypotheses had survived.

The main methodological complaint: the principles of evolutionary architecture show up in a separate chapter near the end, whereas in another architecture book one participant read in parallel, six principles sit on the first page and every later example shows how decisions are made with them. The participants build the connection themselves: the roots are in the theory of constraints, and almost all of it together is about decoupling at different levels. The last responsible moment decouples decisions in time, Postel's law decouples interfaces, testability decouples processes, and Conway's law decouples teams; from Conway's article they recall the closing paragraph, which proposes rewarding managers for keeping their organisations compact. Testability is unpacked on the front end: an online shop carries about a hundred external scripts on its main page, tests hook onto elements by id, and ten teams have to agree on prefixes so identifiers never collide. The set of properties looks neat but, in one participant's words, resembles the animal classification from a Chinese emperor's encyclopaedia: no decision-making reasoning can be built out of it.

The participants state the book's key concept like this: we learned to push code to production quickly, then infrastructure as code joined and travelled down the same pipeline, and now the authors add a third layer — architecture, which is also described as code. Just as code is checked by unit tests and infrastructure by integration tests, architecture is checked by architectural tests such as performance ones: is it still viable within the limits we care about. Without that idea, one participant argues, the book is hard to understand. Another lays the same line out historically: agile and extreme practices taught constant checking of business logic, the devops transformation carried the practices to infrastructure, and now the same is stretched over architecture. Among smaller items the LCOM metric catches the eye, surfacing only at the end of the book: it shows how cohesive methods and data are inside a class but sees no logical connections, and its tool on GitHub dates to 2005, with the last commit about five years ago.

The guidelines get a quick run-through. Remove needless variability is illustrated with immutable infrastructure: manual settings are replaced by a description in code, and the authors note that immutability does not argue with evolvability but removes accidental differences and errors. Make decisions reversible drags in a wild story about one feature flag reused for different functionality, a joke that losing four hundred million takes skill, and Jeff Bezos's letters to shareholders: a reversible decision does not go to a committee, a smart person takes it at their own level. Sacrificial architecture — a term one participant credits to Martin Fowler — is illustrated by Twitter, which got to market fast and then rewrote everything for load; which raises the question of how evolutionary an approach is when evolution means a full rewrite. External libraries should always be hidden behind your own interfaces, and on versioning the authors advise keeping no more than two versions.

The second chapter covers antipatterns and pitfalls: the first looks like a good practice and betrays you later, the second hits at once. The ten-percent trap: a boxed product or a fourth-generation language covers eighty percent of your needs easily, ten percent with hacks, and the last ten not at all — and nobody tells you in advance which ten; the participants add that the trap also covers licensing and support. Vendor king is when a vendor box smeared with adapters becomes the core of your own domain; the examples mention 1C boxes, CRMs, and CMSs, and the ending is usually the same: rewrite from scratch or build the same plant next door on your own technologies. A regular audit helps — cover the vendor box on the diagram with a black square and see what breaks. In its purest form vendor king is business logic in stored procedures; import substitution is a separate case, with a deadline harsher than any performance limit. Under incremental change the single company-wide stack takes a beating: an architect from Wunderlist did the opposite, imposing different technologies on teams so no accidental links could appear.

One participant recalls his own system falling over entirely because of requests to an unimportant part: he strengthened the team and cut the components apart so dependencies could not exist in principle, though he admits in retrospect that a modular monolith with bulkheads, as on the Titanic, would have done. A separate complaint is per-client customisation: the authors say do not do it and offer no alternative, which Ilya had written into the chat before the recording. One participant is taken with the last chapter's picture of communication links, but the complete graph strikes the participants as exaggerated: five people in a room hear each other at once, so the real count is about half. The list of when not to use the approach feels formal — its closing item about winding up your business covers anything. One participant sums up: the authors borrowed terms from genetics, and the closer analogy is not human evolution but a virus, where small services mutate and die off fast while the colony survives. They thank Sergey for his two visits and promise the next episode in a week — about something Russian; the captions break off there.