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

Containers in 2019: They're Calling It a Hypervisor Comeback

infoq.com

Post reply on HN
Print view View original

61–70 of 196 posts

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#61

Post by eyberg »

sansnomme wrote: post #54
dopylitty wrote: post #52

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…

Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…

Deploying a hypervisor on top of a hypervisor (eg: a public cloud) usually makes very little sense so I don't see that as a trend. However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) so hypervisors typically in the form of ESX is still very much a thing and now that we are seeing tighter integration with things like unikernels that is where the 'comeback' is coming from. I would almost go as far to say that it's becoming hip not to be using public cloud today.

Deploying a unikernel on top of commodity cloud is very achievable and easy today - I know because I'm involved with https://ops.city . I'd argue it's ridiculously easier than trying to deploy a container, clearly way safer and even faster and easier than using something like terraform.

I do very much agree with your impedance mismatch re: unix model thought though.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#62

Post by jeieo9nkfkr »

dopylitty wrote: post #52

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…

I have a sneaking suspicion this has a lot to do with business finding a “market niche” more so than reasonable engineering.

They wrap it in semantics they know from marketing physical products, and hey the general public is ignorant...poorly informed ...I mean cool with it... give the people what they say they want when we decide what’s available in the first place... I mean what fits our business niche.

If that feels a bit circular, human society is a bit circular.

I’ve become convinced we’re doomed as so many cannot see the difference between objective physical reality and metaphor/analogy. Even a lot of educated people struggle with the emotional dissonance despite getting through the homework.

Aristotle and scores of other philosophers wrote of it too. The concern being if the general public knew there really weren’t Gods on the mountain, they’d be pretty fucking pissed. So we’ll conveniently “let them have” their myths and legends.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#63

Post by GauntletWizard »

BubRoss wrote: post #53
dopylitty wrote: post #52

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…

Threads are not the same because they are separate computation in the same address space. At some point though, permissions to disk, network, screen, input devices, etc. need to be an integrated part of computing for anything that runs more than one program. Take a look at QNX though, at some point it will be reinvented and heralded as a breakthrough, 40 years after it happened the first time.

Processes running on the same host are a "separate computation in the same address space" - They share a filesystem namespace.

Pods running on the same kubernetes cluster are a "separate computation in the same address space" - They share a DNS namespace.

Servers running on the same internet are a "separate computation in the same address space" - They share an IP namespace.

These are the same abstraction at multiple levels, and that's okay, because you often do need that. The L1 and L2 cache are crystaline to inmemory and redis caches in distributed systems. Components with the same shape show up at multiple levels. This is okay. What's important is that those levels each serve a purpose, and that you reduce the abstraction to be as simple and meaningful as it can be.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#64

Post by aloknnikhil »

alchemism wrote: post #46
tyingq wrote: post #10

Earlier quoted context omitted.

K8S is unnecessarily complicated. I fully expect "serverless", warts and all, to take all comers. And, I get the irony. It's basically cgi-bin 2.0. It will win not because it is better, but because it is better "understood".

The rabbit hole goes deeper than that, my friend. https://cloud.google.com/run/

Oh God, why? Btw, this uses gVisor (https://gvisor.dev/) as the container runtime (instead of runc/containerd). That seriously limits what syscalls the containers can leverage. And the pricing is complicated too.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#65

Post by jacquesm »

panpanna wrote: post #50
jacquesm wrote: post #21

Earlier quoted context omitted.

Most of the people that rail against pure microkernels have zero experience actually building stuff with them. Those that do have that experience have hard proof that systems built in this way are more reliable and easier to build than others. Hypervisors have their own place in the hierarchy, they do not compete effectively with microkernels on their own turf.

Would you consider the gnu hurd folks experienced enough?

No. I thought GNU Hurd was a great idea executed poorly. QnX is that same idea executed in an excellent and pragmatic way.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#67

Post by regularfry »

dopylitty wrote: post #52

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…

From memory, I seem to recall that Genode takes this to its logical conclusion: every process is isolated with virtualization primitives.

As to why: isolating processes the old way needs jails to work properly, BSD lost the popularity contest, and Linux jails didn't get secure enough before VMs and containers took off.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#68

Post by taeric »

GauntletWizard wrote: post #60
taeric wrote: post #55

Earlier quoted context omitted.

This gets silly, though. If you are going for full isolation where applications can't just let the user have data, then you have to coordinate every app talking to every other app. This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. Is it safer? Hard to say. I can do less and have less capabilities without more active work from the developers. There is…

There is no technical panacea, but containers are a useful abstraction. Containers bring back the original intent of the unix process/user security model, allowing you to scope each process to have it's own 'private' filesystem to get around the broken way executables are built, packaged, and linked. This doesn't save you if you do dumb things, like have open ports that allow administrative access that are exposed to…

containers are a great tool for corporate servers. For end user machines, it is a tougher sell.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#69

Post by pjmlp »

gtirloni wrote: post #37
rwmj wrote: post #34

Earlier quoted context omitted.

This is simply a side effect of ill-disciplined programmers breaking ABIs whenever they feel like it. It's quite possible to maintain ABIs in the long term and upgrade and deprecate them thoughtfully, and if you do that then you don't need multiple versions of a library or service around.

If the POSIX committee couldn't deliver a solution that was modern and backwards compatible, what hope do we have that developers will selforganize and ever do that?

POSIX committee doesn't deliver anything.

POSIX is just a common API across UNIX clones.

And besides the AT&T original design, UNIXes have disagreed in almost everything else, hence UNIX wars.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#70

Post by regularfry »

tyingq wrote: post #10
pojntfx wrote: post #4

Earlier quoted context omitted.

"Workload Orchestrators" K8s can already do VMs with Kube-virt, so yeah.

K8S is unnecessarily complicated. I fully expect "serverless", warts and all, to take all comers. And, I get the irony. It's basically cgi-bin 2.0. It will win not because it is better, but because it is better "understood".

CGI-bin 2.0 is actually quite neat: having your script kick off on as many machines as needed is something CGI-bin 1.0 never cracked on any significant scale, and (eventually) having something like a standard interface to do that on Someone Else's Datacenter will be fun.
Post reply on HN