I'm still struck by what a strong endorsement DynamoDB is of the design decisions we've been making in Cassandra over the last couple years. Composite keys, distributed counters, ...
Dynamo as described in the original paper was not made into a web service.
Facebook took up the Dynamo torch and created Cassandra... then switched to HBase after trying to use Cassandra in production.
Have you ever stopped to wonder about what Amazon might have taken OUT of Dynamo before launching DynamoDB? Things that Cassandra still has and just might be holding it back?
That to me seems much more important than just saying "DynamoDB has feature X that Cassandra has had for years! We're so smart!"
There's less to write about there... One of the first Cassandra decisions was dropping vector clocks, reasoning that vector clocks weren't worth the additional complexity for 99% of uses (once you move from key/value to rows + columns). DynamoDB also switched to items/fields and dropped vector clocks (or at least does not expose them).
The original Dynamo was plain key/value with O(1) routing and vector clocks; there's not much else to strip out. :)
P.S. Facebook built Messages on HBase instead of Cassandra for political reasons rather than technical, and shards HBase to mitigate the availability problems it has otherwise. Facebook never ran an Apache Cassandra release in production.
Composite keys (multi-dimensional) and distributed counters were not in the Dynamo paper. They were added to Cassandra, which is indeed based partially on Dynamo.
Cassandra initial team was lead by Avinash Lakshman who was one of the authors of Amazon's Dynamo. So it's not strange that Cassandra is hugely inspired by Dynamo (and vice versa).
Yes, but the Dynamo paper offers two operations Get(key) and Set(key, value). Anything Cassandra adds atop that they did themselves i.e. column families, secondary indices.
More details: http://www.datastax.com/dev/blog/amazon-dynamodb