Is there any advantage that containerization offers that virtual machines virtualization doesn't?

[oslon]

I am preparing for interview questions in devops engineering after working as a IT for 2 years.
In containerization, there are multiple OSes required inside like alpine linux. Same goes for virtual machine virtualization. We can discount the weight of virtual machine VMs. but I think we can always install stuffs on alpine in virtual machine as well.
To create a container and vm both are fast. Just copy and snapshot the vm. We all know what needs to be done for containers.
Honestly I think virtualization is more advantegous than containerization. I've been asked these questions multiple times in various of interviews and training in current company for new role and i have no concrete ideas.

 

[osprey]

@oslon asked:

Is there any advantage that containerization offers that virtual machines virtualization doesn't?
....
i have no concrete ideas

One idea follows, but I can't say whether it's concrete or not.

The differences between containerisation and virtualisation surely have to do with the purpose of the respective installations.

For example, if the user's purpose is to run some specific applications and no more, then a
container that includes the relevant software, including dependencies, in that standalone format, is likely the most resource efficient way to go.

If, on the other hand, the user's purpose is to run a more fully-featured experience with full work loads, then running the whole operating system of a distribution in a virtual machine has advantages. The installation of a distribution in a virtual machine is often going to be a closer representation to the original intents of the distribution than a container could represent because the virtual machine provides a more complete operating system environment that's a bit more isolated.

 

[Sinas]

I am preparing for interview questions in devops engineering after working as a IT for 2 years.
In containerization, there are multiple OSes required inside like alpine linux. Same goes for virtual machine virtualization. We can discount the weight of virtual machine VMs. but I think we can always install stuffs on alpine in virtual machine as well.
To create a container and vm both are fast. Just copy and snapshot the vm. We all know what needs to be done for containers.
Honestly I think virtualization is more advantegous than containerization. I've been asked these questions multiple times in various of interviews and training in current company for new role and i have no concrete ideas.

Well,

First of all, they both serve well for their purpose. there is no general answer like "Containers are better", No. You have to decide whether a VM or a container is better for your workflow.
But
Containers are easier to deal with, you don't need a hypervisor, all you need is a CRI that can interact with runc at kernel.
Managing containers is simpler. If you need to update a dependency in production, you just modify the Dockerfile and rebuild the container once. With VMs, you can’t easily recreate the entire image without overhead, so you usually rely on tools like Ansible or other automation to apply updates in place.

 

[dimko]

Containers are MUCH smaller in terms of space on disk and RAM AND CPU usage, hence lighter on resources.
Containers don't need OS files/apps. They don't need to run duplicate processes that your OS already is running.
Due to size, its easier and faster to back them up.
Its easier to re-deploy containers and faster.

 

[dimko]

I am preparing for interview questions in devops engineering after working as a IT for 2 years.

So many things you don't know, John Snow Best of luck!

 

[wendy-lebaron]

maybe i should start my own topic for this.

i should install "firejail" and check it out. otherwise i have to watch youtube videos and i hate that. while text documentation is sparse and confusing.

what i'm looking for is a "sandbox" or another way. to run an application. under a time limit, say five minutes. if the app finishes its duty before that. then fine, no problem. but if it takes longer than the limit. i want to be able to exit gracefully from it.

yes it sounds dangerous and like a security risk. someone might propose "cron" or its imitators. but i want to avoid whatever is available. which forces me to run as "superuser". it would complicate things. because i need the functionality i have revealed. to be able launched as regular user from an user application. in other words, "shell" statement in qb64 phoenix edition (microsoft q[uick]basic imitator that translates basic code into c++ to be able to create executable files). which "internally" uses "execvpe" or similar function in c/c++.

i might reveal more information about what i want to do. but better if one of the mods tells me. i should start another topic for it.

 

[gvisoc]

A Container is an additional user space on top of the kernel space of the host OS: from the "PID 1" (systemd, SysV Init,...) all the way to your application of choice, and with the chances of trimming out everything you don't need: there are containers with no init system at all. What you virtualise is the kernel tree.

Because of that, in containers you don't need to virtualise hardware, but schedule all the user space programs over the kernel's system calls. This not only consumes less storage volume, but also requires a lot less computing power as there's no need to emulate devices.

A Virtual Machine goes a level down, to the hardware, so you virtualise the CPU and those devices that offer virtualisation extensions, having to emulate the rest. That allows you to run a different OS than the host's.

One big difference is that with containers you share the underlying kernel, so you can't run a linux container on a windows host*. If you need to pack a set of applications over a reduced set of dependencies that would run over your host system, containers are the way to go. If you need to run different operating systems on the same machine, you'll need VMs.

(*) Typing your comment on Docker Desktop anyone? It ships an internal linux virtual machine where the containers are created.

 

[gvisoc]

@oslon For your interview, maybe reflect on the operational cost and I'd personally wouldn't try to identify an absolute best. It depends on the maturity of the place and where it peaks.

• a factor to take in seriously is that the more software your stack has, the more patching you'll require. Having all your environment on VM carries a lot more operational cost than trimming it down to the essential, so using containers where possible makes it easier to keep them patched and with no open CVEs. That means also that if your upgrades and patches require no outage, the VM need to be redundant and in clusters, and that multiplies by 2 or 3 the number of the hosts, that are bulkier.
• on the contrary, using containers makes the application layer more complex because you'll usually need a container orchestrator like kubernetes. While on VM orchestrators are also needed, the amount of hosts to orchestrate is less. Using containers require more engineering maturity, kubernetes is no easy. Terraform and the ansibles of the world are not pieces of cake either