Cloud computing? Now that's a whole different ball game. I'd say they're mostly embarrassingly parallel (or close to) or the cloud functions as a some sort of wrapper/manager/storage. It's easy access, low-cost computer time.
(I appreciate your google-fu)
They are not the sort of use cases I had in mind, nor the kind of software tools I was referring to, hardware one has access to.
If one were so inclined, I'd say Java (released 20 years ago) is also a virtualization. Write once, run on any platform. Not used widely in scientific computing, but it's present. Performance is still rather horrible, but hey, it's easy to write.
I already knew the story when it happened since I am also a certificated AWS Solution Architect. I'm just putting it out to tell you that it has happened and virtualisation across the board for consumer, enterprise and even military or scientific usage is not a new story at all.
Cloud computing is not miracle. It is still built the very same technologies that are powering virtualisation on workstations, namely Xen. The same applies for M$ HyperV, or VMWare vSphere. The best value in a mature cloud computing provider like AWS, M$ Azure, GCE is their management tools and how they provide SOA like services or micro services.
The only thing at the end of the day of using virtualisation is how much overhead we are talking about. Baremetal hypervisor at Level 1 like VMware vSphere, M$ HyperV, Redhat HVM, Linux KVM are working on top of a thin layer of virtual abstraction and hence offers near native performance. Parallels Workstation, Desktop, Vmware Fusion workstation, player at Level 2 hypervisors, will incur more overhead since they are riding on a full fledge OS which may or may not have the best optimised drivers to serve abstraction.
Java is a form of abstraction. While we can look at it from a virtualisation perspective, but today, Java is not considered virtualisation due to the following reason
1) Even if you write codes for Java, you cannot achieve 100% consistency across all platforms since the API are not 100% equivalence across all platforms.
2) There are API found in certain platforms like Win32 API which are not found in the *NIX counterparts.
3) JVM perform Just-In-Time compilation which compiles bytecodes into native codes, which means your codes now touches the binary directly, so it's not virtualisation at all.
I'm afraid you may not have catch up with performance of an enterprise level JVM. Java is not lagging by a lot compared to native codes. The WORM concept was in the past, but very much broken in today's Java development. I learn and do Java development for almost 15 years, how would I not know it ?
Feel free to read
http://fiehnlab.ucdavis.edu/staff/kind/Collector/Benchmark/JAVA_Benchmark on Java 1.6.
When you run your applications on a hardware level virtualisation, it's not the same as Java. There is nothing you need to change in your code to accomodate. The ABI(not API) applications running on top of the Windows guest running in Linux, Mac, or another version of Windows doesn't change across these hosting environment platforms. That's hardware virtualisation, so don't be mistaken with Java.
For most of the reason we have for JVM dismissal, it is not with how fast JVM run, but rather on the Garbage Collection pauses due to stop-the-world operation. This problem has been very well investigated and researched and greatly resolved. If you have enough money to spend, Azul Systems have the highly priced JVM wich is claimed to be capable of High Frequency Trading(HFT).
Whether your distributed architecture is embarrassingly parallel or not *has nothing to do with virtualisation*, has nothing to do with which platform it runs on, has nothing to do with which programming language you use*. If you code your program wrongly and enforced too much global/distributed locking, it will still hinder performance when you run them across baremetal machines. Eventually the network synchronisation will slow the overall performance to how much network latency there exist. You may also passthru your codes in parallel to underlying GPU equiments, internal or external such as the Nvidia Tesla, or perhaps have your codes adapt to OpenCL which will run fine across the board using Intel support chipsets or AMD ATI Radeon GPU or Nvidia cards or appliances.
Mature Cloud providers like AWS merely does it a lot better than your own setup having they can employ industrial class equipments like Infiniband, or fibre channels to minimise the network latency across dedicated hardware nodes suitable for HPC. They can also employ larger machines which can hold more cores within the same instance so that performance works better than across the networks between the NUMA cores.
Bottomline is I do not agree that just because you are on cloud computing means things must be embarrassingly parallel. Things are done this way because architects recognise the short fall of such environments and architects employ what is best for the environment. The same goes for virtualisation and native. However what I have presented is if we want to throw blame at virtualisation for slowing down your application, then perhaps the better question to ask is, why are you not using applications or designing applications which take advantage of horizontal scaling which will give you the performance boost in areas where possible. Unless you are able to point out that your application is designed single threaded or there is no possible algorithm on earth that could parallelise the computation that is required which is then we can only run on the fastest single core we can find. Otherwise I think it is more of an architecture inadequacies instead of virtualisation or not.
If you have analyse all the above and you feel your approach is best for own use cases, that is good. Just that in the context of this thread, I don't see that we need to consider this as a setback because ultimately if one is trying to get the most out of just one single node, and to consider virtualization as a disadvantage to the purpose of this thread, i would have considered it "not thinking out of the box" (almost literally)
