Storage, software defined networking, performance metrics, VDIs, endpoint security, virtualization on the desktop.
Not to mention, a lot of workloads aren’t suited to containers. The vast majority of business software isn’t containerized, and it would be wildly cost-prohibitive for me to shoehorn that square peg into the round hole of virtualization.
Ultimately, in terms of what they can do, well technically you can do anything without any container or virtualization strategy, so from that angle, they are all the same.
It reallyboils down to what the humans are comfortable with, and that’s where there’s some divergence.
Sure, one could make technical arguments about one can be multi kennel, one has arguably somewhat stronger likelihood of isolation, and one has a bit more efficiency than the other, but it’s really down to human factors and familiarity.
Developers tend to like container based approach because the “image” is transparent and usually provides nice cheap options to somewhat track history and “fork” from common points with some flexibility. VMs kind of have some of that, but practically speaking it’s far more awkward.
Conversely some operators find managing container based solutions too “developery” and find comfort with virtual machines. It’s also more straightforward to just carve out a vm, hand it over, and give them the keys and let them deal with it. Then you commonly have VMs at one layer, and at least some of your tenants self managing some container management layer on top of their slice of the world.
While there is some overlap, general comparison of VMware vs Docker is a bit apples and oranges.
Please forgive a wildly uninformed question: What is it that VMware does today that isn’t covered by Docker?
Different OSes. Windows and Linux for example. No way to run a full fledged domain controller in a container. Just to name a example.
VDI environments is one place. Also Windows heavy environments (exchange, SharePoint, teams, DCs, etc) are probably better suited for VMs.
Storage, software defined networking, performance metrics, VDIs, endpoint security, virtualization on the desktop.
Not to mention, a lot of workloads aren’t suited to containers. The vast majority of business software isn’t containerized, and it would be wildly cost-prohibitive for me to shoehorn that square peg into the round hole of virtualization.
Uhh, docker is containers, VMware is a virtualization hypervisor?
Ultimately, in terms of what they can do, well technically you can do anything without any container or virtualization strategy, so from that angle, they are all the same.
It reallyboils down to what the humans are comfortable with, and that’s where there’s some divergence.
Sure, one could make technical arguments about one can be multi kennel, one has arguably somewhat stronger likelihood of isolation, and one has a bit more efficiency than the other, but it’s really down to human factors and familiarity.
Developers tend to like container based approach because the “image” is transparent and usually provides nice cheap options to somewhat track history and “fork” from common points with some flexibility. VMs kind of have some of that, but practically speaking it’s far more awkward.
Conversely some operators find managing container based solutions too “developery” and find comfort with virtual machines. It’s also more straightforward to just carve out a vm, hand it over, and give them the keys and let them deal with it. Then you commonly have VMs at one layer, and at least some of your tenants self managing some container management layer on top of their slice of the world.
While there is some overlap, general comparison of VMware vs Docker is a bit apples and oranges.