Live data from Hacker News

Why the data center needs an operating system

radar.oreilly.com

11–20 of 102 posts

Re: Why the data center needs an operating system

#11
post #7

The thing I like about Mesos is that when you approach your problem you are planning for High Availability from the beginning. You don't get that with Docker. Docker let's you make your provisioning stable and repeatable, but you don't get any advantage on HA. You are on your own with Docker. But, Mesos guides the whole architecture of your app towards HA which is nice.

Docker aids software deployment through the automation of Linux Containers (LXC). While Docker has made the the life of developers and operators easier, Docker plus Mesosphere provides an easy way to automate and scale deployment of containers in a production environment.

Re: Why the data center needs an operating system

#12
So true; think about what multi-tasking and virtual memory have done for developer convenience _and_ system performance over the last decades. Bet we are going to see the same effects in this space too - there are so many interesting things to do in scheduling! Especially when you can distinguish between clever placement of long lived tasks vs fitting short-lived low-latency jobs.

On another note; next up: "data center_s_ need an operating system". Very interested to see the move towards multi DC/availability zones.

Re: Why the data center needs an operating system

#14
post #5

isn't this what all the hype behind CoreOS is about?

CoreOS is still restricted to one machine. It's about installing one operating system, which will run on multiple machines. With CoreOS you have X number of machines, running CoreOS, and Y number of applications running on top, with the CoreOS installations coordinating.

I think the point of the article is to have one operating system, running multiple physical boxes. You could then in turn have something like containers running on top of that OS.

Re: Why the data center needs an operating system

#17
This author talks about POSIX as if a bunch of people sat down and invented a portable OS API. The reality is closer to: a group of people at AT&T created Unix, a number of other companies and universities modified Unix, and then people sat down and said "how can we unify the APIs of the fragmented Unix world"

Re: Why the data center needs an operating system

#18
Yes, we need new, standardizing APIs. However this made me cringe:

> Exposing machines as the abstraction to developers unnecessarily complicates the engineering, causing developers to build software constrained by machine-specific characteristics, like IP addresses and local storage.

It reminded me of the old RPC approach of making potentially any method call a remote method call. It didn't work out, simply because remote call latencies are orders of magnitudes higher than for in-process calls, so you need different (coarser) APIs for them.

By the same token, while abstractions are very welcome, they should still allow distinctions between local and non-local resources, for various definitions of "local".

Re: Why the data center needs an operating system

#19

Earlier quoted context omitted.

What makes you say that?

Distributed computing is now the norm, not the exception, and we need a data center operating system that delivers a layer of abstraction and a portable API for distributed applications.

And then we'll need an OS for handling multiple data centers. Its gonna be a crazy day the first time someone realizes they accidentally rebooted 5% of all servers in the western hemisphere.

Re: Why the data center needs an operating system

#20

In 2005 I saw a demo of this product from VirtualIron called VFe, which did this on a smaller scale (maybe 10 servers) -- it looked amazing. https://www.kernel.org/doc/ols/2005/ols2005v2-pages-243-258....

Mosix, Virtual Iron, vNUMA, ScaleMP, etc. are variants of the RPC fallacy: making remote/slow/independent things pretend to be local/fast/fate-shared. http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf Successful distributed software tends to go the opposite direction, making asynchrony and unreliability the base case.
Post reply on HN