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

81–90 of 196 posts

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

#81

Post by BubRoss »

GauntletWizard wrote: post #63
BubRoss wrote: post #53

Earlier quoted context omitted.

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…

Processes exist in separate virtual memory spaces. Threads in the same process exist in the same virtual memory space. This is a fundamental principle of virtual memory.

Mixing this up with a filesystem or any shared resource is completely nonsensical. Naive oversimplifications like this indicate a lack of understanding of how and why computers are architected as they are in the first place.

Virtualization could be said to be an extrapolation of virtual memory and in fact does offer sub virtual memory, but to equate threads, processes, virtualization and shared resources as the same thing is grasping for simplicity that isn't there by making comparisons that aren't true.

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

#82

Post by tsimionescu »

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…

Having used both LXC and Docker, the main advantage of Docker is using it as a package manager, with the ability to extremely easily start from a 3rd party container and layer your own changes on top. While I'm sure LXC could technically achieve the same, it is way more difficult to do so than docker's 'FROM 3rdparty-container:$VERSION' / 'docker pull 3rdparty-container:$VERSION'.

On the other hand, Docker for a long time didn't really care about security, which LXC was much better at since the beginning more or less.

As for Kubernetes, that is most often used in conjunction with Docker (though there are alternatives), if you want to deploy containers to a cluster of machines (VM or physical) and get rid of some of the administrative work for doing so.

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

#84

Post by bogomipz »

msla wrote: post #36
naasking wrote: post #29

Earlier quoted context omitted.

> 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…

> Hypervisors typically are microkernels. Except they have vastly different histories (look up IBM's VM) and uses and underlying technologies. Here's a good post on the difference: https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi... > Microkernels are intended to create a minimal set of low-level operations that would be used to build an operating system. While it's popular to slap a monolithic kernel on…

>"Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be."

I found this interesting. Can you or anyone else say what the context was where academic researchers have needed to do this? What problem was it solving for them in a cheap way?

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

#85

Post by nostrademons »

tsimionescu wrote: post #77
nostrademons wrote: post #75

Earlier quoted context omitted.

An idea I've been toying around with but don't have time to fully explore or implement: The unit of isolation should be the library , not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can…

Given that some of the most commonly used external libraries do networking, IO, graphics and encryption, I don't think this would really be feasible.

Presumably they'd have to be rewritten, but if you're talking a new OS anyway everything's gotten be rewritten, because you won't have the standard UNIX syscalls. This is not something to embark on lightly, which is why I haven't embarked on it yet.

But imagine a future where using a traditional OS means there's close to a 100% chance that you will have your identity and/or financial assets stolen, or where these computers are widely used in the military and a security failure literally means you're dead. We're headed there anyway, judging from all the headlines on data breaches and identity theft. There'll be system failure at that point, as well as a strong incentive to rewrite everything as a secure system.

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

#86

Post by sansnomme »

eyberg wrote: post #61
sansnomme wrote: post #54

Earlier quoted context omitted.

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 whe…

Hypervisor on hypervisor makes sense if you care about security. Your average FaaS-on-Kubernetes hosting services not from one of the tech giants is a far cry from AWS Firecracker (Lambda) level of isolation. E.g. you run a gaming server and wants to allow arbitrary user plugins, or perhaps a challenger fintech bank that wants some simple user scripting. You want to allow Python/Ruby/any lang except Lua/JS/WASM. You won't be able to find anything hosted that doesn't cost an arm and a leg. (On an unrelated note, if anyone from Zeit is reading this, can you comment on why now.sh container support was deprecated in V2? Was it because of cost?)

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

#87

Post by eyberg »

mynegation wrote: post #73
eyberg wrote: post #61

Earlier quoted context omitted.

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 whe…

> However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) I work in traditional finance, outside of Silicon Valley and there is a huge drive to move to the public cloud. For the same reason banks do not own their office buildings anymore - managing computing infrastructure is not their core business and - to be honest - they are not very good…

I don't know who you specifically work for but I've been to 2 different banking tech conferences in the past month. JPMorgan mentioned they have 13 (or was it 16?) wholly owned datacenters. BoA's tech summit was just this past week in Palo Alto and they were highly negative of anything public cloud. For them it is an extremely rare thing for them to put anything in public cloud. A point they stressed throughout the summit is that the main thing they sell is 'trust' (eg: by holding people's money) and that is quite simply not something they are willing to delegate to others and that's the main driver for them but of course all the other things like cost, security, regulatory, and data gravity are drivers as well.

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

#88

Post by zzzcpan »

tsimionescu wrote: post #77
nostrademons wrote: post #75

Earlier quoted context omitted.

An idea I've been toying around with but don't have time to fully explore or implement: The unit of isolation should be the library , not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can…

Given that some of the most commonly used external libraries do networking, IO, graphics and encryption, I don't think this would really be feasible.

It's feasible in the same way bounds checking is feasible. Everything could have a capability token attached to it and checked. Compiler could generate all the language level checks, kernel could do OS level checks. Main program could have some built in capabilities and capabilities it gets from the other OS processes, it could then pass them or devise new ones to library functions, they could pass them to other library functions and so on.

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

#89

Post by Terretta »

eyberg wrote: post #87
mynegation wrote: post #73

Earlier quoted context omitted.

> However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) I work in traditional finance, outside of Silicon Valley and there is a huge drive to move to the public cloud. For the same reason banks do not own their office buildings anymore - managing computing infrastructure is not their core business and - to be honest - they are not very good…

I don't know who you specifically work for but I've been to 2 different banking tech conferences in the past month. JPMorgan mentioned they have 13 (or was it 16?) wholly owned datacenters. BoA's tech summit was just this past week in Palo Alto and they were highly negative of anything public cloud. For them it is an extremely rare thing for them to put anything in public cloud. A point they stressed throughout the s…

Since you cite JPMC, read this Sept 2019 interview with CEO Jamie Dimon:

https://www.geekwire.com/2019/interview-jpmorgan-chase-ceo-j...

“Jamie Dimon: The cloud and AI are real, huge, powerful and they’re going to change a lot for us. Of course, good companies are going to adapt to it in due course. They can’t just do it overnight, but it changes a lot more than just using the cloud — how you write your code, how you can do agile, it even changes how you organize your company. Managers start to think about using data in a far different way than they ever did before. It changes everything. It’s a huge opportunity.”

...

“When cloud first got started, there was no reason to use someone else’s data center or their networks. You know, I wasn’t completely wrong, if I can run my data center as efficiently as a cloud guy, which fundamentally is true.”

”But here’s what I missed: the bursting part of the cloud. It reduces the peak capacity that we’ve got to keep in our own data centers, and you can burst excess workloads into the cloud. And it directly relates to AI. There’s just so much compute power in one split second that I simply can’t do in one of my data centers. So if you want to apply AI and these tools, and also the services that are built into some of these platforms [the cloud offers an advantage.]”

// Disclaimer: I work at a global bank.

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

#90

Post by sansnomme »

zzzcpan wrote: post #88
tsimionescu wrote: post #77

Earlier quoted context omitted.

Given that some of the most commonly used external libraries do networking, IO, graphics and encryption, I don't think this would really be feasible.

It's feasible in the same way bounds checking is feasible. Everything could have a capability token attached to it and checked. Compiler could generate all the language level checks, kernel could do OS level checks. Main program could have some built in capabilities and capabilities it gets from the other OS processes, it could then pass them or devise new ones to library functions, they could pass them to other libr…

But that means you have to upload raw source code. It's closer to Apple's app store deployment than to what current cloud hosting offers (arbitrary compute power for anything but crypto mining).
Post reply on HN