Live data from Hacker News

Google Open-Sourced Kubernetes to Boost Its Cloud

wired.com

21–30 of 36 posts

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#21
post #13

Is it me or does anyone else interprets all the recent wave of open sourcing as a trend to not create open standards anymore, but instead open source the technology altogether (without even creating the standard). Have standards failed ?

This is a very good debate regarding this very topic: https://www.youtube.com/watch?v=kRVWjC6osuw

TLDR: we are in a stage where we don't know yet what functionality needs to be supported, it is not a good time to form standards, it is a time for checking possibilities and finding best technical solutions.

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#22
post #13

Is it me or does anyone else interprets all the recent wave of open sourcing as a trend to not create open standards anymore, but instead open source the technology altogether (without even creating the standard). Have standards failed ?

My 2c, not speaking as a Google rep but as myself, is that if you have a problem only a single actor needs to solve, you're going to end up with software, not a standard. To get a standard, you have to have a situation where the value of cooperation is higher than the cost.

There are plenty of people now who need to solve the container problem, but Googlers been working on this shit for years, before it was really on anyone else's horizon. Google employees incepted the cgroup feature way back in 2006, to solve problems that were already being felt acutely at that time within Google. Folks have been working on this stuff a long time before it mattered to anyone else, and that's why what's coming out is software rather than standards. There is no way a big company is going to delay solutions to an urgent strategic problem in order to be part of a democratic process for the sake of a few people's ideals. Maybe if they'd seen it coming five or ten years in advance, to give enough time for the standardization process to occur, but Google was far too small and the future far too uncertain in 2001 to predict what might be needed in 2006.

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#23
post #13

Is it me or does anyone else interprets all the recent wave of open sourcing as a trend to not create open standards anymore, but instead open source the technology altogether (without even creating the standard). Have standards failed ?

This is an interesting question. Really, open source and standardization are not competitors. Ideally you'd have both at once; multiple open-source implementations of a standard specification.

That said, there are times when the business model behind an open-source project is ostensibly at odds with standardization. The situation between Docker and CoreOS' app container spec comes to mind. The Docker container spec was defined by the implementation, not the other way around, and CoreOS took that opportunity to define an actual spec (and an implementation). Heated debates erupted.

In the area of cloud orchestration which Kubernetes seems to fill, I think it's still in a "discovery" stage. Early on the Kuberbetes devs said they wanted to focus first on identifying the right abstractions. I imagine standardized specs might come out of it once things stabilize.

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#24
Kubernetes is alpha software right now. I was at a meet up last month and there are a lot of missing features from what I recall. They're planning to fix one of these feature with some project call Ubernetes.

While people are raving about containers, there are still security issues with containers no?

I think VM will be here to stay for a long while and while we might have to pay a performance and memory hit for them, they offer better isolation.

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#25

Kubernetes is alpha software right now. I was at a meet up last month and there are a lot of missing features from what I recall. They're planning to fix one of these feature with some project call Ubernetes. While people are raving about containers, there are still security issues with containers no? I think VM will be here to stay for a long while and while we might have to pay a performance and memory hit for them…

> there are still security issues with containers no?

In Linux, perhaps. However FreeBSD jails and illumos zones are rock-solid. There's this crazy hype around containers these days and people just ignore the stable, secure, and tried technology, I don't understand it at all!

FreeBSD and illumos are not Linux, but their still Unix-like, it's not like you'd have to use OpenVMS. Plus you'd get other benefits too, like DTrace and ZFS. And on illumos now you can even run Linux binaries in a zone.

So why do people simply pretend these secure technologies don't exist? Can someone explain?

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#26
post #13

Is it me or does anyone else interprets all the recent wave of open sourcing as a trend to not create open standards anymore, but instead open source the technology altogether (without even creating the standard). Have standards failed ?

My 2c, not speaking as a Google rep but as myself, is that if you have a problem only a single actor needs to solve, you're going to end up with software, not a standard. To get a standard, you have to have a situation where the value of cooperation is higher than the cost. There are plenty of people now who need to solve the container problem, but Googlers been working on this shit for years, before it was really on…

Almost every problem that containers solved, was solved with EclipseBSD http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8... way back in 1998

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#27

Kubernetes is alpha software right now. I was at a meet up last month and there are a lot of missing features from what I recall. They're planning to fix one of these feature with some project call Ubernetes. While people are raving about containers, there are still security issues with containers no? I think VM will be here to stay for a long while and while we might have to pay a performance and memory hit for them…

