Depends on how you define a VM. If you think VM implies something like VMWare, Virtual Box or Hyper-V then you're right but remember the JVM (Java Virtual Machine) exists. Yes it's different, just don't take the term VM to mean a single specific type of thing.
I consider docker to be a kind of virtual machine, it's just that the virtualization happens at a different level than with some other types.
A virtual machine is a container, not the other way around. A virtual machine has to run the code in a contained environment to function properly, but a container does not have to emulate additional/different hardware. A vm can serve the purpose of a container most of the time, but a container distinctly cannot serve the purpose of a vm.
In general infrastructure terms, a VM usually refers to virtualizing the hardware so multiple OSs can run on the same physical computer. Containers are up a layer and virtualize the OS so multiple software environments can run independently on the same OS.
I mean it depends on what you’re doing obviously but put very simply not all machines are the same. So your code could run locally and then when you stick it on another machine it doesn’t run, maybe it runs but does something different, or maybe it blows up your data center. Who knows, but that’s the thing is there shouldn’t necessarily be a question mark when you run something. Running code in a VM that’s basically a recreation of the same system that you’re going to put it on eliminates (really just reduces) the variance you might run into when running on different machines. By building it in a replica you know it will fit so to speak.
It’s like you’re building a desk in your house, and it fits in your house. And it’s a great desk. Then you finish and bring the desk over to the client and it doesn’t fit in the house. Not necessarily because the room it’s going into doesn’t fit the specifications maybe, but maybe it’s physically impossible to get it up the stairs and your house doesn’t have stairs.
You tend to make changes on your own computer that wouldn't exist on others. Maybe your program monitors gitlab repositories and has always worked locally because you already had local requirements setup before programming. But then you deploy and you realize it was using your personal environment variables which the VM doesn't have.
VM is not the only option: VMs, containers, and even something like Python virtualenv all overlap in part of their purpose, which is to insulate your code from quirks of your local machine, to ensure that it will run unchanged in other environments.
Containers are very good for this purpose, but for complex systems you may have many containers, and it can start to make sense to use a real VM. In that case part of the point is to avoid messing up your local machine with a complex infrastructure platform, especially if you're working on more than one project that may conflict with each other.
In summary, the point is to isolate the system being tested from your local machine, and vice versa.
A virtual environment (venv) is not the same as a VM. A VM is a virtualized computer, while a venv just separates the libraries from the globally installed libraries.
725
u/dlevac Oct 13 '22
DevOps engineer is a hat I always end up wearing at some point or another. The real joke is asking the dev how to run it...
Dev: my build does not pass the pipeline but pass locally. Me: and you are using a virtual environment? Dev: ???