Do containers mark the beginning of the end for VMS and possibly C# and Java ?
-
Hmm, I have a colleague who is a great believer in containers. However, I have yet to find any use case for them in my work, even though I use VMs extensively and have done for many, many years. It has been a very long time since any of the true hypervisors have consumed significant amounts of the hosts available resources (certainly the bare metal ones anyway, like ESX) and the sheer hassle of coming up with a working Docker image of my dev environment say, that I can replicate easily between my various workplaces and machines is much greater the just cloning a complete VM and spinning it up, and for on-going development I just use Nextcloud to replicate the work between multiple (virtual and/or physical) machines to make sure they all keep in step, and write occasional updates to my GIT repository by way of additional backup (itself running in a linux VM that is hosted on one of my ESXi hosts - that also hosts my DC, my SQL server, a mail server for some of my clients, a 3CX phone exchange and a Nextcloud instance that I and some of my clients use - all on an old I7 with 32Gb RAM). I use VMs to replicate the entire working structure of one of my clients, so I can develop in a replica of their production environment without risk to their setup and yet be confident that when I deploy, things will work. Despite the incredible hype surrounding Docker (and to some extend Kubernetes) I have yet to find any instance when Docker was a better fit for me. My colleague, despite insisting that containers would be much better and more productive, has never been able to explain exactly how it would help me. So my answer is "No" 8)
I am talking about the run time virtual machines that .net, java and python languages target .
-
Of course they do it , the code is compiled to intermediate language in .net and that is executed in the runtime virtual machine. It is this virtual machine that may be impacted in the case of code running in containers since the software environment is now controlled. The hardware isnt, but the software is . In that case are the benifits of using the runtime virtual machine as compelling . Of course not all code runs in containers, and it never will, but in the case of containers are there any advantages that can be gained by having control over the software enviornment? Potentially do we need the VM in its current form (in containerised apps) . If we dont ( and I am not saying we dont I am mulling over the question) but if we dont need the VM then isnt that a bit of a kick in the teeth for languages that use a VM such as c#,vb.net, java, python etc. Will we see an emergence of a language more suited to containerised apps?
Andrew Torrance wrote:
the code is compiled to intermediate language in .net and that is executed in the runtime virtual machine. It is this virtual machine that may be impacted in the case of code running in containers since the software environment is now controlled. The hardware isnt, but the software is .
I'd call that a sandbox. To me, a VM has to allow the hardware and peripherals to be governed by a different OS (or another instance of the same OS).
I wanna be a eunuchs developer! Pass me a bread knife!
-
.NET doesn't even use a VM. 🤣
All .net languages, java and Python ( and probably others) target run time virtual machines. App code is compiled to an intermediate form for execution on the run time virtual machine.
-
Andrew Torrance wrote:
the code is compiled to intermediate language in .net and that is executed in the runtime virtual machine. It is this virtual machine that may be impacted in the case of code running in containers since the software environment is now controlled. The hardware isnt, but the software is .
I'd call that a sandbox. To me, a VM has to allow the hardware and peripherals to be governed by a different OS (or another instance of the same OS).
I wanna be a eunuchs developer! Pass me a bread knife!
In all honesty many people replying have been banging on about VMS (or VMs for the pedants) as if I was talking about the traditional virtual server. I'm not, I am talking about the run time virtual machines integral to program execution in many languages. Not really a sandbox , they are referred to by the term virtual machine , hence the confusion. My bad for not being clearer.
-
How many grammer nazis does it take to change a lightbulb ? Ans: Too
Their isn't a hell to hot for you...
Software Zen:
delete this; -
That doesn't make any sense, they're completely different things. Both containers and VMs can run C# and Java applications, but not vice versa. C# ad Java can be used to create new applications, while VMs and containers, well, can't because they're very different things. VMs can be used for work computers, servers, sandboxes, etc. and give you a complete OS on top of your OS. Containers just run a piece of (non-UI) software on the existing OS. If you really have to ask this I suggest you do some reading on the topics.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
One of the main advantages of C# and Java is their use of a virtual machine. It abstracts the dependency on the underlying hardware. But dont containers also do that by allowing us to have whatever OS we want independent of the underlying operating system OS ? So why do we continue to use VMS in a world of containers ? And if the use of VMS goes , does that mean the writing is on the walls for languages that use them, such as C# and Java, or will we simply see a move away from the vm and revert to having the code more tightly coupled to the underlying OS ?
You're kidding right? First, containers are specialized version of a VM. End of story as it abstracts an operating system. As for the end of C# - the future has never been brighter. We are now for the first time seeing C# penetrating the Linux world. Setting up a project to run in a virtualized environment is super easy today. Between containers and app engines running the language of choice C# has never been easier to scale. I honestly don't know about Java - but I wouldn't count it out anytime soon.
-
Not at all. It's like a lightweight VM, but the technology is completely different.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I was talking about the run time virtual machines that the languages use to execute the IM. Assuming I am running in a container (and of course not everything does) and have complete control of the software enviornment doesnt that take away operating system uncertainties, leaving the hardware to be abstracted. In which case do we need to use a virtual machine at runtime ? Of course that tightly couples the code to a specific run time environment which is not ideal so that would be a good argument not to.
In that case I see what you mean in that it could replace the JVM, although that's likely not going to happen anytime soon. There are a few problems. One, as you mention, containers run on the OS while VMs can have their own OS. Second, so far, running UI applications in containers isn't possible (well, I think it is, but you'll have to go through a lot of trouble and do some hacking and tweaking). For that reason, I don't think containers will replace VMs, they do different things and have different purposes, even though one looks like the other. .NET code doesn't run in a virtual machine, as far as I know. Instead, .NET's IL is compiled by a JIT compiler into machine code. The JIT compiler is just an application running directly on the user's machine.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Well, JVM/dotNET do virtualize some aspects - they are virtualization techniques. You can say the same about a lot of computer concepts: Any compiler virtualizes the instruction set of the CPU. A file system driver creates virtual storage unit where you don't have to handle sectors and track and surfaces. And so on. I see a lot of computer people that seem to think that virtualization is one specific thing: Creating a complete virtual hardware CPU / memory / IO environment. If you don't provide all of that Hyper-V or VMware provides, it is not virtualization. If you provide something not found in Hyper-V/VMware, then it it has nothing to do with virtualization. I beg to differ. Virtualization can cover an arbitrary set of virtualized aspects. Bytecodes is one aspect. Memory paging is another. File system drivers is a third. Yes, you are right that containers can run C# applications but not vice versa. You could say something similar: A file system driver can be realized in byte code but a byte code interpreter cannot be realized by a file system driver, so they are completely different things. Yet both are virtualizations. I have been arguing with Docker gurus who consistently insist that containers are NOT virtualization! But Docker does create virtual networks, a virtual address space, virtual disks... It is not the entire set of VMware virtualizations, but ... No, Docker gurus insist that Docker is lightweight, efficient, nothing like resource hogs like VMware/Hyper-V! Whatever Docker does must be called something else - even if it is exactly the same as virtualization. So even people who are working with such issues more or less full time do not have a comprehensive understanding of what virtualization is in a more general sense, but stick to specific instances of it. It should come as no surprise that a less experienced fellow have problems keeping things straight :-)
> but a byte code interpreter cannot be realized by a file system driver Of course it can :P (Not at all saying that you should though...) On a more serious note: you've nicely summed it up. Not all virtualizations are created equal. "I don't think about dying. It is the last thing I want to do. :) " - theoldfool
-
If "abstracting the dependency on the underlying hardware" is the criterium for a VM, then PDF readers are VMs, and even some word processors -- in fact, it could be said that anything that transports commands to OS peripheral interfaces is a VM. For me, being in a purist mood, a VM has to effectively sidestep the underlying OS of the computer, by running files on a different OS on top of the underlying OS. Do C# and Java do this? Not so far as I know, they don't; they may abstract things a tiny bit further than a PDF reader does, but it's still only abstraction. They are programs that allow you to open, run, and use certain files. Notepad does that much, for Heaven's sake! So stop calling spades shovels, and the "problem" highlighted by the article disappears.
I wanna be a eunuchs developer! Pass me a bread knife!
Here's the thing: Java and .NET have their own instruction sets (there's even a microprocessor that can run Java baremetal). So in my eyes it makes them "VM-y enough". > a VM has to effectively sidestep the underlying OS What do you mean about that? Is a paravirtualized kernel not a VM in your terms because it uses the host's OS API to perform its tasks? Or KVM, because again, it utilizes OS-supplied methods? > running files on a different OS on top of the underlying OS What about virtualizing MCUs/PICs or whatever embedded systems for testing purposes, which have no OS? Is anything a VM then? > PDF readers are VMs I'm not sure about PDFs, but PostScript engines are definitely VMs "I don't think about dying. It is the last thing I want to do. :) " - theoldfool
