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

51–60 of 196 posts

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

#51

Post by kazen44 »

meddlepal wrote: post #40
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".

Serverless has been around now for several years and it hasn't taken off yet... definitely not to the same degree containers have. I'm skeptical it will. To adopt serverless you need to be willing to rearchitect your product and retool your developers... that's expensive.

containers are still relatively new and definetly not as ubiquitous as virtual machines.

Virtual machines are everywhere, from SME to large enterprises, tech hubs, industrial software et al.

Containers are mainly used for modern web and app development.

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

#52

Post by dopylitty »

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 suspicion that new generations are re-inventing the wheel in a lot of ways. If you have minimal containers running on a hypervisor how is that different from processes running on an operating system? You have all these CPU provided virtualization instructions to protect guests from each other and the host from the guests but there's no reason those instructions couldn't have been developed to protect processes from each other. You have indirections to protect one guest from accessing another's storage but there's no reason processes couldn't have the same protections (and they do in many operating systems). Why container orchestration and overlay networks instead of OS scheduling and IPC?

I'm sure people in academic computer science have already published many a paper about this but it feels different seeing it from inside an IT organization where people don't seem to apply the lessons from older technologies to newer ones and we end up in this constant churn of reinvention which, as far as I can tell, is mostly a way for people, both in management and in the trenches, to keep their jobs, at least until you're "too old to learn new things" and pushed aside.

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

#53

Post by BubRoss »

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.

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

#54

Post by sansnomme »

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 technology that allows easy compartmentalization with somewhat reasonable security isolation out of the box for existing server code. Containers are not perfect, and hypervisors/unikernels are a pain to deploy on commodity cloud services but we are slowly getting there. (Also if you notice, newer generation of operating systems like Android, iOS, Fuchsia are moving towards strong sandboxing with every single thing locked down where possible. There is an impedance mismatch between the Unix model and current demands. You can't migrate overnight so you build technologies to work around it. From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app)

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

#55

Post by taeric »

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…

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 something to be said for this, of course. But it seems a losing game. I contend there is no technical panacea to security versus convenience.

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

#56

Post by naasking »

gtirloni wrote: post #35
naasking wrote: post #30

Earlier quoted context omitted.

The typical problem with microkernels is poor backwards compatibility, mainly due to POSIX. If you add POSIX compatibility, you don't gain any isolation, performance or security benefits of microkernels, and changing your thinking and your programs to gain those benefits requires significant work when they're written against the POSIX API. Building them that way from scratch is pretty much just as easy as writing pro…

If you don't mind this tangent question... Is there a microkernel API that has more acceptance nowadays? In other words, where should anyone wanting to work on real world / enterprise systems based on microkernel look?

seL4: https://sel4.systems/

The kernel is even formally verified, and it's very widely deployed.

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

#57

Post by dopylitty »

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.

That's a good point. But as I think about it in a sense threads are also a form of isolation in that they allow you to isolate units of business code so that they can run independently and be (potentially) protected from other business code monopolizing a shared resource while not actually doing work.

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

#58

Post by naasking »

meddlepal wrote: post #39
gtirloni wrote: post #35

Earlier quoted context omitted.

If you don't mind this tangent question... Is there a microkernel API that has more acceptance nowadays? In other words, where should anyone wanting to work on real world / enterprise systems based on microkernel look?

Isn't Windows NT the poster child for a non-POSIX mainstream microkernel?

NT kernel is not really a microkernel. It tool inspiration from microkernels but it's still a highly modular monolithic kernel.

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

#59

Post by naasking »

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…

> Except they have vastly different histories (look up IBM's VM) and uses and underlying technologies.

Microkernels over time have also employed vastly different technologies. All the "differences" you note are "intended system design/interaction", which frankly isn't meaningful. For instance:

> By contrast, hypervisors virtualize and emulate hardware at various levels of abstraction. This involves providing some of the same things that microkernels do (eg memory isolation, scheduling), but people interact with hypervisors in very different ways than they interact with microkernels.

Who cares how they interact with it? A microkernel is defined by the sorts of abstractions it provides and the isolation properties those abstractions entail. Hypervisors are effectively less expressive microkernels.

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

#60

Post by GauntletWizard »

taeric wrote: post #55
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…

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 the rest of your (potentially malicious) system. They do force you to think about some of the questions, though, like "Where is my data stored and how do other tools interact with it?"

Most of the problems that people complain containers don't solve are ones that are open ended, and have no definite solution.

Post reply on HN