Live data from Hacker News

Why Stack Exchange Isn’t in the Cloud

blog.serverfault.com

71–80 of 85 posts

Re: Why Stack Exchange Isn’t in the Cloud

#71
post #29

OT: I've heard claims that dedicated servers beat cloud VPS (i.e. AWS) in cost. But most of the dedicated servers I've seen cost $100 and up for a month. Is there a comparison on the cost/computing_power with benchmark for review?

What you care about at any reasonable scale (ie. the point at which costs matter) is $/serviced request. That usually ends up being dominated either in $/cpu cycle or $/iop. The current problem is that most cloud platforms suck iops which makes them far more expencive then they really should be.

Cloud vs. dedi vs. colo in terms of raw prices though, depends entirely on your price of money and the price you can negotiate with your provider.

Re: Why Stack Exchange Isn’t in the Cloud

#72

The reason I'm still wary of the cloud is that the abstractions are still too leaky (to borrow Joel Spolsky's turn of phrase). When you start abstracting away core system calls (like fsync), things work great 99.99% of the time. But when that .01% bites you, it bites hard . We don't expect core system calls (like fsync) to fail. And when they fail, the fact that our code is two or three levels levels of abstraction h…

Keep in mind that screwing with syscalls is an AWS thing, not a virtualisation thing. They make fsync wierd for good reason though, and they really don't have much they can do.

Re: Why Stack Exchange Isn’t in the Cloud

#73
post #30

Past article 'Coding Horror: Scaling Up vs. Scaling Out: Hidden Costs' http://www.codinghorror.com/blog/2009/06/scaling-up-vs-scali... Although it's not quite the cloud, one of the founders prefer vertical stacks due to several reasons including licensing costs.

You scale out hardware layer by finding optimal hardware and scaling out on that.

The major problem with their 'scale out' chart is that that particular hardware is far from optimal hence costing far more then it should.

Re: Why Stack Exchange Isn’t in the Cloud

#74
post #70
post #52

Earlier quoted context omitted.

Instead of 12 physical cores, 96GB of RAM and a 2TB SSD Array pushing 1M IOPs on dedicated hardware for my PostgreSQL database servers, I'd need 1TB of RAM in an AWS box because I'll be lucky if I can even break 10K in IOPs. Does the price make sense then? I have yet to see any significant AWS deployment that doesn't feel like it could be done better, more reliably, and much more cheaply as a co-located setup.

Saying that you can't get IOPS on AWS is like saying that your machinegun sucks at grating cheese. It's really not meant to do that. But that's fine as AWS isn't the only cloud platform out there, and some are actually desgined to take data intensive workloads.

The problem is that it's touted as a great way to scale web apps. Since DB performance is usually the limiting factor in webapp scaling, this doesn't appear to stack up. Needing a lot of IOPS is pretty par for the course.

Re: Why Stack Exchange Isn’t in the Cloud

#75
post #64

Earlier quoted context omitted.

Amazon has very good .NET support. So does Rackspace. So does Azure (obviously). In my personal experience the quality of cloud platforms has been comparable for both Linux and Windows environments. Is there any evidence that .NET cloud platforms are of lower quality? I'm genuinely interested. Please elaborate.

Personally, I doubt there is a real quality problem with those platforms. But running .NET on those platforms looks unnecessarily expensive to me. If I were married to Microsoft (as SO is) then I would avoid 'the cloud' for that reason. Given that one wishes to use Windows/.NET, I feel the decision follows pretty naturally from an analysis of costs - no vague argument about culture necessary

I would say cost (referring to license fees) is more relevant in deciding whether or not to choose the .NET stack in the first place. You're not going to avoid license fees by avoiding the cloud.

Their culture argument is a funny one. But I have no beef with it. If owning and tinkering with the hardware makes them happy, more power to them.

As an aside, I've been using Azure lately for my .NET projects. MSFT has done a nice job with that platform and don't get enough credit for it IMHO. I especially like SQL Azure.

Re: Why Stack Exchange Isn’t in the Cloud

#76
post #72

The reason I'm still wary of the cloud is that the abstractions are still too leaky (to borrow Joel Spolsky's turn of phrase). When you start abstracting away core system calls (like fsync), things work great 99.99% of the time. But when that .01% bites you, it bites hard . We don't expect core system calls (like fsync) to fail. And when they fail, the fact that our code is two or three levels levels of abstraction h…