While I have no doubt someone will pop-out with some wild example of how docker lowers your security bar, wrapping your application in a container shouldn't really hurt you. In fact, adding the need to escape a container should really add a net benefit to security, but it's what happens next what is the concern.

So you've removed a major barrier of deploying more than one app per server. You no longer need to worry about dependancy hell and you've made moving services around super easy. You decide you can save a crap ton of money by sharing resources; this is where the problem lies. If you run multiple app on the same server without a container layer, you'll still have the same app isolation concerns, only attackers now don't have a container to escape from, and you might have dependancy problems.

So the point is, you can't rely on docker isolation instead of vm's from a security pov, but if you stick with using a single docker per VM, you'll still have the deployment benefits such as the ability to create idempotent binaries and deploy these. This is, in my opinion, an improvement over trying to reproduce builds on different platforms or scp'ing your builds hoping all the required packers are in your vendor, etc. Maybe not a big deal if you're deploying go, but a really nice thing when working with php, ruby, python, etc.

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#28
post #25

Kubernetes is alpha software right now. I was at a meet up last month and there are a lot of missing features from what I recall. They're planning to fix one of these feature with some project call Ubernetes. While people are raving about containers, there are still security issues with containers no? I think VM will be here to stay for a long while and while we might have to pay a performance and memory hit for them…

> there are still security issues with containers no? In Linux, perhaps. However FreeBSD jails and illumos zones are rock-solid. There's this crazy hype around containers these days and people just ignore the stable, secure, and tried technology, I don't understand it at all! FreeBSD and illumos are not Linux, but their still Unix-like, it's not like you'd have to use OpenVMS. Plus you'd get other benefits too, like…

Because there are lot more Linux users / developers than BSD.

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#29
post #25

Earlier quoted context omitted.

> there are still security issues with containers no? In Linux, perhaps. However FreeBSD jails and illumos zones are rock-solid. There's this crazy hype around containers these days and people just ignore the stable, secure, and tried technology, I don't understand it at all! FreeBSD and illumos are not Linux, but their still Unix-like, it's not like you'd have to use OpenVMS. Plus you'd get other benefits too, like…

Because there are lot more Linux users / developers than BSD.

I don't think that "X has more users than Y" is a valid complete argument in itself, otherwise nothing would ever change. Of course it matters in the grand scheme of things, but the causal relationship is more complex, involves many degrees of freedom and goes both ways.

Before docker came, Linux had LXC, which wasn't as popular as docker is now, but it was certainly known and used by people. So when docker came, LXC had more users than docker, and yet docker surpassed LXC in popularity in weeks, so the "X has more users than Y" state can be changed by various factors and it's not enough to keep the system in equilibrium.

So yes, the fact that Linux is more widely used than FreeBSD and illumos in the developer community is certainly an important factor, but I don't see anyone ever saying "FreeBSD is great but we want to use something supported by a larger community", or "illumos is great, but we don't have expertise with it", which are certainly important arguments to consider when making a decision.

But I hardly see anyone making these arguments, or any other arguments really. It's like these systems don't even exist. At first I attributed this to the "X has more users than Y" factor, but then I see people having particular problems with Linux container technology, in areas such as security, virtual networking, etc. And these are problems already solved by FreeBSD and illumos. Surely when you have a problem you look for alternative solutions that don't have these problems?

But I don't see people looking over the alternatives at all. As I said, there are many valid reasons not to use these other technologies, but I am very perplexed that people refuse to even acknowledge the existence of them.

And now that illumos can run Linux inside a zone (and FreeBSD did this too 15 years ago, and still does for 32-bit binaries, I believe work is well underway to extend this to 64-bit as well), I think the "I only know Linux" argument loses some potency, you can run Linux after all...

Re: Google Open-Sourced Kubernetes to Boost Its Cloud

#30
post #25

Kubernetes is alpha software right now. I was at a meet up last month and there are a lot of missing features from what I recall. They're planning to fix one of these feature with some project call Ubernetes. While people are raving about containers, there are still security issues with containers no? I think VM will be here to stay for a long while and while we might have to pay a performance and memory hit for them…

> there are still security issues with containers no? In Linux, perhaps. However FreeBSD jails and illumos zones are rock-solid. There's this crazy hype around containers these days and people just ignore the stable, secure, and tried technology, I don't understand it at all! FreeBSD and illumos are not Linux, but their still Unix-like, it's not like you'd have to use OpenVMS. Plus you'd get other benefits too, like…

> In Linux, perhaps.

If you generalise from Docker. There are other container models on Linux -- LXC, lmctfy, Rocket, Garden etc have different security tradeoffs.

Post reply on HN