Live data from Hacker News

Why the data center needs an operating system

radar.oreilly.com

81–90 of 102 posts

Re: Why the data center needs an operating system

#81
post #58

The article's premise is a poor introduction to the project. Sure, reinvent MOSIX if you want :) but don't pretend it'll serve more than a niche of a niche. Firstly, "distributed computing is the norm"? It's just not. Most businesses & app authors will never need to care about ultra-distributed computing, with all its problems and trade-offs. You can move faster with "local-only" computing and scale vertically very c…

We get Stacked Memory HMC soon, Its not hard to envision a 2U server with ultra high speed 1TB+ Memory in 2020. At 10nm, 2U Server would get a Dual 32 Core Xeon. Everyone would do In Memory database and computing, most of today's scaling problem would be 10x easier then. It would properly take a lot longer to reach the scale problem Google and Twitter once had.

So i dont see distributed computing become the norm either. At least not in the next few years.

Re: Why the data center needs an operating system

#82
post #26

It's interesting and great to see this stuff take center stage more and more. Those lucky enough to work at places like Twitter, Google, Facebook and other large tech companies will have already seen how this kind of thing dominates the datacenter's there and has been at the core of their systems for many years. People on the outside though are rarely exposed to this concept of datacenter scale computing aside from t…

> Google SREs by last count were 1 engineer to 1000 machines That number does not seem particularly impressive, if it is accurate. Even "traditional" well-run enterprise IT organizations are often in the 1 admin/SRE to 600-ish machines, so I have a hard time seeing that Google can only do ~2x as good at their scale and with their level of focus. 1 SRE to 5k machines, 10k machines, that makes more sense to me.

And goggle dont have to woory about the hard stuf in the same way that full on IBM sysplex thats running 20% of a coutrys bank acounts does. RBS COUGH COUGH

Re: Why the data center needs an operating system

#83
post #64
post #46

Earlier quoted context omitted.

I wouldn't be betting my marbles on Hadoop, or anything Map Reduce now adays. Spark beats it pretty handily for data processing although HBase isn't too bad.

With YARN, Hadoop has built a more generic scheduler comparable to Mesos. https://www.quora.com/How-does-YARN-compare-to-Mesos

Not sure about that (haven't used yarn however), YARN seems extremely Hadoop specific, whereas Mesos is a "closer to the metal" generic framework to build frameworks for scheduling things on.

If I was to compare the two, I'd call YARN an application scheduler and Mesos a more meta scheduler. You could build yarn ontop of Mesos. You likely couldn't easily build Mesos ontop of Yarn. It should be relatively trivial to make a YARN Framework, which someone has already done with Mesos:

https://github.com/mesos/myriad

Re: Why the data center needs an operating system

#84

Earlier quoted context omitted.

Absolutely. In-core on a neighboring machine can be accessed in less than 1ms. On-disk on the local machine (or any machine) can take tens of seconds.

"On-disk on the local machine (or any machine) can take tens of seconds" Surely you meant 10's of milli seconds. But even so, fastest SSD random access latencies are in sub-millisecond ranges.

No I did not mean that. Contended local disk access under heavy random read/write workloads takes essentially forever.

Re: Why the data center needs an operating system

#85
post #56

Earlier quoted context omitted.

Actually C disallows converting function pointers to/from void pointers.

Can you get away with that in pre-ANSI C? I wouldn't be surprised.

for pre-ANSI C most of these questions are answered by "it depends on the compiler" which is why ANSI C happened. Of course the answer is still "it depends on the compiler" for this behavior, since it's not defined what it does in ANSI C, just that it's not portable to do it.

Re: Why the data center needs an operating system

#86

Earlier quoted context omitted.

> Google SREs by last count were 1 engineer to 1000 machines That number does not seem particularly impressive, if it is accurate. Even "traditional" well-run enterprise IT organizations are often in the 1 admin/SRE to 600-ish machines, so I have a hard time seeing that Google can only do ~2x as good at their scale and with their level of focus. 1 SRE to 5k machines, 10k machines, that makes more sense to me.

I don't know which kinds of enterprise orgs you're envisioning but when I think about "traditional" enterprise IT orgs, I'm picturing companies in healthcare, insurance, certain finance business units, non-profits, public sector, and defense, not any place ever mentioned a lot here on HN in a technical discussion. I've worked with a LOT of them and I'd be surprised if the ratio of ops engineers to servers was anythin…

I think part of the difference is due to the fact that the business of administering healthcare, insurance, financials and other businesses are infinitely more complex than say, serving up search results or 140 character micro blog posts.

It seems much easier in my opinion to scale a single function (search or tweet) than the kinds of tasks that a healthcare company has to do like say...scanning faxes from doctors, applying OCR and properly placing them into a pharmacy order system.

Re: Why the data center needs an operating system

#87
post #85

Earlier quoted context omitted.

Can you get away with that in pre-ANSI C? I wouldn't be surprised.

for pre-ANSI C most of these questions are answered by "it depends on the compiler" which is why ANSI C happened. Of course the answer is still "it depends on the compiler" for this behavior, since it's not defined what it does in ANSI C, just that it's not portable to do it.

I remember working on a Fujitsu box in 1993, which used some sort of weird System V Unix with pre-ANSI C and weirdly abbreviated man pages in Engrish. (shudder) Yeah.

Re: Why the data center needs an operating system

#88
post #83
post #64

Earlier quoted context omitted.

With YARN, Hadoop has built a more generic scheduler comparable to Mesos. https://www.quora.com/How-does-YARN-compare-to-Mesos

Not sure about that (haven't used yarn however), YARN seems extremely Hadoop specific, whereas Mesos is a "closer to the metal" generic framework to build frameworks for scheduling things on. If I was to compare the two, I'd call YARN an application scheduler and Mesos a more meta scheduler. You could build yarn ontop of Mesos. You likely couldn't easily build Mesos ontop of Yarn. It should be relatively trivial to m…

True but Hadoop is the whole tooling and with YARN they are distancing themselves from Map/Reduce. IMHO, it looks like they are heading in that right direction but not quite there. That why it maybe v4 before we can think of Hadoop as an OS for datacenter.

Mesos is closer to the metal but still is only a piece of what is needed. Picturing it as an OS is misleading while picturing Hadoop V2 as a proto-OS is not that much in accurate.

Re: Why the data center needs an operating system

#89
post #32

I definitely wouldn't consider Mesos to be anything like an operating system for the datacenter. That's just marketing language and confuses things. Mesos is basically an application scheduler. It doesn't manage the base operating systems or machine provisioning. Mesos is concerned with ensuring that one or multiple applications are launched and running on a cluster of machines. The Saltstack framework is the only th…

Mesos itself doesn't do scheduling - it merely does allocation and allows applications built on top of it to schedule to workload.

s/Mesos/Marathon and the comment still stands.

Re: Why the data center needs an operating system

#90

Earlier quoted context omitted.

Mesos itself doesn't do scheduling - it merely does allocation and allows applications built on top of it to schedule to workload.

s/Mesos/Marathon and the comment still stands.

Well that changes everything b/c Marathon is just a piece of the puzzle. This turns the statement into "init.d isn't an operating system".
Post reply on HN