[contingencies]

The limitation with this type of approach is the assumption of a conventional (and, some would say, out of date) architecture, ie. single service on a single VM on a single cloud provider.

Topology specification, firewalling, resource constraints (bandwidth, IO speed/resilience... ie. RAID/backup persistence safety), service cohabitation or codependence, performance/capacity testing, cost, cloud provider abstraction, public DNS+SSL+sofware package distribution infrastructure dependencies, legal jurisdiction considerations, speed of instantiation, etc. are all realistic considerations (often requirements) for much modern infrastructure.

In short: this only gets you half-way, for relatively simple examples. But if your workload is within that space, by all means go for it.

(PS. Before anyone snaps 'you can manage multiple hosts with <tool>', sure. But the architecture of the tools begins to present issues.)

[JunkDNA]

I'm not clear what your laundry list of things has to do with application development on a local developer's machine (the problem Vagrant is trying to solve). Is there some new way of development where developers never run on localhost and all those complex considerations are handled for them? It sounds like you're describing a full production or integration environment which is most definitely not the primary use case for Vagrant.

[jacques_chester]

> ie. single service on a single VM on a single cloud provider.

Vagrant allows you to specify groups of VMs that spin up together.

Your general point that it doesn't simulate production perfectly is correct. But this is one case where the perfect is the enemy of the good.

[davvolun]

Apparently to simulate production to the level OP requires, the only solution is to have the users test your product--the only way to perfectly simulate reality is reality.