Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Eric Brewer

medium.com

Post reply on HN
Print view View original

21–30 of 142 posts

Re: Interview with Eric Brewer

#21

Post by contingencies »

jacquesm wrote: post #9
MCRed wrote: post #5

I'd like a real explanation for why containers are better than unikernels. Yes, unikernals are still early, and containers are convenient, because you have all of linux there... but it seems that running several linuxes on a linux machine is a bit much. One operating system plus XEN plus several applications in unikernels seems more efficient, and more exciting. But it's the less common choice. I am guessing convenie…

I'd like a real explanation for why containers and unikernels are better than regular run-of-the-mill applications running on dedicated servers. It's almost as if the wild west of the web isn't quite enough and we now need to add another explosion of layers-of-abstraction but this time on the server in order to pretend we have infinite hardware which then becomes it's own reason for existence rather than to simply ru…

Your questions are valid, and you are correct that one size does not fit all. Frankly, the Google use case ('run lots and lots of as-yet-unwritten stuff on lots and lots of identicalish infrastructure') demands thie style of automation, but sacrifices other aspects of the final solution. This is a close use case to public cloud computing providers. However, in many cases (performance, security, etc.) it is not the most desirable model. This dichotomy is in my view one of the key points being overlooked by the dual champions of containerization, docker (non-profitable silly-valley hypetrain for LXC) and kubernetes (rethink of Google's internal container utilization seemingly in response to docker and EC2).

Re: Interview with Eric Brewer

#22

Post by contingencies »

jacquesm wrote: post #19
mixmastamyk wrote: post #11

Earlier quoted context omitted.

See the shipping container analogy on why containers are so powerful and less work in the long run.

Software is very much unlike anything physical.

Its kind of like ice cream in that it looks beautiful when acquired but once you have it in your hands it tends to melt in to an unrecognizable puddle of sticky shit really quickly.

Re: Interview with Eric Brewer

#24

Post by mixmastamyk »

jacquesm wrote: post #18
DannoHung wrote: post #10

Earlier quoted context omitted.

Sorry, but what costs do containers incur? From my understanding, the resource overhead should be exceedingly minimal (disk space would ostensibly be the largest drawback, if you don't spend time cutting out the fat. Personally, I see this as a tooling issue since fat containers are completely orthogonal to how a container really executes). I understand some of the situation with IO isn't perfect yet, but I haven't h…

An OS has some pretty extensive insight into the processes that it executes, a container is an OS with a single application, so containers (assuming they take basic precautions for isolation) are not going to be able to schedule with anywhere near the efficiency that multiple processes on a single OS will. I can see some (mostly potential at this point) security advantages but that's about it (and maybe those advanta…

The linux kernel knows what is happening in the containers. There is little performance overhead, and security is not a big advantage of the approach, VMs are better.

Re: Interview with Eric Brewer

#25

Post by mixmastamyk »

DannoHung wrote: post #20
jacquesm wrote: post #18

Earlier quoted context omitted.

An OS has some pretty extensive insight into the processes that it executes, a container is an OS with a single application, so containers (assuming they take basic precautions for isolation) are not going to be able to schedule with anywhere near the efficiency that multiple processes on a single OS will. I can see some (mostly potential at this point) security advantages but that's about it (and maybe those advanta…

Do you know where I can read more about this? This is the first I have heard that processes running inside containers interfere with the kernel's scheduler. Or, sorry again, but maybe I'm not following your meaning in some way?

It's not true, so I wouldn't bother looking too hard. ;)

The linux kernel does not "lose track" of processes/libs inside containers, they are simply namespaced, like a more extensive chroot environment.

Re: Interview with Eric Brewer

#26

Post by mark_l_watson »

philip1209 wrote: post #14
mark_l_watson wrote: post #7

Great Interview! I worked as a contractor at Google in 2013 and loved their infrastructure. It was amazing to fire off a Borg job that used hundreds to thousands of servers, and the web based tools for tracking the job, fantastic logging to drill into problems, etc. And, Borg was two generations ago! Even though I am very happy doing what I am now, sometimes I literally wake up in the morning thinking about Google's…

How hard was it to learn these tools as a contractor? I hear that Google is more aggressively making their tools open-source to help the portability of their engineers' skills. Specifically, friends have told me that onboarding at Google is difficult because every tool is a proprietary one built on top of more proprietary systems. In addition, people who leave Google have trouble interviewing because they rely heavil…

Good question. I found onboarding at Google really fun and interesting. I took several great classes, the best being the end-to-end class that in 8 hours let you write code that used most of Google's infrastructure - that class was so awesome that I would have payed Google for that day at work :-)

Also, they had code labs that are self paced modules for learning specific tech. I didn't spend much time at work doing code labs, but I could access them at home with my corporate laptop and I went through about a dozen of them at home. One other nice thing is even mentioning that you couldn't figure out something from the documentation or code labs would cause someone to jump in to help you.

Also, I don't think that people leaving Google have problems getting other jobs :-) The retention rate at Google is surprising low, given the pleasant atmosphere there. People leave to go elsewhere, start their own companies, etc. I was 63 when I worked there, and although it was probably not the most awesome place I worked, it was really great.

Apply for a job if you are interested, or go the easier route and get a contractor position.

Re: Interview with Eric Brewer

#27

Post by jacquesm »

DannoHung wrote: post #20
jacquesm wrote: post #18

Earlier quoted context omitted.

An OS has some pretty extensive insight into the processes that it executes, a container is an OS with a single application, so containers (assuming they take basic precautions for isolation) are not going to be able to schedule with anywhere near the efficiency that multiple processes on a single OS will. I can see some (mostly potential at this point) security advantages but that's about it (and maybe those advanta…

Do you know where I can read more about this? This is the first I have heard that processes running inside containers interfere with the kernel's scheduler. Or, sorry again, but maybe I'm not following your meaning in some way?

Each 'container' is in effect an application plus all its dependencies.

So if one or more active containers could share resources then they won't, which leads to inefficiencies because you'll be running a much larger number of processes than you would otherwise (because of duplication) requiring a larger memory footprint and probably less efficient cache and/or IO utilization.

The deployment of the apps will be easier (which is a definite plus) but machine utilization will be lower and the amount of software running on a single machine will be far larger than otherwise, especially if multiple versions of dependencies are present on the same system.

A container is very much not a single process, it can contain many processes and some of those processes will likely duplicate components in other containers but without the resource optimizations that a kernel can normally perform.

Re: Interview with Eric Brewer

#28

Post by GauntletWizard »

philip1209 wrote: post #14
mark_l_watson wrote: post #7

Great Interview! I worked as a contractor at Google in 2013 and loved their infrastructure. It was amazing to fire off a Borg job that used hundreds to thousands of servers, and the web based tools for tracking the job, fantastic logging to drill into problems, etc. And, Borg was two generations ago! Even though I am very happy doing what I am now, sometimes I literally wake up in the morning thinking about Google's…

How hard was it to learn these tools as a contractor? I hear that Google is more aggressively making their tools open-source to help the portability of their engineers' skills. Specifically, friends have told me that onboarding at Google is difficult because every tool is a proprietary one built on top of more proprietary systems. In addition, people who leave Google have trouble interviewing because they rely heavil…

Onboarding at Google was great; Unlike similarly-sized and oft-mentioned competitors, Google has a set of really good classes that take you through the various systems, showing their design, reasoning, historical anecdotes, etc. Each of these has a more in-depth version, as well as a couple of classes called "Searching Shakespeare" that are designed as a two-day full-stack quickie to build something that uses a little of ever piece.

Re: Interview with Eric Brewer

#29

Post by jedberg »

A funny and somewhat off topic story -- back in 2003, before the Google IPO, Google was doing a recruiting event at Berkeley. They brought a few of their folks with them: their founder Larry, one of their female engineers, Marissa, and some others. They did a little talk, and during the Q&A, professor Brewer told Larry that there was an opening in the PhD program and he was welcome to it. Larry politely declined.

Afterwards I asked Larry, "so, do you think you'll ever finish your PhD, either here or at Stanford?". He said, "If this Google thing doesn't work out I might, but I have a feeling it will work out ok."

It amuses me that Professor Brewer is now working for Larry. :)

Re: Interview with Eric Brewer

#30

Post by jacquesm »

mixmastamyk wrote: post #24
jacquesm wrote: post #18

Earlier quoted context omitted.

An OS has some pretty extensive insight into the processes that it executes, a container is an OS with a single application, so containers (assuming they take basic precautions for isolation) are not going to be able to schedule with anywhere near the efficiency that multiple processes on a single OS will. I can see some (mostly potential at this point) security advantages but that's about it (and maybe those advanta…

The linux kernel knows what is happening in the containers. There is little performance overhead, and security is not a big advantage of the approach, VMs are better.

The linux kernel knows what's happening inside the containers but it can not de-duplicate any components that are present in multiple individual containers and it can not ensure that only one version of a package is present. This will potentially lead to cache trashing and more IO than strictly speaking required for a given workload.

Of course it does make it easier to package and deploy applications (and to ensure their correct application) but to pretend that there is no cost associated with this is simply not true.

Post reply on HN