4 ms·
So, what's the consensus regarding colo vs. the cloud? I've enjoyed walking through rows of colo'd equipment, both as a security guard and as a technology profe
by nsxwolf 14y ago
So, what's the consensus regarding colo vs. the cloud? I've enjoyed walking through rows of colo'd equipment, both as a security guard and as a technology professional. There's a lot of romance to it.
It also seems that we've entered an era where you're a fool if you colo a lean startup. Is there a best practice, book, really good blog post, etc that helps one determine when it makes sense to colo vs just spinning up more Heroku dynos?
- rdl 14y agoIO heavy applications still don't belong in the cloud. They may make more sense in dedicated servers vs. coloing your own hardware, though.
- lsc 14y ago>IO heavy applications still don't belong in the cloud. I agree. >They may make more sense in dedicated servers vs. coloing your own hardware, though. depends on what skills you have already, and then your time to money exchange rate. If you use a lot of compute power, you can save a lot of money with a relatively small time investment, if you already have the skills.
- rdl 14y agoEven though I like messing with hardware, if you've only got a few racks of equipment, some kind of managed hosting often makes sense for alternate sites just due to cost of sending staff there to mess with things. Maybe use colo at your primary site, but managed hosting for a DR site somewhere.
- lsc 14y agoI think "the cloud" is perfect for DR. have a script that spins up your site in the cloud, test it one day a month, and pay for it one day a month. You go down for a day? you pay for one day in the cloud. Of course, this does eat the same amount of labor as building for the cloud /and/ building for co-lo, so you still have the time cost.
- mappu 14y agoSounds great, if your application state and user data doesn't go down with your app - keeping a DB slave out of every possible point of failure, somewhere far away in 'the cloud' means you have non-zero costs there.
- rdl 14y agoThe cloud is definitely good for being able to spin stuff up and down, but most stuff I've worked on is active-active with load sharing (and geographic proximity), plus at least a plan to spin up a new site (for which cloud would be awesome) once something goes down. It depends on how easily you can replicate the database -- if you can do true online replication across the Internet or a WAN between two remote sites, it is probably worth it in a lot of cases to go active-active. (I'm looking at doing SF + NoVA this time, and then probably EU -- we need Amazon Direct Connect nearby as well as good general Internet connectivity and reasonable colo. In DC that pretty much motivates toward Equinix DC1-6 or DC10. In the Bay Area, transport from SV1 is cheap enough)
- krobertson 14y agoIt is great for DR if it can support your IO load, considering the cloud sucks for IO. :) One project moved from AWS to a managed hosting provider with gear built to our specs mostly due to IO issues... continued to grow and then went back to AWS looking to do an easy DR process. Had some issues just with EC2 being able to keep up with replication at that point. The one thing I'd like to try with AWS though is their Direct Connect service. Basically colo in a facility near them and get a cross connect to EC2 (think it focuses on VPC). http://aws.amazon.com/directconnect/ http://aws.amazon.com/directconnect/ IO loads on real hardware, EC2 for all the other stuff.
- rdl 14y agoDC is unfortunately super expensive for outbound bandwidth ($0.03/GB/mo, or $9.60/Mbps/mo). I'm trying to figure out how to deal with that. On top of $2.25/Hr for a 10GE port ($1620/mo) and EQ $400/mo xcon fee, it adds up fast if you want to be DC'd at multiple locations.
- 14y ago
- jasonkester 14y agoCloud stuff makes sense if you have one little website (or certain values of one BIG website). But if you plan to be in this business for the long term, it just makes a lot more sense to have a quarter rack someplace with a couple fast boxes in it. I have something like 30 sites up and running at the moment, some big, some BIG, some small. Adding a new one involves spending seven dollars on a domain name and fiddling around for a few minutes in Remote Desktop, safe in the knowledge that it can live comfortably on that server for its entire life without me needing to figure out what a dyno is. So yeah, in the end it comes down to flexibility. Or rather how you define flexibility. Some people like to be able to spin instances up and down and squeeze their expenses down to the nearest micropenny. Others like to know that they have plenty of breathing room and no requirement to spin things in any direction at a price that's still on the same order of magnitude as the micropenny crowd.