This sounds like the problem Plan 9 set out to solve
Why the data center needs an operating system
41–50 of 102 posts
Re: Why the data center needs an operating system
#42In my mind when I think of abstractions above the level of individual machines, I pretty much automatically go to Erlang as the only language that I know of that operates at the right level of abstraction for that.
It's the only (semi-mainstream?) language that I know of that includes the infrastructure in the language itself to make the individual underlying machines (OS / hardware) appear irrelevant and allow programming to seamlessly span a group of computers.
Re: Why the data center needs an operating system
#43This 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 this is definitely true. Most unix programs are not portable to POSIX, even when they don't intentionally use features that aren't in POSIX (e.g. kqueue).
UNIX API fragmentation is still a problem, but my point is that POSIX was trying to unify existing implementations rather than a greenfields project to generate a set of portable APIs.
Re: Why the data center needs an operating system
#44Combined with rump kernels I can see this as a the data center of the future.. simply a micro-kernel running a specific application without the bloat of a full OS while an orchestration unit/OS such as Mesos does all the setup and tear down of such services providing resources on demand.. lovely.
Re: Why the data center needs an operating system
#45Yes, 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…
To further your point, you can get faster access directly via RDMA on an Infiniband network than the SATA bus can push data. The fastest SATA busses are around 16gbps I believe and you can get HDR IB switches that clock 50gbps today.
With the direction things are moving, "the data center as a computer" is absolutely the right approach.
Re: Why the data center needs an operating system
#46Mesos is just one piece of the puzzle. I think the Hadoop project proper will be the first to get there. Maybe v3 or v4. That said, given the diversity under the Hadoop umbrela I expect distribution to appear, like RHEL is a GNU/Linux OS there might be a (Cloudera ?) Hadoop OS.
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.
Re: Why the data center needs an operating system
#47It'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.
Re: Why the data center needs an operating system
#48This sounds like the problem Plan 9 set out to solve
I was hoping I would see someone mention Plan 9 here. Solving that problem does indeed seem like what their goal was.
"The early catch phrase was to build a UNIX out of a lot of little systems, not a system out of a lot of little UNIXes."
Re: Why the data center needs an operating system
#49One way to think about this problem is to look at components that people thought were useful in an operating system and then think about what a distributed version might look like.
E.g. for an OS we have:
filesystem
scheduler
cron
Then you can go look at the history of these primitives so the same lessons don't have to be relearned. For example, the Linux kernel has gone through many iterations of its scheduler with cgroups, cfs etc. Why did they do that? Why were previous incarnations not good enough? etc.
Re: Why the data center needs an operating system
#50Earlier 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.
[deleted]