Hi,
Obviously additional VMs are going to add overhead.
As you say "those applications communicate with each other", for example communicating via the (virtual) network won't be as fast as communicating on localhost.
If splitting up makes sense depends on workload (for example is it slow in one VM already?) and your goals.
On the one hand, multiple VMs means additional overhead on maintenance.
On the other hand, being able to keep things separated also means that it decouples the dependencies.
Eg. messing up a database VM means that you can replace the database VM with a backup and not worry about the rest of the stack, or take a snapshot of that ONE VM so you can roll back only that one (again great with databases when you are testing).
Also note that if your required workload has things like "testing different database backend servers" that it is a great example for when to split up things. If everything is in one VM, each of those database backends will always use resources, even when you are not using them. If each database server is running in their own VM, then they only use resources when you spin up the VM. eg. have an Oracle VM, a MySQL VM, a postgreSQL VM, an MSSQL one etc...
FWIW, I'm the "keep all things in their own VM" guy and happy with the results, it works very well for me. I can spin up what I need and it all works very well and is pretty flexible.
But I also know people who are big fans of the "all in one" approach.
another edit: If you use the "multiple VMs" approach then be frugal when assigning resources. For example I rarely assign more than 2vCPU's or 4GB of RAM to a VM.
--
Wil
