Well, here I am blogging on the bus with my newly installed Windows Live Writer!!!
This blog is a text version of a five minute "Gong Show" presentation I did at CIDR (Conference on Innovative Database Research) on Jan 8,2007.
All computing can be considered as: "Memories, Guesses, and Apologies". This is a personal opinion about how computers suck. Furthermore, it offers additional opinions about how we can take advantage of their sucki-ness. Lets dig into this...
Newton and Einstein
It used to be that we thought of computing as one big-ass mainframe. The database folks only thought about the database. Transactions (and transactional serializability) offered a crisp and clear perspective of how time marches forward uniformly. When working on transaction T(i), any other transaction T(j) can be perceived as occurring before T(i) or after T(i). If T(i) and T(j) are concurrently processed, the transaction system ensures that either order is correct without modifying the semantics. This offers a crisp and clear perspective of now. Time marches forward like a clock exactly as Newton envisaged his universe.
Nowadays, we have lots and lots of computers. Big ones, small ones, connected, disconnected, occasionally connected, etc. These computers each have their own perspective of time. When you see data, it is unlocked and an artifact of the past. Time is subjective with many different notions of now. This is very much the way Einstein revamped our understanding of the universe.
Moving to SOA is like moving from Newton's Universe to Einstein's Universe.
Inventory and Forklifts
Even is your computer system is perfectly accurate, the data contained withe in it may be incorrect. Data is entered by people and/or sensors. You have the challenge of garbage-in-garbage-out.
Based on the knowledge contained with the computer, decisions are made.
"Jim wants to buy a widget."
"Hey, we have one in the warehouse in New York!"
"Ship it to Jim, should be there on Tuesday!"
Now this is just great... Then the forklift runs over the only widget you have in stock and you won't get any more widgets for a month!
Even if the computer is perfect, it is disconnected from the real world!!! Decisions made by the computer may not be possible to implement!
Guessing and Partial Knowledge
Computers always have partial knowledge for a couple of reasons. First, they will always be separated from the real world. Stuff that happens in the real world will, at best, be reflected after the fact in the computer system. Second, a computer system may have other replicas from which it is separated. A computer's knowledge of the world will be partial.
Computers do not make decisions... They try to make decisions.
The best a computer can do is make a guess. It might be a good guess. It might be a bad guess. Either way, there is no certainty, only guesses.
Memories and Sharing
It is really nice to remember your guesses... It makes it easier when you guessed correctly. It makes it easier to clean up the mess when you've guessed wrong. Usually, computers remember what they've guessed.
Furthermore, it is nice to share with other replicas. You get all the coolness of replicas,disaster protection, etc. Replication definitely helps with memories.
Increased fidelity of memories implies increased cost! The more money you spend on mirroring, replicas, disaster backup, and so forth, the better your memory. The more you spend on increased latencies while you ensure the replicas are in sync before proceeding, the more you reduce the chance of forgetfulness.
It is a business decision how much money, latency, and energy should be spent on reducing forgetfulness. To make this decision, the costs of the increased probability of remembering should be weighed against the costs of occasionally forgetting stuff.
Screw-Ups and Apologies
Consider the following slide from this mini-presentation:
#1 - The application has only a single replica and makes a "decision" to ship the widget on Wednesday. This "decision" is sent to the user.
#2 - The forklift pummels the widget to smithereens.
#3 - The application has no recourse but to apologize, informing the customer they can have another widget in one month (after the incoming shipment arrives).
#4 - Consider an alternate example with two replicas working independently. Replica-1 "decides" to ship the widget and sends that "decision" to User-1.
#5 - Independently, Replica-2 makes a "decision" to ship the last remaining widget to User-2.
#6 - Replica-2 informs Replica-1 of its "decision" to ship the last remaining widget to User-2.
#7 - Replica-1 realizes that they are in trouble... Bummer.
#8 - Replica-1 tells User-1 that he guessed wrong.
#9 - Note that the behavior experienced by the user in the first example is indistinguishable from the experience of user-1 in the second example.
Eventual Consistency and Crappy Computers
Business realities force apologies. To cope with these difficult realities, we need code and, frequently, we need human beings to apologize. It is essential that businesses have both code and people to manage these apologies.
Replication can force apologies. This is the same crap we have to deal with when the physical realities are out of sync with the computer's knowledge, [Please note: I am NOT saying that all replication errors are identical to the business realities. I AM saying that when you replicate business operations (rather than the back-end state of your internal database), the shape of being out-of-sync does, indeed, mimic the business realities.]
We try too hard as an industry. Frequently, we build big and expensive datacenters and deploy big and expensive computers.
In many cases, comparable behavior can be achieved with a lot of crappy machines which cost less than the big expensive one.
Consider the cost/benefit of building big-ass and expensive machines! Careful design of a collection of replicas may fill the business need at a better value!
Just a thought for the day...