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.
Interesting analogy. At the end of the day, however, what are we trying to achieve from this model? It seems like maybe the author is after faster production time. While this has its commercial advantages (as the author points out in his slide presentation) it's not necessarily the bottom line for every application.
The article finishes with, "Having said that, we still have a thing or two to learn from the physical world." I would argue the reverse in this case. My problem with the assembly line is that its bottom line is only speed, without stopping to think of time vs. product diversification. Search queries in the cloud aren't streamlining the process to respond the same every time (that's 1.0) they are dynamic (2.0). But the physical world assembly line is very much static.
Shouldn't we be applying cloud principles to physical world examples? Why isn't buying a car like buying a computer from apple.com or dell.com? Take a base model, tweak the specs to be personalized, and hit "make this for me". The cloud assembly line would then adjust real time to create the personal model. 93 seconds a car? Probably not. Higher rate of sales? Most likely.
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.