The Distributed Computing Manifesto

Alexander shares the draft of an article he has not finished and suggests working out what the manifesto actually said first: nine pages, apparently in three parts. The first is the service-based model. The original pain is stated plainly: the logic lived in Perl scripts that went straight into the database and knew all of its contents, and at some point that code grew so large that carrying on became impossible. The authors' answer is to carve out separate services with a very well-defined interface hiding the business logic, and to talk to them both synchronously and asynchronously, depending on the business process being modelled. One of the participants adds the main consequence: the discipline has to change. Nobody goes into the database directly any more, every service integrates through its own API, developers have to be retrained, and in 1998 that looked thoroughly unusual. He laughs that he started fifth grade that year while the people at Amazon were already gluing services together over APIs.

The participants liked the declared shift of mindset: away from data-centric design, where there is a database, a model built around it and that model spat straight out to the client, towards designing model, business logic and interaction interface separately. They phrase it as attaching data to the logic rather than the logic to the data — obvious today, but back then a new way of thinking about development. The text presents three-tier architecture as the new and exciting approach: interface, service, database — whereas before that the logic lived in stored procedures, and someone, the participants note, still writes that way almost 25 years later. The authors are never named: this is an Amazon manifesto written by anonymous people. It was published recently by the company's current CTO, Werner, who joined Amazon only in 2004, six years later, and who admits in the annotation that when he accepted the offer he thought there was nothing there beyond a database and web servers, despite his PhD in distributed systems.

The second part, on workflow, is taken up by another participant. The problem is shown on Amazon's own model: the cart and the life of an order from start to finish, all dragged through one shared model that lives in a central system; scaling is hard, adding new services is hard, and the central system is a single point of failure. The authors propose what is now called orchestration and choreography: either a coordinator that knows what is going on and who does the work next, or a chain in which each service knows whom to pass to. As a side effect, the volume of data each service works with shrinks sharply. Next to it sits the idea of splitting domains: data should belong to a single domain — everything about the user in the user service, everything about the order in the order service. The participants hear DDD in that, but qualify it carefully: Evans wrote his book only in 2003, five years later, and the authors invented at least contexts, if not domains.

The tools from the same chapter are a state store recording the current stage of an order, and subscribing to events so that changes of delivery address, recipient or the order itself get a quick reaction: a customer may well call to say they have moved to a neighbouring state while the goods are still waiting to ship. Alongside it the participants find an early idea of a separate analytical store instead of the whole history in the local database. The manifesto carries no technical detail — what queue they had in mind is unknown; one participant recalls a classic 2004 book on enterprise application integration and notes that its technologies are obsolete while the concepts are still alive. They also recall a big table of eight coordination options along the axes of synchronicity, orchestration and consistency: some combinations are unrealistic — a large investment for a tiny effect. The pros and cons of orchestration and choreography mirror each other, and orchestration earns its keep as the process grows complex: while it stays linear and nearly failure-free, choreography is simpler.

Alexander turns the conversation to what Amazon actually did. Until 2000 the company ran on Sun servers with a not-a-minute-of-downtime mandate, the system built out of services still came out fairly monolithic, and all of it cost astronomical money; having looked at order growth and the infrastructure bill, roughly five years after launch they began migrating to cheap servers and halted product development for a year. They were lucky: while they were rewriting, the dot-com bubble burst, other companies began selling their servers ten times cheaper, and the bill came out some 80 per cent lower. Even so, in 2005 the main problem was unchanged — every transaction on the site went through a single application, and carving out of it a service that could be developed, tested and deployed separately fell to a different senior manager. What happened between 1998 and 2005 nobody knows: the manifesto seems to have been written, shelved and dug out only in 2022.

From there the participants line up the evolution: monolith, two-tier architecture, three-tier, services, the microservices of 2014, serverless with control at the function level. One of the participants values isolation, platform independence and CI/CD practices in microservices, bought at the price of operational overhead; another reminds everyone that microservices are not an end in themselves. Alexander recalls his first real pain: he had dozens of services and no orchestrator fit for production loads — Kubernetes was published only in the summer of 2014. Sergey gives a working example: at Tinkoff the status of an application is assembled from events from various systems and delivered to the front end in advance, cutting the lag; another participant adds that this also takes needless load off the master systems. The closing stretch is about genre: the manifesto offers no proof, decisions today are written up as ADRs and RFCs, and a manifesto works as a statement about a target state or as a collection of practices — which is how the RKO unit in Tinkoff Business uses it. The participants call the episode experimental and promise to hunt for an even older manifesto.