You may have heard of the CAP theorem: no distributed computing system can offer partition tolerance, basic availability, and immediate consistency all at once. You can have any two of these characteristics, but not all three.
Partition tolerance essentially means that the nodes in a distributed application can lose communication with each other, and the app will continue to function. With basic availability, individual nodes may fail without bringing down the app. Immediate consistency means that data on each node will always be consistent with every other node.
Why should you care? Because Clouds are inherently partition tolerant and offer basic availability – and therefore, cannot offer immediate consistency. The best they can offer is eventual consistency: data may be inconsistent for a short amount of time before a synchronization operation brings them back into a consistent state.
If you require immediate consistency, say because you want to put an enterprise relational database in the Cloud, then it must go into a single partition. As a result, it won’t be able to take advantage of the elastic benefits of the Cloud.
On the contrary, if you require elasticity (and who doesn’t these days?), then you must rearchitect any app that relies upon immediate consistency. That change isn’t necessary a deal killer–after all, you get to decide how often to perform your synchronization–but it may be problematic if the app in question is some crusty piece of legacy you’re loathe to change.
