| HN Mirror

they accomplish the same goal; If you are taking the flexibility out of IAAS (please don't say "cloud") through reserved instances, the biggest difference is that you need someone on call to physically handle hardware if you co-lo.

I mean, I agree that they are very different products, but IAAS and a vps are different products, too. (with a VPS, the customer expects me to preserve the data on disk. With IAAS, the customer expects to be able to spin up new nodes on demand.) If anything, co-lo is much more like VPS or dedicated servers, in that you generally use raid and expect the RAID to be fairly reliable.

But if you are running a webapp, just like most webapps that could run on a VPS can run on IAAS and vis-a-vis, most webapps that can run on a dedicated server or IAAS can also run on co-located hardware you run.

The cost difference is, well, dramatic. Of course, the stress difference, if you are notified that you made the front page of hacker news Thursday evening and have to come up with more servers same day on a friday, and your application can't run on IAAS? The stress difference can also be considerable. so I'm not saying colo is always the answer; I'm just saying that if you are looking at hosting options for your webapp, colo deserves a look.

Of course, if you do co-lo, don't forget redundancy. Good hardware you own with RAID is going to be significantly more reliable than a single IAAS instance, all things being equal, but you don't run something on IAAS without redundancy, and if downtime is expensive, you won't run it on hardware without redundancy. For some applications, it's enough to just have spares and carry a pager (of course, that's also a pain in the ass. I better be saving a lot of money to carry a pager) and for other applications? It's okay to just wait until Monday and get the people you bought the computer from to fix it. In those cases, I'd practice spinning up your app on IAAS so you have something, just in case.