Something else I think people fail to consider is what I would call a hybrid approach.
For example, even if you mostly operate on your own infrastructure, keep a replica of your data tier going on EC2, along with freshly configured images for the rest of your moving pieces. This way you have an instant pop up B site for disaster scenarios.
There are a lot of other possible concepts. Keeping a dataset at amazon to use for map reduce jobs is convenient. Or even if you want to keep your infrastructure virtual, being able to price arbitrage across a couple providers could be a powerful cost reduction. The price of entry for all this is devops automation, but I think people are now mostly convinced that's worth it.
I think it's the best way to go, but also for a resilience approach, I want to be able to ditch a datacenter in 15min. If you can ditch the datacenter, why not ditch the whole provider?
So we tried to keep the deployment scripts ready for a competitor at all times, having backups we could restore there etc. And if you grow big enough, this becomes a bargaining chip with your provider too: I can ditch you in 15 min.
Something else I think people fail to consider is what I would call a hybrid approach.
For example, even if you mostly operate on your own infrastructure, keep a replica of your data tier going on EC2, along with freshly configured images for the rest of your moving pieces. This way you have an instant pop up B site for disaster scenarios.
There are a lot of other possible concepts. Keeping a dataset at amazon to use for map reduce jobs is convenient. Or even if you want to keep your infrastructure virtual, being able to price arbitrage across a couple providers could be a powerful cost reduction. The price of entry for all this is devops automation, but I think people are now mostly convinced that's worth it.