Live data from Hacker News

Why the data center needs an operating system

radar.oreilly.com

21–30 of 102 posts

Re: Why the data center needs an operating system

#21

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…

While I take your point, "local" is a leaky concept inside a data-center. On a fast network, "in cache on the neighboring computer" can be closer than "on my hard drive" for most purposes.

It seems like what might be ideal would be a specification language that doesn't care where things are, an implementation that tries to deal with that automagically, and a way to specify portions (to all) precisely that is checked against the high-level specification.

Re: Why the data center needs an operating system

#22
post #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"

The Programming API layer is fragmented in the UNIX world. There's mostly only ANSI C, X, and gcc, which exist everywhere, but it's still not trivial to port between *NIX. The kernel API is the most useless fragmentation of them all. It's addressed by POSIX and UDI (http://www.project-udi.org/), but the differences between the most important UNIX kernels don't justify the problems they make.

Re: Why the data center needs an operating system

#23

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…

While I take your point, "local" is a leaky concept inside a data-center. On a fast network, "in cache on the neighboring computer" can be closer than "on my hard drive" for most purposes. It seems like what might be ideal would be a specification language that doesn't care where things are, an implementation that tries to deal with that automagically, and a way to specify portions (to all) precisely that is checked…

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.

Re: Why the data center needs an operating system

#24

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…

One thing worth noting is that the indirection Ben describes is, basically, the indirection that is already in the Apache Mesos kernel. In real world environments (e.g., Twitter), there is negligible overhead.

Also, locality and latency can both be expressed in terms of placement rules and schedulers on Mesos can use those rules to guarantee or express preference for task placement that optimizes around reduced latencies.

The point that I take away is that the ability to express your needs in a declarative way (e.g., "place these two tasks such that they have such-and-such latency) is much more scalable, flexible and resilient than coding to machine-specific internals. The latter is easier to update and supports delegation of responsibilities.

John Wilkes of Google puts it this way:

"Our own experience has been that allowing our developers unfettered access to the internals of infrastructure systems has been a problem, and we're moving away from that model as fast as we can.

Constructing large-scale complex systems with many interdependencies leads to brittle, fragile systems if they rely on internal implementation mechanisms.

Allowing internal customers to rely on internal implementation mechanisms has made it hard to adopt new technologies, because we only know what knobs they set - not why.

The fix for both is similar: describe the desired end state, not how to get there."

Re: Why the data center needs an operating system

#25
post #4

The dataceneter == the new form factor

What makes you say that?

Datacenter and back-end apps simply don't fit on a single machine anymore. Every app of reasonable scale is probably a distributed system of some sort. That, and there are a new class of "apps" (or, more precisely, datacenter services) that were built to operate across fleets of machines from day one, such as Spark, Hadoop, Cassandra, Kafka, Elasticsearch, and so on

Re: Why the data center needs an operating system

#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 things like hadoop and so the idea of leveraging a datacenter level API is hard to fathom. I believe it's still going to be a while before this truly becomes mainstream and really we'll see the historical two level forward shift whereby on one side we've previously achieved compute as a service with EC2 and GCE, while developing platform as a service on the other side with Google App Engine and Heroku. These service different demographics and we'll continue to see the level of abstractions occur providing SREs/Devops engineers access to Cluster As A Service and microservice platforms for developers/programmers to give them more flexibility.

Google SREs by last count were 1 engineer to 1000 machines. In 10 years the common devops engineer at a 200 person startup will leverage the same number of resources using layers of abstraction like Mesos and Kubernetes.

Re: Why the data center needs an operating system

#27
post #5

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

Mesos runs quite nicely on CoreOS. Mesos doesn't replace the native Linux on each of the boxes in the datacenter. The Linux on each box provides the execution environment.

Here is a short tutorial for standing up Mesos on a single CoreOS instance: https://mesosphere.com/docs/tutorials/mesosphere-on-a-single...

Re: Why the data center needs an operating system

#28
post #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"

The Programming API layer is fragmented in the UNIX world. There's mostly only ANSI C, X, and gcc, which exist everywhere, but it's still not trivial to port between *NIX. The kernel API is the most useless fragmentation of them all. It's addressed by POSIX and UDI ( http://www.project-udi.org/ ), but the differences between the most important UNIX kernels don't justify the problems they make.

Oh, we're completely cross-platform these days! That means it runs on both RHEL and Ubuntu.

Re: Why the data center needs an operating system

#29

In light of all the excitement around Docker & containers, it's important to note that Mesos has been using cgroups / LXC (for isolation) since its inception. Mesos paper: http://people.csail.mit.edu/matei/papers/2011/nsdi_mesos.pdf

It also supports Docker as of recently.

Re: Why the data center needs an operating system

#30

Earlier quoted context omitted.

The Programming API layer is fragmented in the UNIX world. There's mostly only ANSI C, X, and gcc, which exist everywhere, but it's still not trivial to port between *NIX. The kernel API is the most useless fragmentation of them all. It's addressed by POSIX and UDI ( http://www.project-udi.org/ ), but the differences between the most important UNIX kernels don't justify the problems they make.

Oh, we're completely cross-platform these days! That means it runs on both RHEL and Ubuntu.

ha ha ha
Post reply on HN