I'd consider the issue of latency to be a switching cost vs. lock-in. You could move all your stuff over to the new, shiny cloud. Of course, if Cloud A is goo

I'd consider the issue of latency to be a switching cost vs. lock-in. You could move all your stuff over to the new, shiny cloud. Of course, if Cloud A is good for some stuff and Cloud B is good for other stuff, then you're stuck in the middle (without low-latency peering as some commenters have mentioned). In general, I don't see why people are scared of Amazon EC2 lock-in. You're still writing a regular 'ol app that runs on RedHat (or whatever). How does switching over to your own datacenter require any re-writes (other than config changes, etc.)? I understand the S3 issue, but you ought to be abstracting away the S3 details anyway with a code layer. So, you could implement some sort of hybrid scheme (S3 + new way abstracted away) easily enough if you must avoid downtime Or, if you don't have that much data, just write a script to move it all over. Queuing: If you're relying on some specific feature of SQS, you're doing it wrong. Payments: Ok, this gets interesting. But, it's low volume compared to most computing activity, so you can afford the latency. It's not like your DB is at Amazon and your app servers are somewhere else. I'm more sympathetic to Google AppEngine lock-in. However, I don't think it's too hard for someone to implement the limited set of interfaces provided by the cloud (at least in the Java case -- I haven't examined the Python one), so it's easily broken. As Clouds become more abstracted away from hardware and the current ways of doing things, I think lock-in will become a real concern. But, it doesn't matter right now.