Live data from Hacker News

Why We Moved Off The Cloud

code.mixpanel.com

111–120 of 154 posts

Re: Why We Moved Off The Cloud

#111
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.

NIST (the National Institute of Standards and Technology) actually has a pretty good (if not exactly short!) definition by listing the characteristics "a cloud" has: http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf

Leasing physical servers could be regarded as "cloud", but usually wouldn't because that method of hosting towards not meeting the Resource pooling, Rapid elasticity and Measured Service (esp "automatically control and optimize resource") characteristics (of course, one can argue that it can do those thing, but generally( it doesn't).

"Cloud" isn't* an engineering term, and thinking about it in absolutist, engineering terms makes as much sense as thinking about "web 2.0" in engineering terms 5 years ago.

Re: Why We Moved Off The Cloud

#112
post #32

Facebook's CTO thinks the opposite or perhaps even alike. IMHO, a startup should not start with dedicated, but perhaps when you get to a certain size, perhaps, dedicated hardware, team and bandwidth is the way to go. Just like you will not have a dedicated chef to cook your meal at start, but rather outsource meals, etc. -- http://www.bbc.co.uk/news/business-12406171 What's the biggest technology mistake you've ever…

I've always thought the "Drive to the datacentre" argument was BS. If you're writing your app for the cloud, you have to deal with spurious instances going away, degrading, etc. It is no different in the datacenter. If you're driving to the datacenter in the middle of the night to replace a disk or a fan, you're doing it just as wrong as if getting evicted from an EC2 instance causes you to have to scramble oncall re…

You are not necessarily doing it wrong, you may simply not have enough ressources ($$$) to buy enough hardware for complete redundancy.

When you get evicted from an EC2 instance you just switch to a new one, the cost is constant. When your piece of hardware at the datacenter goes down, unless you had the ressources for a spare one, you are hosed.

Re: Why We Moved Off The Cloud

#113
post #106

Earlier quoted context omitted.

> In fact they let you have both dedicated hosts and cloud hosts and allow dedicated and cloud hosts to talk to each other. That's not amazing at all. You do realise that a "cloud" host and a dedicated box are two exact same hardware boxes siting next to each other in a rack? One's just virtualized 10x with Xen, VMWare, KVN, etc.

Of course its not amazing, but it is a feature they have that would have made the transition to dedicated easier.

Being networked is a feature?

Re: Why We Moved Off The Cloud

#114
post #32

Facebook's CTO thinks the opposite or perhaps even alike. IMHO, a startup should not start with dedicated, but perhaps when you get to a certain size, perhaps, dedicated hardware, team and bandwidth is the way to go. Just like you will not have a dedicated chef to cook your meal at start, but rather outsource meals, etc. -- http://www.bbc.co.uk/news/business-12406171 What's the biggest technology mistake you've ever…

I've always thought the "Drive to the datacentre" argument was BS. If you're writing your app for the cloud, you have to deal with spurious instances going away, degrading, etc. It is no different in the datacenter. If you're driving to the datacenter in the middle of the night to replace a disk or a fan, you're doing it just as wrong as if getting evicted from an EC2 instance causes you to have to scramble oncall re…

I have to agree. I put our stuff in a colo 2 years ago and never looked back. Pretty much all servers come with some kind of remote console interface IPMI, and that's not terminal redirection, thats actually a totally self contained microprocessor and ether port that you can run on a separate subnet and control your server even if it's off. I updated the bios, reinstalled OS's, all via IPMI which is part of the motherboards. Add to that power strips that you can also control remotely and you're all set. Our servers are in the Bay Area, I'm in Canada. I have NEVER had to drive/fly to fix anything. Never even had to use remote hands for anything. Sure some drives died, but standby drives are in place.

The costs are dirt cheap these days. You can get a full rack, power and a gigabit feed for about $800 in many colos in texas. We opted for equinix in san jose, which is all fancy with work areas, meeting rooms, etc when you are there, but the funny part is, we're never there!

