Just waiting for the new re-discovery of hypervisors, but with better marketing names.
Serverless servers?
Containers in 2019: They're Calling It a Hypervisor Comeback
11–20 of 196 posts
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#12Just waiting for the new re-discovery of hypervisors, but with better marketing names.
Federated subsystem authoritator
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#13Is there still any place in 2019 for "system containers" like LXC/LXD?
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#14And 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…
Plus now, the app devs, now all turned devops because talent is scarse and demand is high, get to handle the complexity of concurrency, networking and reliability. This adds to deployment/testing/development setup, and when you change stack or job, the architecture slightly different and you need to learn it all over again. Funnily enough, we couldn't make the microkernel concept works despite an homogeneous, integra…
What if the pure microkernel approach is flawed and hypervisors offer a sensible middle ground?
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#15Is there still any place in 2019 for "system containers" like LXC/LXD?
They are quite useful as "VMs at the speed of application containers".
When you use application containers, you tend to create a more complicated setup and lose visibility as to what's going on in the system.
Just like you use VMs on a baremetal server, you use system containers in a VM.
But I find more important to use LXD as a tool for software development and also for Linux desktop use.
If you want to setup nodejs or something similar, it makes sense to put it in a LXD container so that it does not mess up your host. Each step of the workflow (creation, deletion, etc) takes a few seconds or less.
You can also setup LXD containers to run GUI applications. It makes big sense if you want to run games (like Steam) so that your desktop does not get polluted with i386 packages. You can also use for development tools, such as those from JetBrains, Android Studio and more.
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#16Is there still any place in 2019 for "system containers" like LXC/LXD?
They're certainly very useful for CI systems.
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#17Earlier 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 irony is that now we have Azure services to keep state across serverless requests.
Excuse me while I go implement a servlet over there....
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#18Is there still any place in 2019 for "system containers" like LXC/LXD?
They may not be mainstream but I use them as isolated VM-like application environments, where everything “just works” without having to learn/apply a whole lot of new tools or workflows.
I’m sure there must be others who see the benefit of this approach too?
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#19> The Docker engine default seccomp profile blocks 44 system calls today, leaving containers running in this default Docker engine configuration with just around 300 syscalls available. ...preventing devs/ops people to run tools like iotop, unless extra capabilities are added. I'm all in for containers, cgroups/namespaces but at the moment it's namespace isolation for the price of less features. Unless namespaces bec…
> ...preventing devs/ops people to run tools like
This is because docker makes the fundamental mistake of conflating packaging with isolation. "Packaging" is achieved in docker by using the OS to do an amount of sandboxing and then letting the user perform whatever non-reproducible crap they like before balling the whole thing up and calling it a package.
If instead you make an app author actually figure out what their dependencies are and how to fetch/build them - in a system such as Nix, you not only get reproducible packages, you also get to decide to apply actual os-level isolation on a case by case basis - a developer doesn't necessarily need/want these barriers on their dev machine.
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#20I'm quite hopeful for the limited re-introduction of hypervisors to "containment", if only because I've become disappointed with the lack of power app authors have to specify fine-grained, strict security details. This is because most of the fun lockdown toys that linux has, selinux, seccomp et al aren't easily "stackable", and those toys have been used by the orchestrator to perform the containment. And that's great, but it means containers all end up with broad, generic policies (that only care about container breakout) which can't be further restricted by app/container authors.
My hope is that lightweight virtualisation will give back the ability for app authors to tighten their container's straight jackets. Personally I've got my eye on kata containers.