The core idea of this article has merit but the analysis of the topic is abysmal. Ford invented the assembly line, we're calling it "Staged Event Driven Archit

The core idea of this article has merit but the analysis of the topic is abysmal. Ford invented the assembly line, we're calling it "Staged Event Driven Architecture (SEDA)". End result, ninety three seconds to manufacture a car vs one to two days, and over one million cars produced every year. I'm going to go out on a limb and say there's never been a way to assemble an entire car in 93 seconds. It takes almost that long to put the lug nuts on two wheels, if you're fast. I believe the ideas of retirement rate and total time to perform are being conflated here. You could get the same thing with 930 teams performing the task the slower, manual way. There are obvious speed benefits to specialization, but the two ideas should not be confused. First and foremost, stop thinking about time to complete. Think workflow instead. There is no reason to hold up the front of the line if someone else can do the work later. By deferring the work you cut down your response time, which means snappy user experience, and it also means that you're able to take advantage of the latest industry buzzwords: elastic computing, and real-time web. Time to complete is crucial if you need to make a decision about step two with data from step one. For example, consider an order flow: you have to decide whether or not to ship a product based on a credit card approval. Furthermore, if the card is not approved, you'd like to provide the opportunity for your customer to edit their information, rather than just wonder why their widget never arrived. Also, elastic computing is orthogonal to this. If you have 1000 concurrent order flows you could still assign an entire machine to each order flow: very much the "one team per car" approach derided above. All of the sudden, the cost of hiring / firing another server is zero, and the datacenter (factory) costs are swallowed by the provider Vendors are not charities and costs are never "swallowed" by a profitable vendor. While analysts love the hand-wavy approach of "just build everything IN THE CLOUD", a lot of workloads that would be ideal inside of EC2 (for instance) are great... until you consider the costs. Just allocating one machine and leaving it idle all month is (IIRC) $70ish/mo: vastly more expensive than a non-cloud approach. The win comes when your workload takes advantage of what the cloud providers can do cheaper than you can. Sometimes this means parallelizing the old dumb way instead of spending the time and money engineering a cloud compliant web-2.0+ system.