Live data from Hacker News

Why Stack Exchange Isn’t in the Cloud

blog.serverfault.com

61–70 of 85 posts

Re: Why Stack Exchange Isn’t in the Cloud

#61
post #59
post #58

Earlier quoted context omitted.

>>* All Amazon does is provide the hardware and network infrastructure to run on. It is not a magic bullet that says I don't need to have these people around*. Even in this case, I would still like to excuse my self of the headache dealing with real estate, electricity, air conditioning etc. In other words supporting factors required to keep the data center up and running. Unless you are going to need ridiculous amou…

This comment doesn't make any sense. Companies who need to build their own data-center aren't going to get by on Heroku. For everyone else there's co-location, where you don't worry about those things anyways. Unless you have a just terrible facility I guess. I mean sure, one time in the past three years I've complained to our colo folks that it seemed warmer than it should be while one of the A/C units was being ser…

Actually I was replying to the parent comment:

>>Call me insane because I sure do love spending time in a datacenter, it's one of the few times working in IT you really get to do something with your hands, and that does have a certain appleal to me.

We are both saying the same thing. You need to draw a line between "fun" and how much feasible it is to afford that fun. Most people don't need a data center, but still want it.

All passion and fun talk aside. Sometime you need to look at it very pragmatically. That was my point.

Re: Why Stack Exchange Isn’t in the Cloud

#62

What a silly argument. "If you just want to use someone else’s computers, it means you don’t love computers — at least not every aspect to them." Uh, don't they use Dell? If they love them so much, why not build their own? Why stop there? I love software and programming languages, but it doesn't mean I'm going to use my own compiler or run a company on my own libc.

There is always the question of degree and practicality. So in terms of libc / and custom compilers that is perhaps ad absurdum. There really wouldn't be any practical benefit taking it to that far for most companies. However, people that love programming languages often probably wish it was practical and that they had an excuse to write compilers at some point. As far as Dell goes, I honestly have mixed feelings at…

> So in terms of libc / and custom compilers that is perhaps ad absurdum.

Not totally silly, Apple has been doing sort of the same thing with clang/llvm.

Re: Why Stack Exchange Isn’t in the Cloud

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

You can't really create a massive co-located setup on demand for big jobs, then tear it down ... use the right tools for whatever job you're doing. EC2 being more expensive for your Postgres deploy doesn't mean it is an expensive toy

Re: Why Stack Exchange Isn’t in the Cloud

#64
post #2

So for cultural reasons? Is it not perhaps because there's much less competition for .NET stack cloud platforms, therefore less quality?

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

Re: Why Stack Exchange Isn’t in the Cloud

#65
post #36

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…

In what way does fsync work differently in the cloud?

Because there's an extra virtual layer between you and the hard-disk, fsync() does not do what it says it does, which means that a database cannot actually guarantee that a transaction was successfully completed.

In case your traffic is huge, this can cause big problems that are very hard to fix. And it did cause problems for Reddit, as EBS is notoriously awful in this regard (and others, like big latencies on access).

Basically when working at big scales, nothing beats having complete control over your infrastructure. It may be tough and time consuming, but at least you can identify the problem and fix it.

It is my opinion that something like Google's search cannot be built on top of Amazon's AWS.

Re: Why Stack Exchange Isn’t in the Cloud

#66
post #41
post #36

Earlier quoted context omitted.

In what way does fsync work differently in the cloud?

In the way that you have no idea whether fsync actually writes the data to disk, or whether it puts it in memory somewhere (usually a write cache).

Most modern hard drives don't actually do what most people expect an fsync does anyway. This is an interesting thread about Apple's F_FULLFSYNC ioctl that discusses the problem (this pat is by Apple FS engineer Dominic Giampaolo): http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072...

Re: Why Stack Exchange Isn’t in the Cloud

#67
I'm growing to understand "the cloud" not as AWS/Rackspace/Heroku/whatever, but as a mindset where: 1) you're not tied to hardware 2) your application scales horizontally 3) you can easily (and dynamically) add (computational) resources as needed, preferrably managed by your application. 4) you build fault tolerance and redundancy into your application

This article basically takes the approach that "the cloud" is AWS.

Re: Why Stack Exchange Isn’t in the Cloud

#68

Poorly written argument full of red herrings. From what I can tell, their answer to the "why aren't you in the cloud" question is that they "love computers so much that they want to do it all themselves because it's so fun".

It's very similar to the argument that Jeff Atwood gave a while back that "If it's a core business function -- do it yourself, no matter what" ( http://www.codinghorror.com/blog/2008/10/programming-is-hard... )

And taken on those terms - not on the cost accounting of cloud vs local - it makes sense to me. Is it a convincing "no matter what" argument against cloud hosting in all cases? I'd say no - there will be cases where sheer scale or fluctuations in scale make cloud hosting more attractive. as the article admits.

Re: Why Stack Exchange Isn’t in the Cloud

#69
post #36

Earlier quoted context omitted.

In what way does fsync work differently in the cloud?

Because there's an extra virtual layer between you and the hard-disk, fsync() does not do what it says it does, which means that a database cannot actually guarantee that a transaction was successfully completed. In case your traffic is huge, this can cause big problems that are very hard to fix. And it did cause problems for Reddit, as EBS is notoriously awful in this regard (and others, like big latencies on access…

Saying that because fsync() doesn't work in AWS that it won't work 'in the cloud' is much like saying that because you can't take a cheap sedan to the bush that a 4wd can't possibly exist.

Google can't exist (well) on top of AWS as AWS is designed for the deployment of (qusi)stateless applications. Saying that you can't build a data intensive application on top of it is like saying that your machinegun sucks at grating cheese.

OVM was designed to run a search engine origionally (darkmatr, now defunct due to lack of comparitive profitability), so you could quite easily build google on top of it. It wouldn't surprise me if google would work really well on top of that stack.

Re: Why Stack Exchange Isn’t in the Cloud

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

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.

Post reply on HN