Keep in mind that screwing with syscalls is an AWS thing, not a virtualisation thing. They make fsync wierd for good reason though, and they really don't have much they can do.

Right. The question, however, was about working in the "cloud", which usually means that you just have access to the VMs, not to the underlying hardware. VMs are great, but there's nothing like root access to the physical computer to help you diagnose hardware issues.

Re: Why Stack Exchange Isn’t in the Cloud

#77

Earlier quoted context omitted.

The practicality argument doesn't apply when they already say they're doing more than necessary because they love computers and if you don't that you don't really love computers . When someone says that you don't love computers because you did whats most practical or cost effective for you, how can they say that they love computers when they do or don't do something else because its most practical or cost effective t…

Clearly there's no difference in effort between a day installing and configuring a Dell server and several thousand person years of writing a solid, scalable operating system, so your question is perfectly reasonable.

I understand that what I'm saying is a bit of a stretch, but when they claim people don't love computers for not doing that they're doing, they may as well take it to the extreme. People have written operating systems, maybe these people should say everybody else doesn't love computers.

I mean, obviously I don't expect anyone to build everything they use. My argument was aimed at the "you don't love computers" statement and not at the fact that they don't write their own OS.

Re: Why Stack Exchange Isn’t in the Cloud

#78
post #52
post #25

Earlier quoted context omitted.

If you remove any rational analysis based on productivity, developer time, or finances, then we're only left with a question of personal taste -- and it's impossible to argue against personal taste. An evaluation based on personal taste is useless. If I say "I like orange because it's a great color" -- then either you already like orange, in which case my analysis does you no good, or you don't like orange, in which…

Instead of 12 physical cores, 96GB of RAM and a 2TB SSD Array pushing 1M IOPs on dedicated hardware for my PostgreSQL database servers, I'd need 1TB of RAM in an AWS box because I'll be lucky if I can even break 10K in IOPs. Does the price make sense then? I have yet to see any significant AWS deployment that doesn't feel like it could be done better, more reliably, and much more cheaply as a co-located setup.

Instead of 12 physical cores, 96GB of RAM and a 2TB SSD Array pushing 1M IOPs on dedicated hardware for my PostgreSQL database servers, I'd need 1TB of RAM in an AWS box because I'll be lucky if I can even break 10K in IOPs.

Does the price make sense then?

Does it? That's the point of analysis. It may be that you can scale up your organization on AWS, and then make the decision to scale something like a database vertically once you actually need it.

The choice should be based on a rational cost analysis, however. Not just money, but developer time, productivity, and a potential loss of focus on the core competency -- which should be your product, not your commodity infrastructure.

I have yet to see any significant AWS deployment that doesn't feel like it could be done better, more reliably, and much more cheaply as a co-located setup.

That's a stretch. Especially the "cheaply" part. The operational costs involved in building and maintaining a significant co-located deployment are huge, not to mention the capital expenditure involved in enterprise networking hardware, servers, cages, racks, PDUs, etc.

I don't firmly fall on either side of the debate -- one must balance the requirements and costs, like anything else.

However, I do firmly believe that we should have programmers automating the entire software system administration job away, leaving only the question of hardware provisioning. That's why we have "devops" style teams nowdays, and I only expect that trend to grow.

Re: Why Stack Exchange Isn’t in the Cloud

#79

Earlier quoted context omitted.

You conveniently left out the first part of the quoted sentence, "allow programmers to actually program infrastructure". Almost everything you wrote can be programmed these days without a "traditional" sysadmin.

That is what good sysadmins do, and rack monkeys are training to do.

Sure. But often they don't have the programming background to do it cleanly.

Re: Why Stack Exchange Isn’t in the Cloud

#80
post #74
post #70

Earlier quoted context omitted.

Saying that you can't get IOPS on AWS is like saying that your machinegun sucks at grating cheese. It's really not meant to do that. But that's fine as AWS isn't the only cloud platform out there, and some are actually desgined to take data intensive workloads.

The problem is that it's touted as a great way to scale web apps. Since DB performance is usually the limiting factor in webapp scaling, this doesn't appear to stack up. Needing a lot of IOPS is pretty par for the course.

Exactly. And it's not like it's a good idea to put your DB in an IOPs enhanced cloud, and your applications in another.
Post reply on HN