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

41–50 of 196 posts

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

#41

Post by karmakaze »

rwmj wrote: post #34
zbuf wrote: post #22

Earlier quoted context omitted.

I believe it's because at some point the operating systems (particularly Linux based ones) became semi-closed ecosystems of software, instead of a platform to run other people's software. Also became a 'singleton' mentality too, where the only one version or variant of an app/library is accomodated. So now we're falling back to the few stable ABIs we have available -- Linus's kernel ABI (containers) and some kind of…

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.

This is actually a great explanation of how/why we got virtualization rather than microkernels. The hardware presented an ABI that couldn't be circumvented. The problem with software interfaces is that they're soft. With h/w we use a 'good enough' interface for possibly too long before it gets replaced as where in software we decide to upgrade the as-yet-not-widely-adopted interface with a better one and repeat.

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

#42

Post by jacques_chester »

naasking wrote: post #29
hinkley wrote: post #3

And let me state again for the record that all of these promises being made by container systems sound an awful lot like the promises I was offered by 'real' operating systems in the early nineties. I think the only real difference is that there has been a sea change in public opinion on this kind of aggressive isolation by default being worthwhile. But a hypervisor publishing a bunch of services that talk to the wor…

> Things are beginning to look a bit more like microkernels as time goes on. Hypervisors typically are microkernels. The very first "hypervisor" was L4 in fact, with L4Linux. Also, you're right that virtualization and containers are fulfilling the promises of operating systems. The problem of earlier OSes is that they didn't take security seriously enough. Modern hypervisors aren't much better at isolation than real…

> The very first "hypervisor" was L4 in fact, with L4Linux.

The term "hypervisor" was coined by Popek and Goldberg in 1974. L4 didn't appear until the 90s.

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

#43

Post by jacques_chester »

kresten wrote: post #26

Key point: AWS Firecracker does NOT run on AWS. Unless you want to pay for bare metal instances. AWS Firecracker DOES run on Google Cloud, Azure and Digital Ocean.

Firecracker is used as the runtime for Lambda, I believe.

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

#44

Post by denton-scratch »

I have a Xen hypervisor at home, running on a (well-configured) NUC. VMs boot in about 15 seconds. I'm patient!

I'm not doing devops stuff; I no longer code, so I don't need a testing pipeline.

I looked into containers based on LXC, when it was first introduced. I decided to stay away - I don't want to get tied into Poettering's code. Yeah, I'm running systemd on some of the VMs, but you don't really have much choice nowadays. I still use Debian, but I'm bitter about their adoption of systemd - and my hypervisor machine runs SysV Init, because I know how that works.

I never mixed it with Docker. From what I've been reading, Docker is already old-hat (it's only about 3 years old; how did that happen?) Kubernetes seems to be the thing nowadays. I don't even know how to pronounce "Kubernetes".

What was wrong with LXC? Like, LXC comes with the OS. Nothing to install. Why do people love these 3rd-party container engines?

And "wrappers"? what purpose is served by container wrappers?

Serious questions, I'm not trolling. Promise. I'm just a bit out-of-date.

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

#45

Post by jacques_chester »

"Containers" is an unfortunate term, since it really better describes the container image than an actual running process with API virtualisation.

I think VMs-as-containers is where we'll wind up. The container image has turned out to be the real thing of interest, the runtime is almost secondary. Virtual machine systems have closed the performance gap in a variety of ways.

For example: tearing out kernel checks for devices that will never be connected to the VM; taking advantage of hyper-privileged CPU instructions; being able to make and restore higher-fidelity checkpoints than an OS can for faster launches etc.

At which point the isolation benefits of VMs really begin to outweigh everything else. A hypervisor has a much smaller attack surface and has a much simpler role than a full monolithic OS kernel. It partitions the hardware and that's about it. It doesn't exist in a constant tension between kernel-as-resource-manager and kernel-as-service-provider.

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

#46

Post by alchemism »

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".

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

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

#47

Post by meddlepal »

denton-scratch wrote: post #44

I have a Xen hypervisor at home, running on a (well-configured) NUC. VMs boot in about 15 seconds. I'm patient! I'm not doing devops stuff; I no longer code, so I don't need a testing pipeline. I looked into containers based on LXC, when it was first introduced. I decided to stay away - I don't want to get tied into Poettering's code. Yeah, I'm running systemd on some of the VMs, but you don't really have much choice…

Some of us have problems that are actually well solved by these tools and run on more sophisticated hardware than our home computer... It doesn't sound like you've hit that set of problems.

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

#48

Post by jacques_chester »

denton-scratch wrote: post #44

I have a Xen hypervisor at home, running on a (well-configured) NUC. VMs boot in about 15 seconds. I'm patient! I'm not doing devops stuff; I no longer code, so I don't need a testing pipeline. I looked into containers based on LXC, when it was first introduced. I decided to stay away - I don't want to get tied into Poettering's code. Yeah, I'm running systemd on some of the VMs, but you don't really have much choice…

Docker achieved a number of things: they provided a simple user experience and a simple, relatively effective image format. The primitives had been in the kernel for some time and were widely used to implement a variety of systems (Cloud Foundry used these kernel features over 2 generations of its own code before switching to runc).

If you're just running stuff on a single machine for your own satisfaction, you don't need to fret about Kubernetes.

Disclosure: I work for Pivotal, so I've been up close with some of this stuff for a bit.

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

#49

Post by zbuf »

rwmj wrote: post #34
zbuf wrote: post #22

Earlier quoted context omitted.

I believe it's because at some point the operating systems (particularly Linux based ones) became semi-closed ecosystems of software, instead of a platform to run other people's software. Also became a 'singleton' mentality too, where the only one version or variant of an app/library is accomodated. So now we're falling back to the few stable ABIs we have available -- Linus's kernel ABI (containers) and some kind of…

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.

This is totally true, but I think it's the opposite approach that would have actually made a difference here. Saying "we know these ABIs won't be stable, either practically, or by design, so this is where the OS ends"

Then Linux package managers would have made it easy to eg. install local (eg. per user, or in a folder) libraries or software.

Of course it was always possible, setting various $PATH variables etc. but because it wasn't easy (and you're immediately out of the ecosystem) all focus has been on the root user and singleton approach. Static linking was put to one side too.

In doing so we made the presentation of the "operating system" a full ecosystem of libraries, too complex to be a defined layer to interface with. But the kernel realised the importance of stable ABI layer, so now we have containers instead.

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

#50

Post by panpanna »

jacquesm wrote: post #21
panpanna wrote: post #14

Earlier quoted context omitted.

What if the pure microkernel approach is flawed and hypervisors offer a sensible middle ground?

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?
Post reply on HN