Once upon a time, threads were a new thing. Hardcore Unix architectures were processes-only, cheap forking, and would have none of this lightweight threads business. Some system architects -- stuck in the 1970s -- still produce architectures for modern operating systems that consist of dozens of processes. I have personally seen a complex UI application on Windows that relies on >35 processes, of which eight different processes display parts of the application's UI (at the same time!). There is much good to be said about the isolation benefits of multiple processes, but having a Unix-inspired fear of threads is often completely unjustified today, especially in face of the cost of inter-process communication and the complexity of starting up, coordinating, and shutting down multiple processes.
I am now seeing the same thing happening with virtual machines. It is very cheap to put up a virtual machine on Azure, Amazon, or Rackspace. Very easy, too, and scriptable -- in ten minutes' time you can set up a farm of twenty virtual machines doing your bidding. This leads to architectures where every system component -- which used to live in a separate process or thread -- now lives in a separate virtual machine. Starting up, coordinating, and shutting down multiple virtual machines is harder and slower than doing the same with processes, and it seems to me that we're falling into the same trap again.
If you're separating your system into a bunch of virtual machines, I think it would be valuable to stop and ask yourself if they are all strictly necessary. In a system with good separation of concerns and good decoupling between independent components, you can always scale to multiple VMs if necessary. This is another case of premature optimization, which has a measurable financial cost in maintenance, operations, and management overhead.