

Henry Ford & Event Driven Architecture: Reinventing the assembly line - igrigorik
http://www.igvita.com/2009/04/06/henry-ford-event-driven-architecture/

======
iigs
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.

------
ivyirwin
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.

------
Create
"Ford invented the assembly line" ...or not. Although credit is attributed to
Ford (PR). While the article mentions wikipedia:

<http://en.wikipedia.org/wiki/J%C3%B3zsef_Galamb>