I do like the virtualization for some maintenance/flexibility so we have a few servers that are hosts and we run our own private cloud where we get to decide where/what runs. Database servers on bare metal with ssd drives in other cases. Best of both worlds.

It's so cheap you get a second colo in a different part of the country to house a second copy of your backups, and some redundant systems just in case something really bad happens.

Oh yeah and don't get me started on storage. We store about 100TB of data. How much is that on S3 per month? $12,000/month! A fancy enterprise storage system pays for itself every couple of month of s3 fees.

Re: Why We Moved Off The Cloud

#115

One thing I love about ec2 is that I can easily test/debug/modify my provisioning recipes (written in chef) from a blank slate. With fog ( http://fog.io/1.0.0/index.html ), I can start up a new ec2 instance in less than a minute and tell it to run the chef process. If it doesn't work properly, I shut it down and try it again. How does that work on a dedicated machine at, say, SoftLayer?

I use unmanaged dedicated servers with Serverbeach, but I assume SoftLayer has similar tools. If I totally screw up my server there are tools to boot in rescue mode or just wipe the machine and do a clean OS install.

For testing out puppet processes I use Vagrant with VirtualBox on my local machine.

Re: Why We Moved Off The Cloud

#116

Do you rent your house, or did you buy it? Cloud is renting servers: low cap-ex but high op-ex, minimal risk exposure, highly nimble. Dedicated hardware is buying servers: high cap-ex but low op-ex , more risk, and more consistent. There's nothing inherently "better" in either strategy; they each suit a different need.

Except in many places in Australia is actually cheaper than buying because poorly-educated investors have been sucked into the dream of financial freedom through owning an asset that always increases in value.

Re: Why We Moved Off The Cloud

#117
post #46

Earlier quoted context omitted.

> The moment a popular site like Reddit switches to the cloud, is the moment it becomes barely usable during certain times of the day. That's completely false. The moment reddit blogged about moving to the cloud, it was * perceived* as being slower. The cloud move happened 7 months before the blog post came out.

I think the OP just meant that once someone like reddit moves into your cloud, your performance goes down. Meaning, the hardware that my little blog is on works great until that hardware also hosting reddit, and then my blog takes a beating because reddit is thrashing away with actual activity.

Reddit wasn't just running on one instance on a single physical server in AWS mind you...

Re: Why We Moved Off The Cloud

#118
There are some cloud providers where you can allocate dedicated servers with virtualization on top. That way you can manage exactly what runs on each instance, while still have the flexibility to allocate more server instances quickly for handle growth.

Re: Why We Moved Off The Cloud

#119

Earlier quoted context omitted.

Yes, that is also an issue for us, we provide a large number of downloads (virtual machines, installers) that go into the TB and it would be quite expensive to move that over to EC2. One nice feature of Amazon, if you can afford it, is the ease of use with which you can put that content on their CDN

You can use their CDN (CloudFront) without moving your origin to EC2/S3. http://docs.amazonwebservices.com/AmazonCloudFront/latest/De...

Be sure to read the documentation though -- at the very least, keep in mind that they do not honor query strings, so any dynamic (I.e. behind a script) content you may want cached, you may have to do a little webserver rewrite magic for.

Re: Why We Moved Off The Cloud

#120

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…

Two points.

One, datacenter failure happens with any hosted application that runs within a single datacenter. Most other types of hosting also have a litany of other failure modes that go away with cloud, to be replaced by other modes. For example, you no longer have to deal with failures of individual hard drives, but now you have to deal with failures of EBS clusters.

Two, cloud provides a standard system that makes HA easy. Rather then having to do dual dc failover in hardware and having to deal with bgp, anycast ips/dns failover, dealing with splitbrains and hw stonith/etc. All of this is just taken care of for you and/or made a lot easier.

Post reply on HN