Virtual Machines vs Containers
-
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
-
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
Just "turn them off". This is the entire concept of cloud computing. You can turn off a container, you can turn off a VM in the same way.
-
@scottalanmiller said in Virtual Machines vs Containers:
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
Just "turn them off". This is the entire concept of cloud computing. You can turn off a container, you can turn off a VM in the same way.
I know KVM can do dynamic resource allocation. You have to set a max number beforehand, but you can change RAM and CPU on the fly as long as its the same or under your max.
Not sure about other hypervisors.
-
@stacksofplates said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
Just "turn them off". This is the entire concept of cloud computing. You can turn off a container, you can turn off a VM in the same way.
I know KVM can do dynamic resource allocation. You have to set a max number beforehand, but you can change RAM and CPU on the fly as long as its the same or under your max.
Not sure about other hypervisors.
ESXi definitely has some cool tech around that kind of stuff, too. And that's just at the hypervisor level. You still have cloud-style allocation on top of that.
-
@scottalanmiller said in Virtual Machines vs Containers:
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
Just "turn them off". This is the entire concept of cloud computing. You can turn off a container, you can turn off a VM in the same way.
Right but aren't you wasting a lot of resources at that point as well? I'm not sure how the licensing works with containers running only a set of services required for the app to run, but I'd think it would be a lot more cost effective resource wise than running an entire OS
-
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
Just "turn them off". This is the entire concept of cloud computing. You can turn off a container, you can turn off a VM in the same way.
Right but aren't you wasting a lot of resources at that point as well? I'm not sure how the licensing works with containers running only a set of services required for the app to run, but I'd think it would be a lot more cost effective resource wise than running an entire OS
Wasting them how? One of the big points about containers vs. VMs is that the overhead difference is trivial. Containers are lighter and faster, but by a tiny amount and there are complexities and limitations that come with that - like having to share one kernel instead of getting a unique kernel for each workload. So if you need to update the kernel or have anything compiled against a kernel it can cause problems.
-
@scottalanmiller said in Virtual Machines vs Containers:
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@wirestyle22 said in Virtual Machines vs Containers:
@scottalanmiller said in Virtual Machines vs Containers:
@RamblingBiped said in Virtual Machines vs Containers:
Application isn't being used heavily during 3:00am EST? Start culling under-utilized nodes/containers and killing them as they fall off. When your still running nodes/containers start to see higher activity, respond by spinning up more nodes and containers and bringing them online to meet demand.
You can already do all of that with VMs, though.
Dynamic resource allocation? Didn't know that outside of thin provisioning which wouldn't fit this use case. What is this called so I can research it?
Just "turn them off". This is the entire concept of cloud computing. You can turn off a container, you can turn off a VM in the same way.
Right but aren't you wasting a lot of resources at that point as well? I'm not sure how the licensing works with containers running only a set of services required for the app to run, but I'd think it would be a lot more cost effective resource wise than running an entire OS
Wasting them how? One of the big points about containers vs. VMs is that the overhead difference is trivial. Containers are lighter and faster, but by a tiny amount and there are complexities and limitations that come with that - like having to share one kernel instead of getting a unique kernel for each workload. So if you need to update the kernel or have anything compiled against a kernel it can cause problems.
Why do containers exist if it's trivial though? I'm assuming containers become 'best practice' at extremely high work loads?
-
@wirestyle22 said in Virtual Machines vs Containers:
Why do containers exist if it's trivial though? I'm assuming containers become 'best practice' at extremely high work loads?
Well they are an old technology and VMs were not very efficient and required rare hardware support back when containers were introduced. Containers come from the FreeBSD and Solaris worlds, which are often not on similar hardware. Containers work the same across architectures, where VMs do not.
-
@wirestyle22 said in Virtual Machines vs Containers:
I'm assuming containers become 'best practice' at extremely high work loads?
Twelve years ago they were when Solaris went to 100% containerization (Type-C Virtualization as it is sometimes called.) Solaris doesn't run any other way. Today, it's more niche. Even the biggest workloads like Amazon rarely use it. The difference is just too trivial.
-
@scottalanmiller Good to know. Thanks!
-
FreeBSD Jails, the first big time container technology, was introduced in 2000. Back then only paravirtualization was available, and only from Xen and that's before it was mainstream. So containers pre-date virtualization on Intel and AMD architectures for general use by quite a bit and predate full virtualization by quite a bit more.
-
@stacksofplates said in Virtual Machines vs Containers:
I know KVM can do dynamic resource allocation. You have to set a max number beforehand, but you can change RAM and CPU on the fly as long as its the same or under your max.
Not sure about other hypervisors.ESXi supports this (HotAdd is the term used). Requires BaseOS support it.
-
@scottalanmiller Containers with some exceptions (ESXi Instant Clone, and Photon Fast Boot) are orders of magnitude faster to create than VM's.
Containers running in a shared OS instance also can lower CPU overhead on the scheduler. Until recently Containers also sucked pretty bad at high IO activities (still not amazing, but a bit better).
