Live data from Hacker News

Why We Moved Off The Cloud

code.mixpanel.com

51–60 of 154 posts

Re: Why We Moved Off The Cloud

#51
Thanks for this post. I currently own/run a niche social networking site with a little over 60,500 registered users and see several thousand users on the site at a time. I bought my own servers co-locate them in a large hosting facility in northern Virginia. The initial costs were the hardware, of course you can lease it if you want which can be cheaper if you intend to upgrade existing servers on a yearly basis. We do not need to do that quite that often, so buying them outright has been economical for us.

The ability to customize our boxes has been a big advantage for us and given the hosting facility has all the redundant power sources and bandwidth pipes we never see any problems. I will mention that most of our traffic is east coast based and given our servers are on the east coast we have not seen any problems. If we see traffic expand we would look to put some boxes on the west coast or midwest.

At one point I looked into us switching into the Cloud with AWS and and Rackspace, the costs were much more then we pay now.

In regards to bandwidth, most of the clouds pricing I have seen are based on total usage, our bandwidth is based on the 95 percentile usage. And it's not capped, so if we have a spike of 20mg/sec the pipe is open to fulfill it. The 95% pricing model as worked very well for us. We average a few mgs/sec and our bandwidth costs are under $50/month. I'd add to author when he talks about negotiating, do it, you can get a great deal (s).

I looked into AWS for another start up I am doing in the communications space and we tried it, for not a lot of users on the cloud it was very expensive. We moved to Rackspace and have limited our alpha users to $100, it's still expensive and as we move to launch over the next year we will go with dedicated servers.

Thanks for the post. Brandon

Re: Why We Moved Off The Cloud

#52
post #48

You didn't abandon "the cloud", you just switched providers. You're still paying someone else for servers that you don't own (unless softlayer ships you those machines after 3 years). This is why I hate the term "the cloud" -- because it is too nebulous and non-descriptive.

Cloud implies running in virtualized environment. Dedicated implies that only your bits run on that hardware which is huge for I/O.

Also, you don't necessarily take a huge hit in I/O with virtualization. VMWare on dedicated hardware with all the virtualization extensions will be pretty comprable and a lot easier to maintain then straight up raw iron.

Re: Why We Moved Off The Cloud

#54

The disk problem is always something I've always been fighting with when it comes to virtual private servers. I've never had to do so much optimizations with dedicated servers as I had to do with VPSs.

The disk problem is maddening, and I used to be a strong proponent of dedicated hardware for this reason.

However, the provider I use (Joyent) recently added some kind of disk scheduling that prevents these problems. I don't know how they do it, but hopefully more cloud providers do something similar.

Re: Why We Moved Off The Cloud

#55
post #48

You didn't abandon "the cloud", you just switched providers. You're still paying someone else for servers that you don't own (unless softlayer ships you those machines after 3 years). This is why I hate the term "the cloud" -- because it is too nebulous and non-descriptive.

Cloud implies running in virtualized environment. Dedicated implies that only your bits run on that hardware which is huge for I/O.

> Cloud implies running in virtualized environment.

Unfortunately, 'cloud' implies nothing. Apple's iCloud isn't necessarily storing my data using VMs and EBS/BigTable type FS. They could be using dedicated W2K/IIS 4.0 boxes storing BLOBs in MSSQL and still be considered cloud by everyone.

Re: Why We Moved Off The Cloud

#56
I think currently the biggest problem with the cloud is the inability for cloud providers to truly estimate and understand their risk, which also means that customers don't have the ability to understand their risks either.

For example, Amazon could estimate 99.95% downtime, because of physical and geographical redundancy, etc. But this analysis would be faulty, as their outage earlier this year showed.

There are a litany of long-tail black swan events that could bring down entire datacenters, that people just can't anticipate. Not even including earthquakes, terrorist attacks, etc, but even simple upgrades or misconfigurations like the one that took down their datacenter in the East Coast. Yet, they still advertise a SLA of 99.95% availability, etc. Is the risk to downtime really only 0.05%? Was the event that occurred really a 3 standard deviation event? I highly doubt it.

This complete lack of true ability to estimate risk means that customers also have essentially an inaccurate view on what their risks are. Like the one commenter who said that a small business ran their POS device over the cloud, if you told them that they would be down 2 days out of the year, would they really be interested in that? Probably not.

In a similar vein, the authors were likely promised great uptime, but no guarantees on I/O or CPU performance, which is something you don't think of. The cloud provider doesn't have to be down for your web service to be drastically affected. I suppose since this is all new, the customers are learning which questions to ask, and the cloud providers are learning which things to guarantee, so hopefully this is worked out in the next year or so.

Re: Why We Moved Off The Cloud

#57
post #52

Earlier quoted context omitted.

Cloud implies running in virtualized environment. Dedicated implies that only your bits run on that hardware which is huge for I/O.

Also, you don't necessarily take a huge hit in I/O with virtualization. VMWare on dedicated hardware with all the virtualization extensions will be pretty comprable and a lot easier to maintain then straight up raw iron.

And ESX with VMotion & DRS can make sure you still get good I/O even when parts of the hardware get congested or even offline.

Re: Why We Moved Off The Cloud

#58

Engineering is always about making the right compromises. Why does it have to be 100% dedicated or 100% cloud? What most people don't realize is that it really is a continuum. For example, why not run the disk performance sensitive DB server on a dedicated machine, while fronting the whole arrangement with proxies and app-servers hosted in the cloud? Ok, so there are latency considerations to be made, but you can see…

"For example, why not run the disk performance sensitive DB server on a dedicated machine, while fronting the whole arrangement with proxies and app-servers hosted in the cloud?"

That's actually exactly what we do:

"We’ve moved 100% of our machines that rely upon performant disks to dedicated servers hosted at Softlayer. Roughly speaking, this corresponds to about 80% of our hosting costs."

Re: Why We Moved Off The Cloud

#59
post #48

You didn't abandon "the cloud", you just switched providers. You're still paying someone else for servers that you don't own (unless softlayer ships you those machines after 3 years). This is why I hate the term "the cloud" -- because it is too nebulous and non-descriptive.

Cloud implies running in virtualized environment. Dedicated implies that only your bits run on that hardware which is huge for I/O.

I do not agree with this. Cloud is often a confusing term but it is not strictly bound to virtualization. One can imagine a cloud offer with dedicated hardware.

Re: Why We Moved Off The Cloud

#60

I think currently the biggest problem with the cloud is the inability for cloud providers to truly estimate and understand their risk, which also means that customers don't have the ability to understand their risks either. For example, Amazon could estimate 99.95% downtime, because of physical and geographical redundancy, etc. But this analysis would be faulty, as their outage earlier this year showed. There are a l…

While I agree with you providers obviously have been unable to avoid "long-tail black swan events" (awesome phrase!), and that too many businesses and users jump to the cloud without actually understanding their architecture, availability does not mean what you are implying.

99.95% availability means your site should be "available" 99.95% of the time. It does not mean you have a 0.05% chance of a disaster, it means you will not have more then 21.5 minutes per month of outages. Those 21.5 minutes might be during your most critical time. They might even all be added together for one 4 hour downtime before you're demoing to VCs and still not violate your SLA for the year.

Post reply on HN